How to accept Bitcoin payments without running a full node
incoherency.co.uk
incoherency.co.uk
If you don't want to bother generating the deterministic keys online, you could pre-generate thousands, even millions of them if you want. And keep both the private and public master keys offline. It also is a safer approach since you can securely store the master private key in a offline hardware wallet and not have to worry about keeping track of hundreds of private keys.
Long time since I've been active in Bitcoin, but this is the way I would have run a payment service without using a full node.
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 never receive a payment.
I've added an update at the end of the article.
Cheers!
But as usual. People not to a) priven wrong and they need to get with it in touch with it every few weeks/ days to accept a new concept.
And i think for that. We as bitcoin fans and user should and now can get more cocky :)
I also browse HN quite frequently so would have been likely to see it anyway :)
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.
If you like the CLI, it has that too; it's a fully-compliant HD wallet. Getting set up is as simple as it can be
$ curl https://21.co > setup.sh
$ sh setup.sh
$ wallet create
[write down mnemonic]
$ wallet payoutaddress
[printed payout address]
If you like the advanced stuff, it has support for micropayment channels, too.
This is not accurate. Bitpay (most popular payment provider) charges you only if you settle (convert your BTC to USD).
If you are going through an exchange (bitfinex for example), you'll pay 0.2% for taker rates.
0.8% seems reasonable enough for me considering that Bitpay provides a decent interface and decent tools.
Unless there's a bug in a recent version of bitcoind which causes it to crap out when initially catching up with the network?
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?
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).
It is now part of the Mycelium Gear project, which is a hosted commercial version of it, and I don't work for the company anymore, but the team behind it that I hired and worked with is really great and they keep working on the product.
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.
Alternative:
Create HD wallet (via electrum e.g.), get "public master key" and use it everywhere. You can generate consequent public addresses using that key but you can't generate private keys (i.e. spend anything). Now your server is protected from stealing any money and don't require any special backups for these new keys.