Post
Topic
Board Development & Technical Discussion
Re: As a developer, what's the best way to accept BTC without using third-parties
by
contactlight
on 22/11/2014, 23:35:20 UTC
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.
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

What's wrong in using a 3rd party API ?
its not trustless

Bitcoinj isn't trustless either Wink

Yes, it is not. It isn't unreasonable to trust some full-nodes you are running, though.