Full RBF

[o_e_l_e_o]

It is about joining and splitting one-input-one-output entries, where all participants can do that, but if things will finalize, then they will look like any ordinary SIGHASH_ALL transaction.

I still don't think that solves the problem. Even if we ignore the fact that contributing one input and one output makes it almost trivial to deanonymize you simply by matching output amounts to input amounts, then Carol can still attack the process. Even if the other parties can simply remove Carol's contribution to the transaction and try again, then she has still succeeded in wasting their time. A large enough entity (think another coinjoin provider attacking their competition) could easily spam enough inputs to make this happen over and over and over.

[o_e_l_e_o]

Bump.

There's been another recent flurry of discussion regarding this on the mailing list and GitHub, which stemmed from this post by one of the developers of Muun wallet: [Opt-in full-RBF] Zero-conf apps in immediate danger

His concerns are essentially that full RBF means all their zero confirmation functionality, include submarine swaps and various instant Lightning sends, become too risky and they would have to cease immediately. This spawned a lot of discussion which you can read if you are interested. There is a good summary of the whole issue from Gloria Zhao available here: https://github.com/glozow/bitcoin-notes/blob/full-rbf/full-rbf.md

The discussion spawned several more pull requests:
https://github.com/bitcoin/bitcoin/pull/26287 - remove the full RBF option from 24.0 entirely, and potentially introduce it in 25.0 with a default setting of true
https://github.com/bitcoin/bitcoin/pull/26305 - leave the full RBF option in 24.0 with a default setting of false, and turn the default setting to true in 25.0
https://github.com/bitcoin/bitcoin/pull/26323 - leave the full RBF option in 24.0 but change the default setting to true, but it does not activate until May 1st, 2023
https://github.com/bitcoin/bitcoin/pull/26438 - remove full RBF option entirely

It's not clear yet what the final outcome here is going to be. There seems to be consensus for the full RBF option defaulting to true at some point in the future, but not clear yet if that will be 25.0, a future version, a fixed date 6/12/18 months in the future, or some other point depending on network uptake. Whether or not 24.0 still ships with the full RBF option included but set to false by default is not so clear at the moment, but I suspect it will go ahead as was originally planned.

[BlackHatCoiner]

Pretty searing discussion there. Essentially and summarily, there are mainly two groups; those who find it only theoretically possible to have zeroconf transactions double-spent, and those who find it both practically and theoretically possible.

Pro-full-RBF users' arguments are:

• It's the natural state of the network.
• It's a false sense of security, because miners must be considered to always have full RBF enabled, because they follow profit.
• Defends against CoinJoin and Lightning related DoS attacks.

Pro-postponing-full-RBF users' arguments are

• Some businesses accept zeroconf as settled, and must either move to Lightning or withdraw this policy.
• Lightning and CoinJoin software needs upgrade.

