Feature Request - HD Wallet

[genus1]

I received and loved your book then saw the NoAPI shopping cart and was happy because I to am tired of blockchain.info and others not issuing api keys for virtually no reason.

I believe, instead of private key generation and saving in the database it would be great to integrate an HD wallet generator from an XPUB and store the Account and Address of the bitcoin address like m/0/0 etc.

I would specifically target Trezor and other wallets.

Now my site is perfectly safe. Maybe someone would get my xpub and a little privacy would be a problem, but ALL signing keys are in the Trezor.

You could use straight-server or other like MyceliumGear and keep track of unused address in the database so they could be reused to avoid the gap limits.

I have no way to get ahold of you so maybe you can contact me via github.

[coinables]

Thank you genus1, I'm really glad to hear that. Please consider leaving a review on Amazon if you can :)

In regards to the HD wallet integration to this shopping cart, someone else reached out to me with a similar request. It's definitely on my to-do list since it would make things much more secure; private key storage on a web server is typically a bad idea as we recently saw with bitfinex. At least with this shopping cart, the funds are only at risk until you sweep them off of your webserver for each sale. As long as you are selling small ticket items, the risk is nominal.

I'm leaning towards using the BitWasp library to handle the address generation from the main xpub key, the tricky part will be handling the gap issue, without having to heavily rely on an API. I recently did a video on using smartbits API for working with HD xpub keys but I don't think they would work with the gap issue. I could log the key index of each new generated address to a database, but even if they have the index if their wallet doesn't see the transaction then the user will have to manually regenerate those keys with something like bip32.org

[genus1]

Kyle,Thank you for your reply.The way to handle gap is fairly simple. You record the account and the address for a specific xpub to a the member invoice.If the invoice does not process within a short period say 15 minutes the invoice would be market as timed out and the same account/address would be reissued to another customer.You add timed out accounts or cancelled accounts to a list and reuse them from lowest account. If you ever get an account used twice because someone was late paying you still have an invoice saying they paid. You would just have two invoices on the same address.This should keep ahead of a gap unless you have large number of orders at a time. If you do have a large number you use another account with a different xpub giving another 20 to the pool. You would have a table to keep track of the last generated key and keep track of your combined gap. Anyway if you would like to discuss further please request my email. Roger

[genus1]

Kayle, I have put your code up for testing and would be of mutual benefit to work together testing this with about 1000 customers right now. The main thing at the moment is to make the qr integration more friendly and cut down on server overhead. How about saving the orderID in a session and have a button they click to verify they have written down the payto address and orderID BEFORE anything is sent on the websocket. The button starts the websocket and first response of the address shows payment sent. If they leave the page open, it can reply first confirmation as paid. Also you should pre generate the qr code and include amount and message with orderID. Also us https://larsjung.de/kjua/ for your qr generator. I am working on all this at the moment.

[coinables]

We could lighten the server load from the QR code portion entirely by running it client-side using a javascript library https://github.com/davidshimjs/qrcodejs Implementation is quite simple, already tested it and works fine.

EDIT: Committed the change, and removed googleAPIs. QRs are now generated client-side in javascript. https://github.com/coinables/Bitcoin-NoAPI-Shopping-Cart/commit/a83385c491ea9386611ec91526ae05d05426ffd9

[genus1]

Great, I did not load your version yet. I put my own together and my code presents the qr containing the address, amount and message for the invoice number which is the orderID. I also modified the page for better user interface. You can test it at https://wecbtc.com/noapi. When you get to the pay side you can ignore paying the $0.60 testing fee. One problem is that blockchain.info does not feed back all the time and you do not get a message. Need to look at option to select other service for monitoring. I could share the code but not real skilled at git hub. Guess I could try.

[genus1]

Careful with BitWasp. Their website is hacked. Domain gone. Viruses on the site.

[coinables]

Did not know that about bitwasp, thanks for the heads up. Thankfully I haven't used anything from them yet. If the blockchain websocket is failing, we could use a back-up like block.io to fire in case no connection is made. Here's an example I created for someone else with block.io's websocket. Basically works the same with some minor differences in variable names. I like your version. It worked well for me, including the blockchain websocket to recognize the payment in real-time. http://i.imgur.com/tAyHCMp.png

[genus1]

I do not know if any files at bitwasp are hacked but links on them have been and the domain is gone. A lot of people use them and they do look good if the code is still safe. Thanks for the donation on the test. My next important part is to put in the hd generator and a database to just keep track of used addresses and unused. If the gap start to get big I can reissue old addresses again keeping track of the orderID. I think the straight server is the best choice which is what mycelium built their stuff on. You did not provide a link to the other site with block.io. I think it is smart to have three of them in case something goes down. Also gives you options to compare price etc..

[coinables]

Ooops https://jsfiddle.net/p5rr0Los/ Or you can subscribe to a specific BTC address. https://jsfiddle.net/bxw3v8c7/

[genus1]

Did you use an api key on jsfiddle I cannot see or is it not needed? Line 7 in admin is throwing an error. Maybe try: if((!isset($_SESSION['logged'])) or ($_SESSION['logged'] != 1)){

[genus1]

Somehow in line 11 order.php the id is sometimes undefined. I will work this weekend on figuring out github so I can do a pull and provide you some input.

[ahmedphp90]

Hello Kyle , i have questions , can u explain how the address generated can belong to me or how it's work with out api ? beside can u provide us the version with block.io

thanks

[ruthtern]

If I can raise an objection to the HD suggestion, and propose a different approach to keeping the private keys safe ... I am uncomfortable with deterministic wallets because exposure of the seed risks the entire fund base I understand the benefit of deterministic, and I understand there are ways to keep the seed safe My objection is on the basis that the seed is a single point of risk for a potentially large number of keys

An alternative proposal ... Move the key generation logic off the web server Pre-generate a sufficient quantity of keys in advance off-line, and then store a copy of the set of public keys on the Web server Replace the current code which is generating keys, instead select the next available public key from the stored key set This way the private keys are never exposed on the Web server

Before the set of stored keys is all used, the administrator should replenish the set

And for HD wallet fans, this approach lets you use your HD wallet, to pre-generate the keys, away from the Web server

This approach avoids the complexity discussed earlier in this thread regarding gaps and address reuse

[coinables]

@ruthtern That's definitely a viable option. One could create a simple file locally that would generate for example 10,000 addresses and store the key pairs to a local database, back it up. Then import the database file with only the addresses, leaving the private keys offline. For each new order grab a fresh address and mark it as "used".

[dcb500]

@coinables @ruthtern read the discussion , the proposal to keep the keys offline and use previously generated addresses is very nice. I will donate a good amount to the project if this idea gets realized.

[ruthtern]

@dcb500 Just noticed your comment. Also noticed the project has been sidelined due to the security issue of keeping private keys online, an extra incentive to implement the suggested enhancement. Have recently been conscripted to build a Bitcoin donation receipting system with similar requirements

[genus1]

I noticed the comments. I have been using an offsite hd address generator by supplying the xpub. I have had no issues and if a gap starts to appear, just pay a small amount to one of the later addresses. Of course you still have to monitor the addresses to make sure they are not intercepted by using a security key and https. Also all payments end up in a Trezor so the keys are well protected.

However, I like the idea of generating your file and then only putting addresses in the online database for security purposes. I considered that prior to using the HD approach. Make sure that you encrypt your file on your hard drive or someone could get ALL your keys. This is great for security but may be added software complexity. It should be fairly easy to implement.