<p>Here's my solution.</p>

<p>When gap limit is reached, append a random and unique satoshi amount to the total bitcoin amount and associate it with the user.</p>

<p>For example, if your product price is BTC 0.001, then generate an amount like 0.00100001 for user A, 0.00100002 for user B, both using the same address when gap is reached.</p>

<p>Now for user A, you use Blockchain.info's Receive API. In the database, you record user A, price and address.</p>

<p>Now in the case of user B, you use the Balance Update API. In the databae, you also record user B, price and address.</p>

<p>So when you receive the notification, you can check which user made the payment by checking the amount paid.</p>

CC BY-SA 4.0
2018-05-29T23:37:50.357Z
This is not a solution. It can make disaster. you should not give an address to two users at the same time and wait if one of them sending the amount. How about a time that two of them sent the amount?! That's not small collateral. That's very big flaw of this method.
ICE
CC BY-SA 4.0
2018-05-30T03:24:36.253Z
First user send money and you return `*ok*` for your callback. 2nd user send money and the wallet don't do callback because you returned `*ok*` for that address before. so does not monitor anymore. it means you can not even know the second user paid!
ICE
CC BY-SA 4.0
2018-05-30T10:52:01.013Z
Another better solution to this, you can use the "Balance Update" notification.
ethmz
CC BY-SA 4.0
2018-05-30T17:29:20.567Z
Waiting for more callbacks after one paid is bad. Maybe you get the first confirmation callback for 2nd user in the 48 hours. Balance Update is not a solution for gap limit. It seems HD wallets are not for merchant. They have big flaw for online stores and they can not handle big or even small online stores.
ICE
CC BY-SA 4.0
2018-05-30T22:23:08.507Z
Small or big collateral doesn't matter. both of them are equal to a faulty system.
ICE
CC BY-SA 4.0
2018-05-29T12:31:12.183Z
2018-05-30T22:57:54.313Z
2018-05-30T22:57:54.313Z
ethmz
<p>Issues related to gap limit as summarized in <a href="https://blog.blockonomics.co/bitcoin-what-is-this-gap-limit-4f098e52d7e1" rel="nofollow noreferrer">this blog post</a>. Basically you have few options</p>

<ul>
<li>Use wallets like electrum to increase <a href="https://bitcoin.stackexchange.com/questions/22606/more-receive-addresses-with-electrum">gap limit setting</a></li>
<li>Automatically send small amount of funds to 20th unsued address to keep things going. This is done by services like <a href="https://www.blockonomics.co/merchants" rel="nofollow noreferrer">blockonomics</a></li>
<li>Keep generating new address without worrying about gap limit. Later you can generate all private keys using xprv and sweep in the funds from all private keys.</li>
</ul>

CC BY-SA 4.0
2018-06-10T16:18:55.347Z
can give me more information about the 3rd option?
patrick
CC BY-SA 3.0
2018-03-20T05:58:06.773Z
2018-03-20T05:58:06.773Z
dark knight
<p>I am building a app, and the design is, the "welcome page" has a qr code allowing the user to purchase a single-use of the app.</p>

<p>Blockchain.info conveniently allows you to use xpub to generate addresses, however, their docs mention bip 44, and the "gap limit"...  This is instantly a problem as I can imagine, say 30 users simultaneously going to the app (more realistically, 30 users going to the app under the amount of time it takes a single user to purchase), 20 will be presented bitcoin addresses to purchase, 10 will not due to the api throwing gap limit errors.</p>

<p>What options do I have to get around this?</p>

<p>I've had others suggest I just manually generate a bunch of private keys and not use xpub, but manually having to consolidate all of those single-transactions-per-address just sounds like an absolute nightmare that I would like to avoid.</p>

<p><strong>UPATE</strong></p>

<p>Is there any way at all to re-use the same address every time, but attach a guid to it so that when I see the txn broadcasted, I can link it with a given user's session?  This is really all that I need.  I don't need xpub.. I just need a way to identify that user A and user B both are viewing the welcome page, user A doesn't pay, user B does, user B is automatically given access, user A is not.</p>

