Has anyone written the code already? Actually, I, too, was thinking of writing an example code to OP, but I am too damn tired to do it now. If you write it at the end, I provide my collection into your consideration where I will organize such example codes for our users. You may have me include your code, too.
But first thing first, OP have you solved the issue already or would you like to receive additional help?
Topic: How to optimize our Bitcoin integration? (Read 1749 times)
Although I haven't tried it in production this is how I was thinking of handling the gap issue.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
What if somone is about to send a transaction to that last 19th address?
Wouldn't matter, it would still show on the wallet since the look-ahead is 20 consecutive addresses.
Although I haven't tried it in production this is how I was thinking of handling the gap issue.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
Great description! I have not implemented it yet but I definitely saved it for later as a free time job or in case block.io's API goes down.
However, at the moment I think using block.io's API is the more comfortable choice. I learned about it overnight from their own public documentation.
Let me know if you need an example!
Although I haven't tried it in production this is how I was thinking of handling the gap issue.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
What if somone is about to send a transaction to that last 19th address?
Personally i'd just use block.io's API. It's faster, doesn't have the limits, and is more reliable.
Although I haven't tried it in production this is how I was thinking of handling the gap issue.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
1. generate new address
- - check the current gap
2. If current gap is > 19 then
- - call block.io to send a small payment to the newly generated address
3. discard that address
4. return to #1 (gap should now be zero).
You can check the current gap of addresses that haven't received a payment by calling https://blockchain.info/v2/receive/checkgap?xpub={xpub}&key={apikey}
You’ll get a JSON response like: { “gap”: 12 } if it reaches more than 20 you'll get an error.
So when generating a new address, I'd check the current gap for my xpub, and if it is larger than 19, then I will send a small payment myself to the newly generated address so the gap resets to zero, scrap the address, and generate another new address for the user to use.
The issue here is even though you are sending funds to yourself so you don't lose funds, it will still cost you transaction fees every time there's a 20 address gap. I'd use block.io to send the payment since just sending a payment from a single address will still be within their free api service.
Personally I think BIP32 does not work well with accepting payments online strictly because of the look-ahead issue. This happens with all wallets, it's not just a blockchain.info problem. I'd rather just use a fully functional wallet API, bitcoind or even generate key pairs on the fly and temporarily store them on the server for later once a payment is received to sweep the funds off your server.
the first optio you have is just switch to other api provider like blockio or other and if you can take a little expence then i think downloading the full bitcoin core wallet will be the gurrentyed and the best option for this kind of project because you need a strong network for this much traffic
We currently offer Bitcoin withdrawals and deposits on our website. Blockchain API is used to handle all operations.
Only problem is Blockchain Receive API's 20 address gap limit, as mentioned here: http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/
Now we get a lot of curious users who click on Bitcoin deposit button and commit to it without actually sending any transaction, which easily build up to 20 addresses. What are some ways of removing this limitation? I have few ideas but they are rather bulky and some require complete re-write of code and replacement of Blockchain API. Can you guys offer any insight and/or advice? How can this problem be solved in elegant and efficient way?
Only problem is Blockchain Receive API's 20 address gap limit, as mentioned here: http://bitcoinx.io/news/articles/blockchain-info-updates-receive-payments-api-version-to-address-edge-cases/
Now we get a lot of curious users who click on Bitcoin deposit button and commit to it without actually sending any transaction, which easily build up to 20 addresses. What are some ways of removing this limitation? I have few ideas but they are rather bulky and some require complete re-write of code and replacement of Blockchain API. Can you guys offer any insight and/or advice? How can this problem be solved in elegant and efficient way?
Jump to: