<p>Every full node keeps track of all unspent transaction outputs (UTXO). UTXO are identified via their outpoint <code>txid:vout</code>, where <code>txid</code> is the transaction identifier of the transaction that created it, and <code>vout</code> is the output position within this transaction. Transaction ids are generally unique, and thus each outpoint can only occur once as well.¹</p>
<p>To spend any bitcoins, one must reference the UTXO that are used in the inputs. Thus, replaying the transaction will be infeasible as new UTXO received to the same address will differ in their outpoint and thus the replayed transaction will referenced the old, already spent inputs.</p>
<hr />
<p><sup>¹ There are two pairs of colliding <code>txid</code> in the blockchain from when miners created two coinbase transactions with the same inputs and outputs. Each caused one of the two outputs to become unspendable, as the first was still present when the second was created. To mitigate this issue, <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="nofollow noreferrer">BIP30</a> specified that duplicate txids may not be accepted in blocks unless all outputs of the older tx with the same id are spent. This duplication vector has since been resolved altogether by requiring coinbase transactions to cite the height of the block they are part of via <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP34</a>. It is now considered infeasible to generate txid collisions, and thus each UTXO is in all likelihood unique. H/T to Pieter Wuille for pointing out the relevant BIPs and corrections.</sup></p>

CC BY-SA 3.0
2018-04-22T06:40:15.843Z
note that there is a repeating txid on the blockchain.
Albert S
CC BY-SA 3.0
2018-04-22T14:18:55.220Z
@Alberts: Correct. Two coinbase transactions were created with the same txid. This was the reason to require coinbase transactions to cite the current height as referenced in my answer, making this duplication infeasible since. I've edited my answer to make the point clearer.
Murch
CC BY-SA 3.0
2018-04-22T18:37:21.163Z
In fact, there are two such pairs. They're both very old (pre block 100000), and later this practice was made invalid with BIP30 and BIP34.
Pieter Wuille
CC BY-SA 3.0
2018-04-22T05:12:07.600Z
2018-04-22T19:52:31.333Z
2020-06-16T11:10:03.350Z
Murch
<p>The transaction ID and output index of the second 1 BTC that was sent to A's address will be different from the first 1 BTC that was sent there. Since transactions refer to inputs by their txid and output index, the signature used in the first transaction will not be valid for another tx trying to spend the second deposit.</p>

<p>Additionally, depending on the type of Signature, it may also restrict that the output can only go to B's address.</p>

CC BY-SA 3.0
2018-04-21T14:23:01.543Z
2018-04-21T14:23:01.543Z
Raghav Sood
<p>I am NOT talking about double spending. I am talking about this type of scenario: </p>

<p>Let's say address A has 1 BTC balance initially. A valid transaction is created and for simplicity's sake, assume all the balance is transferred to address B in a valid manner. </p>

<p>Okay, now that transaction has been confirmed and A has also received another 1 BTC from some other random address. </p>

<p>Now, what prevents a malicious user, to rebroadcast the old transaction as the same conditions are being met. The input has the exact same balance, the old signature is telling to send the balance to B etc. </p>

<p>Obviously, this would mean it would be the same transaction ID and the network would reject it. So my question is, what is the variable in a transaction that allows you to prevent this type of attack? I can't find any documentation. </p>

CC BY-SA 3.0
2018-04-21T18:14:01.997Z
There is more to a tx than value and signature... The details of what is signed have been shown in the answer section here: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
pebwindkraft
<replay-attack><utxo-set>
What prevents a malicious user creating a new transaction using signatures of an old mined transaction if the inputs have the exact same balance?
D. Doshi
# What prevents a malicious user creating a new transaction using signatures of an old mined transaction if the inputs have the exact same balance?

(Asked by: username_0 on 2018-04-21)

I am NOT talking about double spending. I am talking about this type of scenario:

Let's say address A has 1 BTC balance initially. A valid transaction is created and for simplicity's sake, assume all the balance is transferred to address B in a valid manner.

Okay, now that transaction has been confirmed and A has also received another 1 BTC from some other random address.

Now, what prevents a malicious user, to rebroadcast the old transaction as the same conditions are being met. The input has the exact same balance, the old signature is telling to send the balance to B etc.

Obviously, this would mean it would be the same transaction ID and the network would reject it. So my question is, what is the variable in a transaction that allows you to prevent this type of attack? I can't find any documentation.

**Tags:** replay-attack, utxo-set

> **Comments:**
> **username_1**: There is more to a tx than value and signature... The details of what is signed have been shown in the answer section here: https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx  

---

## 2 answers

### Answer by username_2 on 2018-04-22. Score: 3 | Accepted answer

Every full node keeps track of all unspent transaction outputs (UTXO). UTXO are identified via their outpoint `txid:vout`, where `txid` is the transaction identifier of the transaction that created it, and `vout` is the output position within this transaction. Transaction ids are generally unique, and thus each outpoint can only occur once as well.¹

To spend any bitcoins, one must reference the UTXO that are used in the inputs. Thus, replaying the transaction will be infeasible as new UTXO received to the same address will differ in their outpoint and thus the replayed transaction will referenced the old, already spent inputs.

---

¹ There are two pairs of colliding `txid` in the blockchain from when miners created two coinbase transactions with the same inputs and outputs. Each caused one of the two outputs to become unspendable, as the first was still present when the second was created. To mitigate this issue, [BIP30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) specified that duplicate txids may not be accepted in blocks unless all outputs of the older tx with the same id are spent. This duplication vector has since been resolved altogether by requiring coinbase transactions to cite the height of the block they are part of via [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki). It is now considered infeasible to generate txid collisions, and thus each UTXO is in all likelihood unique. H/T to username_4 username_4 for pointing out the relevant BIPs and corrections.

> **Comments:**
> **username_3**: note that there is a repeating txid on the blockchain.  
> **username_2**: @Alberts: Correct. Two coinbase transactions were created with the same txid. This was the reason to require coinbase transactions to cite the current height as referenced in my answer, making this duplication infeasible since. I've edited my answer to make the point clearer.  
> **username_4**: In fact, there are two such pairs. They're both very old (pre block 100000), and later this practice was made invalid with BIP30 and BIP34.  

---

### Answer by username_5 on 2018-04-21. Score: 4

The transaction ID and output index of the second 1 BTC that was sent to A's address will be different from the first 1 BTC that was sent there. Since transactions refer to inputs by their txid and output index, the signature used in the first transaction will not be valid for another tx trying to spend the second deposit.

Additionally, depending on the type of Signature, it may also restrict that the output can only go to B's address.


---

