Re: As a developer, what's the best way to accept BTC without using third-parties
Hi,
I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network.
I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay.
I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain.
I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues.
What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems.
I have one potential solution in mind. Let me know if you see any problems with this.
I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network.
I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay.
I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain.
I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues.
What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems.
I have one potential solution in mind. Let me know if you see any problems with this.
Code:
1- Join the network, wait for new blocks from peers
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
2a- Look at the block, check the transactions included in the block, are they relevant?
2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
2c- Sweep the address and send it to cold wallet
2d- Increment the balance of the user
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
2a- Look at the block, check the transactions included in the block, are they relevant?
2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
2c- Sweep the address and send it to cold wallet
2d- Increment the balance of the user
What's wrong in using a 3rd party API ?
Bitcoinj isn't trustless either
SPV clients are not suppose to be trustless so it isn't trustless in any context, it is convenience. Security is given up for convenience.
Unless you want to run a full node in front of the bitcoinj library and force bitcoinj to only connect to that. Then it is trustless.
Yes, it is not. It isn't unreasonable to trust some full-nodes you are running, though.
No, but you are concerned about scalability while I don't know what you are doing, that is the key word that I would use a 3rd party api. Lowest overhead and easiest to be scaling with.