<p>Each node in the network accepts any transactions with a higher sequence field (in TxIn) as long as the transaction isn't locked (lock time hasn't expired).</p>

<p>This can't be used as an attack because the client is aware the transaction is unlocked and thus could be modified.  The client (and thus any merchant) will/should treat the transaction as even less secure than an unconfirmed one.  </p>

<p>To protect oneself the merchant just needs to wait until the lock time has expired (then transaction is similar to any other 0-confirm transaction) and for even more security wait for 1 to 6 confirmations.</p>

<p>Currently the client only supports lock time of 0 (lock as soon as created) and sequence of max UINT (no possible higher sequence) which prevents modifying transactions.</p>

CC BY-SA 3.0
2011-12-29T21:52:27.497Z
2011-12-29T21:52:27.497Z
DeathAndTaxes
<p>Further to <a href="https://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence">this question</a>, how does the network determine whether to accept a new version of a transaction as a replacement transaction? Could an attacker replace transactions maliciously?</p>

<transactions><revert-transaction>
How does the network determine whether to replace a transaction?
jl6
# How does the network determine whether to replace a transaction?

(Asked by: username_0 on 2011-12-29)

Further to [this question](https://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence), how does the network determine whether to accept a new version of a transaction as a replacement transaction? Could an attacker replace transactions maliciously?

**Tags:** transactions, revert-transaction


---

## 1 answers

### Answer by username_1 on 2011-12-29. Score: 3

Each node in the network accepts any transactions with a higher sequence field (in TxIn) as long as the transaction isn't locked (lock time hasn't expired).

This can't be used as an attack because the client is aware the transaction is unlocked and thus could be modified. The client (and thus any merchant) will/should treat the transaction as even less secure than an unconfirmed one.

To protect oneself the merchant just needs to wait until the lock time has expired (then transaction is similar to any other 0-confirm transaction) and for even more security wait for 1 to 6 confirmations.

Currently the client only supports lock time of 0 (lock as soon as created) and sequence of max UINT (no possible higher sequence) which prevents modifying transactions.


---

