<p>From <a href="https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#summary" rel="nofollow noreferrer">BIP 125</a>:</p>
<blockquote>
<p>A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).</p>
</blockquote>
<p>The <a href="https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean">nSequence</a> in a transaction is used for other things including locktimes so it is unlikely to ever be removed entirely.</p>
<blockquote>
<p>In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),
then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?</p>
</blockquote>
<p>&quot;Ignoring pro zeroconf nodes&quot; doesn't make much sense unless they are attempting to change the consensus rules or seeking to reject blocks with replace-by-fee transactions in them. In that case we would be in consensus rule &quot;war&quot; territory like with the block size wars but that would be a very strange route to take given altcoins like BCH already exist which aren't seeking to scale off-chain and are perhaps more open to prioritizing the zero conf use case. It is possible full nodes could preferentially peer with other nodes who have the <code>-mempoolfullrbf</code> option turned on in future. However, in the Bitcoin Core 24.0 release it is off by default and there is no preferential peering based on this issue.</p>
<blockquote>
<p>Would the RBF bit be then set for removal in a subsequent soft fork?</p>
</blockquote>
<p>It wouldn't need a soft fork or a consensus change to simply ignore the transaction signaling for RBF by default in a Bitcoin implementation like Bitcoin Core. I very much doubt Bitcoin Core would ever make RBF a consensus issue, it is a mempool policy issue. It is possible Bitcoin Core could change policy defaults and policy options available to users in future. This is pure speculation of course though, I don't know what will happen in the future and no one can speak for Bitcoin Core, certainly not me.</p>
<blockquote>
<p>And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?</p>
</blockquote>
<p>It is possible the default for the <code>-mempoolfullrbf</code> option could be changed in future and it is also possible the <code>-mempoolfullrbf</code> option could be removed in future. As I said, we're moving into speculating future changes in Bitcoin Core releases. Any future change would need to have a pull request opened, reviewed, merged and included in a release. As you stated this is in the realm of policy and not consensus so I highly doubt this would be relevant to a future soft fork but I guess there is a speculative element to that too as I can't envisage every possible future soft fork design.</p>

CC BY-SA 4.0
2022-12-12T15:37:16.340Z
Good answer. I think that one thing that would align well with the question post would be to get into what the default value for `nSequence` could be if fullrbf is widely adopted on the network.
Murch
CC BY-SA 4.0
2022-12-12T18:10:35.687Z
@Murch: Good question. I'd say the default `nSequence` wouldn't change if Core changed the default to -mempoolfullrbf=1 or even if Core did that *and* got rid of the option entirely. At least theoretically some other implementation(s) might still require RBF signaling to accept a transaction into their mempool. So unless there was a reason to change the default `nSequence` you'd leave it as is so those theoretical implementations also accepted the transaction into their mempool? Agree?
Michael Folkson
CC BY-SA 4.0
2022-12-12T14:41:45.530Z
2022-12-12T15:47:44.727Z
2022-12-12T15:47:44.727Z
Michael Folkson
<p>In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),<br />
then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?</p>
<p>Would the RBF bit be then set for removal in a subsequent soft fork?</p>
<p>And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?</p>
<p>I'm using &quot;ignore&quot; instead of &quot;ban&quot; because I suppose pro-zeroconf would be policy instead of consensus.</p>

CC BY-SA 4.0
2022-12-12T14:50:08.457Z
What is a "pro-zeroconf" node? A node that implements the BIP125 relay policy? A node that does not permit any transaction to be replaced? Something else?
Pieter Wuille
CC BY-SA 4.0
2022-12-12T21:29:39.297Z
I can't tell, after rereading BIP 125. RBF-FSS is still a thing, I guess. Then I tried thinking about nodes banning blocks because mempool features instead of because consensus, and I can't figure how could this be done without risking censorship resistance.
Mercedes
CC BY-SA 4.0
2022-12-12T21:34:40.203Z
RBF-FSS is something else, much older, and unrelated to fullrbf or BIP125. You're inventing the term "pro-zeroconf" here; I'm just asking what you mean by that.
Pieter Wuille
CC BY-SA 4.0
2022-12-13T14:18:11.170Z
I don't know anymore.
Mercedes
<consensus><mempool><replace-by-fee>
persistence of the RBF bit in post-fullrbf chain
Mercedes
# persistence of the RBF bit in post-fullrbf chain