(Anti-full-RBF users' arguments are mostly invalid IMO, especially due to complete dependence of transaction fees after a few decades)


I'm of the latter. We should postpone it for a little longer, at least until significantly used wallet software such as Muun upgrade. Most Internet-based businesses will have to switch from zeroconf to Lightning this year.

[NotATether]

The discussion spawned several more pull requests:
https://github.com/bitcoin/bitcoin/pull/26287 - remove the full RBF option from 24.0 entirely, and potentially introduce it in 25.0 with a default setting of true
https://github.com/bitcoin/bitcoin/pull/26305 - leave the full RBF option in 24.0 with a default setting of false, and turn the default setting to true in 25.0
https://github.com/bitcoin/bitcoin/pull/26323 - leave the full RBF option in 24.0 but change the default setting to true, but it does not activate until May 1st, 2023
https://github.com/bitcoin/bitcoin/pull/26438 - remove full RBF option entirely

It's not clear yet what the final outcome here is going to be. There seems to be consensus for the full RBF option defaulting to true at some point in the future, but not clear yet if that will be 25.0, a future version, a fixed date 6/12/18 months in the future, or some other point depending on network uptake. Whether or not 24.0 still ships with the full RBF option included but set to false by default is not so clear at the moment, but I suspect it will go ahead as was originally planned.

v24.0 is about to be released and is almost off the assembly line so I don't see them making a last-miniute change to that release considering the kind of peer-review process PRs get and the deterministic building procedure for each release. Any change will likely affect v25.0 at the earliest.

[DaveF]

IMO, part of the issue is that if we take this forum as a small microcosm of bitcoin enthusiasts this post about Full RBF in 4 months got a whopping 44 replies.
People are not paying attention to it, and the people who are using software that is going to be effected by it seem to be taking their time in dealing with it.
Should they have been more proactive? Probably. Is it important that we start Full RBF now, nope not really (at least in my view).

I am on the side that would like to see them deal with this a different way, but my way would probably cause more issues for non tech users and generate about eleventy billion lines of spaghetti code so there is that.....

-Dave

[BlackHatCoiner]

The problem with disabled RBF is that it relies on Bitcoin users' sincerity for transaction settlement, oppositely to RBF, which relies on miners' profit. Running a full node does grant you an opinion, because you're enforcing both consensus and non-consensus rules, but you should not rely to the latter. Miners can, and should, dump non-RBF double-spends, but I hold no sway to the way they'll choose to do business. Ultimately, they decide if they'll put profit above this pseudo-rule.

Disabled-RBF Is fundamentally flawed, because the system is designed to work trustlessly, and transactions that pay the most ought to, naturally, have advantage.

[o_e_l_e_o]

People are not paying attention to it, and the people who are using software that is going to be effected by it seem to be taking their time in dealing with it.

Marco Falke noted that in his pull request here: https://github.com/bitcoin/bitcoin/pull/26287. Full RBF has been discussed for years. It's pretty surprising that developers of projects which accept/depend on zero confirmation transactions are only learning about it now.

Lots more discussion on this pull request in the last couple of days, and now another new one from Andrew Chow - https://github.com/bitcoin/bitcoin/pull/26456.
This one removes the setting from 24.0 entirely simply to allow 24.0 to be released and to allow ongoing discussion regarding full RBF to happen, but even that seems to be contentious.

Disabled-RBF Is fundamentally flawed, because the system is designed to work trustlessly, and transactions that pay the most ought to, naturally, have advantage.

As noted in the mailing list discussion, this is the natural state of the system, and as the block subsidy falls and fees make up a larger and larger proportion of miners' income, then they are more and more likely to start accepting higher paying replacement transactions even if the original is opted out of RBF.

[NeuroticFish]

I have a feeling that the services relying on non-RBF transactions may have a small edge / advantage over the competition (since 0 conf is a good advertising and attracts users) hence they're not eager to change.

So while it could be a nice gesture to postpone the full RBF a little, we may have the exact same problem on the next release too.

[o_e_l_e_o]

So while it could be a nice gesture to postpone the full RBF a little, we may have the exact same problem on the next release too.

Absolutely, but I think it is the right thing to do for two reasons. I understand the points that this is only a setting which is defaulted to off, and actually any node or miner who wants to run a full RBF policy can do so at any time even without this setting. However, I don't think it is right to release a feature which has divided opinion so strongly without spending a bit of time working things out, and it would also give the developers and services which seem to have been caught off guard by this change some more time to react. Although this has been discussed for years, and the developers in question really should have done a better job of keeping up to speed with ongoing developments, I don't think it's a good look for the community to now say "Well, sucks to be you" and release a feature which some developers are saying will completely break their app/software/business model.

Now, as I said above, full RBF is the natural state of the system, not to mention the necessary benefits it brings to allow further development of Lightning and other projects, and so I fully expect it to arrive in v25.0 if not in v24.0. But I don't think delaying it from v24.0 is necessarily a bad thing, and if we did, then hopefully by the time v25.0 comes round many of these issues would have been discussed and resolved.

[o_e_l_e_o]

So looks like all the pull requests linked to previously have now been closed, meaning that 24.0 will ship as originally planned with the mempoolfullrbf option present but default set to false. And with 24.0 being bumped to rc4, we are probably only a few days away from release.

Will be interesting to see what the general mempool policy turns out to be and how quickly nodes and miners start enabling the option. There is already some financial incentive for miners to start adopting full RBF, not just from people attempting to replace non-RBF flagged transactions but also from this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html

I suspect we will pretty quickly start to see services which offer zero confirmation deposits or payments stop doing so. I suspect there will also be a handful of services which are unaware of this change being scammed.

[ABCbits]

Will be interesting to see what the general mempool policy turns out to be and how quickly nodes and miners start enabling the option.

I don't expect node operator bother change default option. It's already proved with lack of node which accept transaction with fee lower than 1 sat/vbyte or non-standard transaction.

There is already some financial incentive for miners to start adopting full RBF, not just from people attempting to replace non-RBF flagged transactions but also from this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html

Starting from $100/block? It's rather generous considering coming from an individual.

[o_e_l_e_o]

I don't expect node operator bother change default option. It's already proved with lack of node which accept transaction with fee lower than 1 sat/vbyte or non-standard transaction.

I also think the majority of non-mining node operators probably won't bother to change the default, but that is different for mining node operators. All it takes is one large miner to start enabling the setting on all their nodes and start claiming the additional rewards for other miners to want in on that too. And with the success of things like transaction accelerators, a miner could offer their services out to the community and invite people to broadcast RBF transactions directly to them so they know they are getting seen.

It will be a bit haphazard to begin with, but I suspect that prior to the setting being changed to true by default in future version that we will effectively be running a full RBF system across the network already.

[BrotherCreamy]

My 2c:

Full RBF is the only option that makes sense.

The RBF behaviour is not part of Bitcoin, it's just a node implementation detail.
Anything prior to consensus is not sacred. As long as a block follows consensus rules, it is valid, regardless of what transactions it includes from the mempool.

This is a key difference between Bitcoin and the shitcoins.
Bitcoin doesn't try to get fancy implementing all kind of "social consensus" rules and other such stupid non-deterministic things.

Users expect determinism and reliability out of the Bitcoin network. There should be no features which rely on the goodwill of node operators.
This would be akin to building an extension to your stone fortress out of paddlepop sticks.

The same goes for any feature which attempts to treat the mempool as sacred.
The mempool is a resource to be plundered in the greediest way possible. It is a Herbalife salesperson's phonebook.
Any implementation details which try to get nodes to treat mempool txns in a particular fashion is foolish.

Miners ought to order transactions by fee revenue and nothing else, otherwise they are in the wrong industry.
If there are 50 pending blocks, and I submit a transaction with a higher sats/vb than the rest, rational miners should include my transaction first before all the others even though my transaction is the newest.

[o_e_l_e_o]

Full RBF is the only option that makes sense.

I agree, but as I said above, it is obvious that many entities and businesses which depend on risk assessed zero confirmation transactions for much of their functioning were caught unaware by this change. Now you can argue that is their own fault, since this has been discussed for years, but I don't think it would be wrong to give them more time to adjust their inner workings to be compatible with this change.

Having said all that, though, it isn't going to happen. 24.0 has already been finalized and will be released with mempoolfullrbf as planned, and yet another pull request to revert it has been fairly widely NACKed.

[o_e_l_e_o]

alternative full node implementation usually just follow default Bitcoin Core behavior

True, but in this case, Knots has supported full RBF for a long time now, and if a Core node really wanted to run full RBF they could do that too with very minimal code changes. Relying on zero confirmation transactions has always had an associated risk, and was always dependent on nodes not implementing full RBF, which they could have done at any time.

[NotATether]

alternative full node implementation usually just follow default Bitcoin Core behavior

True, but in this case, Knots has supported full RBF for a long time now, and if a Core node really wanted to run full RBF they could do that too with very minimal code changes. Relying on zero confirmation transactions has always had an associated risk, and was always dependent on nodes not implementing full RBF, which they could have done at any time.

Well now they have at least another year to decommission their zero-conf transaction scanning, and move to Lightning Network instead. All the major payment gateways support it, so I see no reason why an in-house solution shouldn't be able to do the same.

[BlackHatCoiner]

Users expect determinism and reliability out of the Bitcoin network. There should be no features which rely on the goodwill of node operators.

Exactly, but that's not bad. Merchants and customers should rather rely on the good will of their between relation, not on the Bitcoin network. If a customer is malicious, it doesn't matter much if most nodes choose to not propagate transactions that double spend an RBF-disabled transaction; he's surely discouraged to try, but there are alternatives such as miner bribing.

On the other hand, if there's a good relation between the merchant and the customer, regardless of whether the transaction opts-in for RBF or not, there won't be double-spends. And I don't know about you, but I mostly have good relations with those I transact with.


Question: how hard is it to full the network with nodes that have Full RBF? Could you setup multiple full nodes in one machine without anybody knowing one person is running all?

[o_e_l_e_o]

And I don't know about you, but I mostly have good relations with those I transact with.

Sure, but you also have to consider entities such as Muun wallet or Bitrefill which have tens or even hundreds of thousands of users. Impossible for them to build a relationship with each one. (I named these two specifically since they were involved in the above linked discussions on GitHub and the mailing list.)

Could you setup multiple full nodes in one machine without anybody knowing one person is running all?

Sure, but it wouldn't really achieve much if almost every other node continues to run opt in RBF and rejects all the replacement transactions you broadcast. Or more to the point, unless major miners update their nodes to start accepting full RBF replacements.

[DaveF]

And I don't know about you, but I mostly have good relations with those I transact with.

Sure, but you also have to consider entities such as Muun wallet or Bitrefill which have tens or even hundreds of thousands of users. Impossible for them to build a relationship with each one. (I named these two specifically since they were involved in the above linked discussions on GitHub and the mailing list.)

Could you setup multiple full nodes in one machine without anybody knowing one person is running all?

Sure, but it wouldn't really achieve much if almost every other node continues to run opt in RBF and rejects all the replacement transactions you broadcast. Or more to the point, unless major miners update their nodes to start accepting full RBF replacements.

I don't see the big deal with Bitrefill. I use them on almost a daily basis now that they have bill payments too. Waiting for a confirm for a GC is not a big deal, and payments seem to go out overnight anyway.
RBF / no RBF I don't see why they would be caring that much either way anyway. Have to go read what they have said.

I understand what they are trying to do and why they are trying to do it, I just think as do some others that we would be better off drawing a line in the sand and saying as of THIS DATE (or block number) it is happening. That one last warning so to speak.

-Dave

[BlackHatCoiner]

Sure, but you also have to consider entities such as Muun wallet or Bitrefill which have tens or even hundreds of thousands of users. Impossible for them to build a relationship with each one. (I named these two specifically since they were involved in the above linked discussions on GitHub and the mailing list.)

Yes, indeed. I was referring to smaller businesses, which are more in number. Bitrefill, as a successful business, ought to switch to lightning.

Sure, but it wouldn't really achieve much if almost every other node continues to run opt in RBF and rejects all the replacement transactions you broadcast. Or more to the point, unless major miners update their nodes to start accepting full RBF replacements.

More nodes that have Full RBF means more chances for everyone to establish connection with nodes that have Full RBF. Therefore, more chances for an attacker to take a user's transaction and hand it over to the miner.