Edge cases when dealing with incoming Bitcoin transactions

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).

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).