What prevents a malicious user creating a new transaction using signatures of an old mined transaction if the inputs have the exact same balance?

3

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.

D. Doshi

Posted 2018-04-21T13:59:07.297

Reputation: 33

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

pebwindkraft 2018-04-21T18:14:01.997

Answers

3

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

Murch

Posted 2018-04-21T13:59:07.297

Reputation: 41 609

note that there is a repeating txid on the blockchain.Albert s 2018-04-22T06:40:15.843

@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 2018-04-22T14:18:55.220

2In 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 2018-04-22T18:37:21.163

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.

Raghav Sood

Posted 2018-04-21T13:59:07.297

Reputation: 10 897