2

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.

Improve this question
4
  • 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?
    – Pieter Wuille
    Commented Dec 12, 2022 at 14:50
  • 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
    Commented Dec 12, 2022 at 21:29
  • 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.
    – Pieter Wuille
    Commented Dec 12, 2022 at 21:34
  • I don't know anymore.
    – Mercedes
    Commented Dec 13, 2022 at 14:18

1 Answer 1

Reset to default
2

From BIP 125:

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

Improve this answer
2
  • 2
    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 ♦
    Commented Dec 12, 2022 at 15:37
  • @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
    Commented Dec 12, 2022 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.