CC BY-SA 3.0
2018-03-19T09:29:47.567Z
Possible duplicate of [How to solve Blockchain 20 address gap-limit problem?](https://bitcoin.stackexchange.com/questions/48090/how-to-solve-blockchain-20-address-gap-limit-problem)
pebwindkraft
CC BY-SA 3.0
2018-03-19T17:46:51.420Z
@pebwindkraft unfortunately that post doesn't offer any sort of solution or suggestion.
patrick
CC BY-SA 3.0
2018-03-20T04:22:31.693Z
Use https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Public_parent_key_rarr_public_child_key ? Do you need an implementation?
MCCCS
<blockchain.info><api><bip44><xpub>
What options do I have to avoid API gap limit? I am using xpub keys
patrick
# What options do I have to avoid API gap limit? I am using xpub keys

(Asked by: username_0 on 2018-03-19)

I am building a app, and the design is, the "welcome page" has a qr code allowing the user to purchase a single-use of the app.

Blockchain.info conveniently allows you to use xpub to generate addresses, however, their docs mention bip 44, and the "gap limit"... This is instantly a problem as I can imagine, say 30 users simultaneously going to the app (more realistically, 30 users going to the app under the amount of time it takes a single user to purchase), 20 will be presented bitcoin addresses to purchase, 10 will not due to the api throwing gap limit errors.

What options do I have to get around this?

I've had others suggest I just manually generate a bunch of private keys and not use xpub, but manually having to consolidate all of those single-transactions-per-address just sounds like an absolute nightmare that I would like to avoid.

**UPATE**

Is there any way at all to re-use the same address every time, but attach a guid to it so that when I see the txn broadcasted, I can link it with a given user's session? This is really all that I need. I don't need xpub.. I just need a way to identify that user A and user B both are viewing the welcome page, user A doesn't pay, user B does, user B is automatically given access, user A is not.

**Tags:** blockchain.info, api, bip44, xpub

> **Comments:**
> **username_1**: Possible duplicate of [How to solve Blockchain 20 address gap-limit problem?](https://bitcoin.stackexchange.com/questions/48090/how-to-solve-blockchain-20-address-gap-limit-problem)  
> **username_0**: @username_1 unfortunately that post doesn't offer any sort of solution or suggestion.  
> **username_2**: Use https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Public_parent_key_rarr_public_child_key ? Do you need an implementation?  

---

## 2 answers

### Answer by username_3 on 2018-05-29. Score: 1

Here's my solution.

When gap limit is reached, append a random and unique satoshi amount to the total bitcoin amount and associate it with the user.

For example, if your product price is BTC 0.001, then generate an amount like 0.00100001 for user A, 0.00100002 for user B, both using the same address when gap is reached.

Now for user A, you use Blockchain.info's Receive API. In the database, you record user A, price and address.

Now in the case of user B, you use the Balance Update API. In the databae, you also record user B, price and address.

So when you receive the notification, you can check which user made the payment by checking the amount paid.

> **Comments:**
> **username_4**: This is not a solution. It can make disaster. you should not give an address to two users at the same time and wait if one of them sending the amount. How about a time that two of them sent the amount?! That's not small collateral. That's very big flaw of this method.  
> **username_4**: First user send money and you return `*ok*` for your callback. 2nd user send money and the wallet don't do callback because you returned `*ok*` for that address before. so does not monitor anymore. it means you can not even know the second user paid!  
> **username_3**: Another better solution to this, you can use the "Balance Update" notification.  
> **username_4**: Waiting for more callbacks after one paid is bad. Maybe you get the first confirmation callback for 2nd user in the 48 hours. Balance Update is not a solution for gap limit. It seems HD wallets are not for merchant. They have big flaw for online stores and they can not handle big or even small online stores.  
> **username_4**: Small or big collateral doesn't matter. both of them are equal to a faulty system.  

---

### Answer by username_5 on 2018-03-20. Score: 1

Issues related to gap limit as summarized in [this blog post](https://blog.blockonomics.co/bitcoin-what-is-this-gap-limit-4f098e52d7e1). Basically you have few options

* Use wallets like electrum to increase [gap limit setting](https://bitcoin.stackexchange.com/questions/22606/more-receive-addresses-with-electrum)
* Automatically send small amount of funds to 20th unsued address to keep things going. This is done by services like [blockonomics](https://www.blockonomics.co/merchants)
* Keep generating new address without worrying about gap limit. Later you can generate all private keys using xprv and sweep in the funds from all private keys.

> **Comments:**
> **username_0**: can give me more information about the 3rd option?  

---