(Asked by: username_0 on 2022-12-12)

In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),  
then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?

Would the RBF bit be then set for removal in a subsequent soft fork?

And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?

I'm using "ignore" instead of "ban" because I suppose pro-zeroconf would be policy instead of consensus.

**Tags:** consensus, mempool, replace-by-fee

> **Comments:**
> **username_1**: What is a "pro-zeroconf" node? A node that implements the BIP125 relay policy? A node that does not permit any transaction to be replaced? Something else?  
> **username_0**: I can't tell, after rereading BIP 125. RBF-FSS is still a thing, I guess. Then I tried thinking about nodes banning blocks because mempool features instead of because consensus, and I can't figure how could this be done without risking censorship resistance.  
> **username_1**: RBF-FSS is something else, much older, and unrelated to fullrbf or BIP125. You're inventing the term "pro-zeroconf" here; I'm just asking what you mean by that.  
> **username_0**: I don't know anymore.  

---

## 1 answers

### Answer by username_2 on 2022-12-12. Score: 2

From [BIP 125](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#summary):

> A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).

The [nSequence](https://bitcoin.stackexchange.com/questions/87372/what-does-the-sequence-in-a-transaction-input-mean) in a transaction is used for other things including locktimes so it is unlikely to ever be removed entirely.

> In case consensus decided to ignore pro-zeroconf nodes (in case that is or can be a thing),
> then what's the point of having the RBF bit in a transaction, if everything in the system is enforcing RBF (either explicitly or implicitly)?

"Ignoring pro zeroconf nodes" doesn't make much sense unless they are attempting to change the consensus rules or seeking to reject blocks with replace-by-fee transactions in them. In that case we would be in consensus rule "war" territory like with the block size wars but that would be a very strange route to take given altcoins like BCH already exist which aren't seeking to scale off-chain and are perhaps more open to prioritizing the zero conf use case. It is possible full nodes could preferentially peer with other nodes who have the `-mempoolfullrbf` option turned on in future. However, in the Bitcoin Core 24.0 release it is off by default and there is no preferential peering based on this issue.

> Would the RBF bit be then set for removal in a subsequent soft fork?

It wouldn't need a soft fork or a consensus change to simply ignore the transaction signaling for RBF by default in a Bitcoin implementation like Bitcoin Core. I very much doubt Bitcoin Core would ever make RBF a consensus issue, it is a mempool policy issue. It is possible Bitcoin Core could change policy defaults and policy options available to users in future. This is pure speculation of course though, I don't know what will happen in the future and no one can speak for Bitcoin Core, certainly not me.

> And if that were the case, why not remove it the first moment pro-zeroconf nodes are ignored?

It is possible the default for the `-mempoolfullrbf` option could be changed in future and it is also possible the `-mempoolfullrbf` option could be removed in future. As I said, we're moving into speculating future changes in Bitcoin Core releases. Any future change would need to have a pull request opened, reviewed, merged and included in a release. As you stated this is in the realm of policy and not consensus so I highly doubt this would be relevant to a future soft fork but I guess there is a speculative element to that too as I can't envisage every possible future soft fork design.

> **Comments:**
> **username_3**: Good answer. I think that one thing that would align well with the question post would be to get into what the default value for `nSequence` could be if fullrbf is widely adopted on the network.  
> **username_2**: @username_3: Good question. I'd say the default `nSequence` wouldn't change if Core changed the default to -mempoolfullrbf=1 or even if Core did that *and* got rid of the option entirely. At least theoretically some other implementation(s) might still require RBF signaling to accept a transaction into their mempool. So unless there was a reason to change the default `nSequence` you'd leave it as is so those theoretical implementations also accepted the transaction into their mempool? Agree?  

---

