<blockquote>
<p>my unique index for Bitcoin transactions is a combination of these three: txid:vout:address</p>
</blockquote>
<p>That seems like it might be overkill. After all, the blockchain only uses <code>txid:vout</code> to uniquely identify transaction inputs.</p>
<blockquote>
<p>would there be other edge case scenarios that might need special validation logic?</p>
</blockquote>
<p>I don't know, but maybe you need to consider how you handle blockchain reorgs of one or two blocks.</p>

CC BY-SA 4.0
2023-02-21T10:18:41.363Z
2023-02-21T10:18:41.363Z
RedGrittyBrick
<p>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.</p>
<ol>
<li>A new deposit address is generated with <a href="https://developer.bitcoin.org/reference/rpc/getnewaddress.html" rel="nofollow noreferrer">getnewaddress</a></li>
<li>Every minute a job runs and calls <a href="https://developer.bitcoin.org/reference/rpc/listsinceblock.html" rel="nofollow noreferrer">listsinceblock</a> with the <code>target_confirmations</code> set to 6 (so that my database transaction records update up to 6 confirmations)</li>
</ol>
<p>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.</p>
<p>Initially my business logic was having the <code>txid</code> 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 <code>txid</code> 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 <code>vout</code> index within the transaction.</p>
<p>So right now my unique index for Bitcoin transactions is a combination of these three: <code>txid:vout:address</code></p>
<p>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).</p>

<bitcoin-core><transactions><bitcoind><json-rpc>
Edge cases when dealing with incoming Bitcoin transactions
Carlos
# Edge cases when dealing with incoming Bitcoin transactions

(Asked by: username_0 on 2023-02-18)

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](https://developer.bitcoin.org/reference/rpc/getnewaddress.html)
2. Every minute a job runs and calls [listsinceblock](https://developer.bitcoin.org/reference/rpc/listsinceblock.html) 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).

**Tags:** bitcoin-core, transactions, bitcoind, json-rpc


---

## 1 answers

### Answer by username_1 on 2023-02-21. Score: 1 | Accepted answer

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


---

