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.


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.


Issues related to gap limit as summarized in this blog post. Basically you have few options

  • Use wallets like electrum to increase gap limit setting
  • Automatically send small amount of funds to 20th unsued address to keep things going. This is done by services like blockonomics
  • 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.
  • can give me more information about the 3rd option? – patrick Jun 10 '18 at 16:18

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.

  • 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 May 29 '18 at 23:37
  • 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 May 30 '18 at 3:24
  • Another better solution to this, you can use the "Balance Update" notification. – ethmz May 30 '18 at 10:52
  • 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 May 30 '18 at 17:29
  • Small or big collateral doesn't matter. both of them are equal to a faulty system. – ICE May 30 '18 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.