Quote from: gweedo on November 23, 2014, 08:58:55 PM

Quote from: sidhujag on November 23, 2014, 06:20:11 AM

Quote from: gweedo on November 22, 2014, 06:23:26 PM

Quote from: sidhujag on November 22, 2014, 05:58:23 PM

Quote from: BitcoinExchangeIndia.com on November 22, 2014, 05:52:48 PM

Quote from: contactlight on November 17, 2014, 09:11:23 PM

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

How? Does it force u to connect to an online api? If not it is trustless in the context we care about

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.

Quote from: contactlight on November 22, 2014, 11:35:20 PM

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.

Not meant to be trustless? Bitcoinj was trustless i thought it connects to peers and not some random api on the net unless its for a price feed which is irrelevent. What do u mean by this?