0

I have an app that accepts Bitcoin payments. After some research I've settled with using Bitcoin Core's bitcoind with RPC to manage new addresses and verify for new transactions for those addresses.

  1. A new deposit address is generated with getnewaddress
  2. Every minute a job runs and calls listsinceblock with the target_confirmations set to 6 (so that my database transaction records update up to 6 confirmations)

Currently I'm accepting transactions with at least one confirmation. I might start accepting unconfirmed transactions for high value users, with certain security measures in place.

Initially my business logic was having the txid unique to the transactions table, but, even though highly unlikely, a user might make a transaction to two different Bitcoin addresses associated to their account, so I must account for that case in which the txid is the same but addresses are different, but they are still valid deposit addresses for that user. Another case is, when a user might make a transaction in which more than one output belong to the same address. Bitcoin Core does not allow sending to the same address more than once in the same transaction, but other wallets do (e.g. Trezor). I've worked that out by using the vout index within the transaction.

So right now my unique index for Bitcoin transactions is a combination of these three: txid:vout:address

My question is, would there be other edge case scenarios that might need special validation logic? I'm not worried about RBF since I'm not accepting unconfirmed transactions (for now).

1 Answer 1

1

my unique index for Bitcoin transactions is a combination of these three: txid:vout:address

That seems like it might be overkill. After all, the blockchain only uses txid:vout to uniquely identify transaction inputs.

would there be other edge case scenarios that might need special validation logic?

I don't know, but maybe you need to consider how you handle blockchain reorgs of one or two blocks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.