<p>In essence, that is exactly what it is: an RBF transaction is simply a new, distinct transaction.</p>
<p>The RBF aspect, the rules associated with it, matter however. Full nodes maintain a list of transactions they expect to confirm (called their &quot;mempool&quot;), and in order to enter the mempool, and be relayed to other nodes, there are applicable rules.</p>
<p>One of those rules is that normally, an existing transaction in the mempool cannot be replaced by another. When RBF is enabled on the original, this is allowed under certain circumstances.</p>
<p>In short, while the replacement transaction is <strong>valid</strong> regardless of whether the original opted in the RBF, that does not mean it will necessarily be <strong>accepted</strong> by nodes and propagated across the network to miners.</p>

CC BY-SA 4.0
2024-04-14T10:17:44.513Z
Essentially it is a new transaction that is double spending the UTXO that has already been "spent" (is in the mempool). The nodes need some sort of rules to decide which transaction to pick up and send to miners. To prevent spamming attacks I believe that initially the RBF rule was that the new transaction had to have a higher fee than the one it is replacing. Is this still the case?
user2334659
CC BY-SA 4.0
2024-04-12T19:46:48.253Z
2024-04-12T19:46:48.253Z
Pieter Wuille
<p>If I am sending a new RBF transaction to replace my stuck transaction and since the txid preimage has outputs value it will change the txid then why do we even care about RBF and nsequence &lt; 0xffffffff since it will never come into effect ? Correct me If I am wrong fundamentally somewhere .</p>

<transactions><unconfirmed-transactions><replace-by-fee>
Does new transaction in RBF has a txid different from the stuck transaction ? If yes , then isn't it basically creating a new transaction?
Prabhat Verma
# Does new transaction in RBF has a txid different from the stuck transaction ? If yes , then isn't it basically creating a new transaction?

(Asked by: username_0 on 2024-04-12)

If I am sending a new RBF transaction to replace my stuck transaction and since the txid preimage has outputs value it will change the txid then why do we even care about RBF and nsequence < 0xffffffff since it will never come into effect ? Correct me If I am wrong fundamentally somewhere .

**Tags:** transactions, unconfirmed-transactions, replace-by-fee


---

## 1 answers

### Answer by username_1 on 2024-04-12. Score: 3

In essence, that is exactly what it is: an RBF transaction is simply a new, distinct transaction.

The RBF aspect, the rules associated with it, matter however. Full nodes maintain a list of transactions they expect to confirm (called their "mempool"), and in order to enter the mempool, and be relayed to other nodes, there are applicable rules.

One of those rules is that normally, an existing transaction in the mempool cannot be replaced by another. When RBF is enabled on the original, this is allowed under certain circumstances.

In short, while the replacement transaction is **valid** regardless of whether the original opted in the RBF, that does not mean it will necessarily be **accepted** by nodes and propagated across the network to miners.

> **Comments:**
> **username_2**: Essentially it is a new transaction that is double spending the UTXO that has already been "spent" (is in the mempool). The nodes need some sort of rules to decide which transaction to pick up and send to miners. To prevent spamming attacks I believe that initially the RBF rule was that the new transaction had to have a higher fee than the one it is replacing. Is this still the case?  

---

