Thanks fbueller.
I think the take-away from your post is to wait for a few confirmations before making any commitments, and use a combination of multi-sig and cold/hot wallets to limit damage from an attack. These are things I'll certainly be implementing!
Topic: Transaction with Many Outputs (Read 748 times)
You might be missing re-org's. A block might be replaced by another, undoing the one where a transaction confirmed. You need to be able to unwind if this happens, since the transaction may get dropped by the network. It's unlikely, but has happened.
Track the payment for a couple of confirmations. That way you're sure to be handling reorgs (otherwise your app would start getting duplicate balance updates). You really need to guarantee consistency between user balances and funds in the wallet.
You should look into using watch only addresses, and perhaps multisig, as keeping a bitcoin node with coins on a webserver (or accessible via jsonrpc) will probably cost your customers their coins. I say this only because it sounds like you're trying to accept payments without using an API, which is great.
Track the payment for a couple of confirmations. That way you're sure to be handling reorgs (otherwise your app would start getting duplicate balance updates). You really need to guarantee consistency between user balances and funds in the wallet.
You should look into using watch only addresses, and perhaps multisig, as keeping a bitcoin node with coins on a webserver (or accessible via jsonrpc) will probably cost your customers their coins. I say this only because it sounds like you're trying to accept payments without using an API, which is great.
Standard enough situation, I'm using -walletnotify to call gettransaction, in order to monitor incoming payments.
My plan is to iterate through all outputs and
Does this sound ok to implement or am I missing something?
My plan is to iterate through all outputs and
- only check outputs that have 'category = receive'
- only check outputs that include an address I have presented to a user I.e. stored in my database
Does this sound ok to implement or am I missing something?
Jump to: