This is reckless. If your hardware corrupts data too often to sync a full node, the solution is not to hack together a homemade payment processing system with only SPV-level security that will run on your faulty hardware. This approach and the attitude behind it will lead to losing money and losing track of customer payments, probably sooner rather than later. Rolling your own payment processor is a great way to learn more about bitcoin, but use testnet coins. If receiving real money is what you want, use a tested library written by someone who put in the time and experience to do it the right way, or use a 3rd party payment processor. Don't learn with real money; that's learning the hard way.
How to accept Bitcoin payments without running a full node
21–28 of 28 posts
Re: How to accept Bitcoin payments without running a full node
#22A problem I'm currently addressing that maybe someone can help with:
I'm using a BIP32 HD wallet master pubkey to generate addresses on the payment front-end. Now, the ideal payment-watching solution would be the following; it maintains a set of "active" addresses, which I can add to whenever, and notifies me whenever one receives a confirmed payment. However, I'm not sure if this exists. I would also settle for me being able to query arbitrary address balances quickly.
Bitcoin-core doesn't work because adding an address causes a rescan of the entire blockchain (as it doesn't maintain an address-indexed UTXO dictionary for all addresses), which is too slow. I think electrum-server might work. Even though I'm following the same derivation path as electrum-client, I don't think I can use electrum-client for this (because I could conceivably be attacked with hundreds of thousands of address generation requests, which I doubt electrum-client will like). I also want to ignore adderesses more than, say, a week old, which I don't think electrum-client supports.
Re: How to accept Bitcoin payments without running a full node
#23Author here, surprised to see this on HN! I considered submitting it myself but didn't think this crowd was that into Bitcoin. Nice to be proven wrong :) A couple of people mentioned HD wallets: I initially tried using an HD wallet, but the mechanism for interacting with it was more inconvenient than generating keys manually - especially considering that you might have to generate hundreds of addresses in a row that…
> I initially tried using an HD wallet, but the mechanism for interacting with it was more inconvenient than generating keys manually - especially considering that you might have to generate hundreds of addresses in a row that never receive a payment.
Not sure I follow. The only difference between generating a HD-derived address and a traditional address should be that the former can be re-generated based on the master key alone. Not sure what difference not receiving payment at hundreds of addresses would make between the two.
Re: How to accept Bitcoin payments without running a full node
#24> I use the keyconv program from vanitygen as a convenient way to do this. Simply running "keyconv -G" generates an address and private key and outputs them.
You have to really trust that vanitygen tool. If there's some bug where there's not enough entropy in the private key generation, ALL your temporary wallets become vulnerable (e.g. someone can generate your private keys).
Re: How to accept Bitcoin payments without running a full node
#25> I use the keyconv program from vanitygen as a convenient way to do this. Simply running "keyconv -G" generates an address and private key and outputs them. You have to really trust that vanitygen tool. If there's some bug where there's not enough entropy in the private key generation, ALL your temporary wallets become vulnerable (e.g. someone can generate your private keys).
The keyconv program is extremely short, it simply calls the key generation routines in OpenSSL.
Re: How to accept Bitcoin payments without running a full node
#26Author here, surprised to see this on HN! I considered submitting it myself but didn't think this crowd was that into Bitcoin. Nice to be proven wrong :) A couple of people mentioned HD wallets: I initially tried using an HD wallet, but the mechanism for interacting with it was more inconvenient than generating keys manually - especially considering that you might have to generate hundreds of addresses in a row that…
> I initially tried using an HD wallet, but the mechanism for interacting with it was more inconvenient than generating keys manually - especially considering that you might have to generate hundreds of addresses in a row that never receive a payment. Not sure I follow. The only difference between generating a HD-derived address and a traditional address should be that the former can be re-generated based on the mast…
I agree. Using an HD wallet would work fine. I found the tooling less convenient so I didn't use an HD wallet.
Re: How to accept Bitcoin payments without running a full node
#27Doesn't stripe support bitcoin?
Re: How to accept Bitcoin payments without running a full node
#28The author mentions being plagued by crashes/corruption, but I've never experienced this and I've been running a full node for a few years. Other than the large (well, not _that_ large) storage requirements (.bitcoin is currently 101G) I've not got any complaints... Unless there's a bug in a recent version of bitcoind which causes it to crap out when initially catching up with the network?
> Other than the large (well, not _that_ large) storage requirements (.bitcoin is currently 101G)
This has always been my complaint with bitcoin. Will the block chain download just keep getting larger and larger? Setting up a full node takes forever because of that. Is there any possible way to improve this?