Remove -mempoolfullrbf option

BitcoinErrorLog commented at 5:16 pm on November 17, 2022: none

Reverts #25353.

I am submitting this PR after many discussions with users, merchants, and Bitcoin Core developers.

They agree that the nuances of first-seen, full RBF, and zero-conf interactions are significant and controversial, and that given the current state of the discussion, and that full RBF may not solve the DoS issues that inspired it, the original PR would not have been merged in the first place.

I believe we should leave first-seen mempool policy intact. The arguments for this include miner incentive compatibility, maximization of fees per block through next-block priority-competition, utility for merchants and consumers, intelligent double-spend risk mitigation, protection of the user space, and optimization of Bitcoin adoption, utility, and activity.

I apologize for not yet having a reference link with full details of all of my arguments, but I am happy to interact with commenters on any arguments for a full RBF agenda here. I can also alleviate any concerns with current zero-conf acceptance risk mitigation.

I would appreciate being heard, and having a fair chance to be reviewed and considered.

I also need time for consideration because I am assisting some merchants and users with understanding how to interface with Bitcoin Core and what is happening, so they can express their support for this PR, and their value of zero-conf being useful as a service.

In the end, I am advocating for the Bitcoin network state that has thrived for its entire history so far, and asking that Bitcoin Core avoid steering policy.

Remove -mempoolfullrbf option

Reverts PR 25353.

c632df98a2

DrahtBot commented at 5:16 pm on November 17, 2022: contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type	Reviewers
Concept NACK	luke-jr, TrAyZeN, instagibbs, jnewbery, prusnak, Zero-1729, michaelfolkson, brunoerg, stickies-v, aureleoules, zndtoshi, SkanderHelali, nvk, acidtib, josibake, mzumsande, vostrnad, reardencode, ghost, ZenulAbidin, kaloudis, greenaddress, petertodd
Concept ACK	ziggamon, MiguelMedeiros, coreyphillips, Tigerix, proofofjogi, artdesignbySF, Transisto, shreyanjoshi, jayt87, krotkiewicz, sarafshailesh, greedyradar, benpbolton, tiero, jaredcobb, bitcoinheiro, SeverinAlexB, TheGuySwann, felcreate, ursuscamp, iBeizsley, i5hi, hsjoberg

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#28132 (policy: Enable full-rbf by default by petertodd)
#28130 (Remove arbitrary restrictions on OP_RETURN by default by petertodd)
#27832 (doc: Clarify -datacarriersize, add -datacarriersize=2 tests by MarcoFalke)
#26451 (Enforce incentive compatibility for all RBF replacements by sdaftuar)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

luke-jr commented at 5:20 pm on November 17, 2022: member

NACK. We’ve been over this already too many times.

asking that Bitcoin Core avoid steering policy.

Steering policy is exactly what this PR does.

TrAyZeN commented at 5:27 pm on November 17, 2022: none

NACK

instagibbs commented at 5:32 pm on November 17, 2022: member

We had copious amounts of debate already, status quo reigns

NACK

maflcko commented at 5:33 pm on November 17, 2022: member

My personal preference would have been to release 24.0 with something like #26456, but given that this was too controversial, and given that 24.0 is already released, I don’t think it makes sense to rehash the discussion right now.

Have you seen the previous discussion, for example #26438 (comment)? I don’t think there are any new arguments at the current time that would warrant a rehash.

jnewbery commented at 5:37 pm on November 17, 2022: contributor

NACK. Everyone has had a fair chance to express their opinions in #26438. Nothing has changed since then. Let’s not rehash the same arguments here.

ziggamon commented at 5:39 pm on November 17, 2022: none

ACK

The network is unprepared for this behavior change.

In the recent massive mempool spike less than 1% of transactions caught under it successfully used the RBF option to bump their transaction, despite 20-30% of them signalling the opt-in flag. See https://twitter.com/0xb10c/status/1592603590941880320?s=46&t=xkVv8ULO1nE8Q9vOd-WSeA

https://twitter.com/ziggamon/status/1592613046421426179?s=46&t=xkVv8ULO1nE8Q9vOd-WSeA

If this flag gets used by a subset of nodes or miners we will end up in a worst-of-both worlds scenario where some current modes of using bitcoin break, while no recourses become available to vast majority users. If RBF was widely used across different parts of the stack of things making bitcoin transactions that might have been a different story, but so far the market is clearly not selecting RBF, so forcing it on those who don’t is unlikely to create any of the benefits sought. Compare with fee estimation which is roughly equally old in bitcoin, but is used by the vast majority of transactions, to navigate the unpredictible blockspace market.

i agree with john that it’s worth reconsidering this.

BitcoinErrorLog commented at 5:41 pm on November 17, 2022: none

Steering policy is exactly what this PR does.

Gaslight. The current state of the Bitcoin network uses first-seen. I am arguing to keep that state intact.

BitcoinErrorLog commented at 5:43 pm on November 17, 2022: none

We had copious amounts of debate already, status quo reigns

Your definition of status quo has not been adopted by users yet. They have not been heard or fairly considered.

BitcoinErrorLog commented at 5:48 pm on November 17, 2022: none

24.0 is already released, I don’t think it makes sense to re-hash the discussion right now.

Have you seen the previous discussion, for example #26438 (comment)?

The release schedule for Core is not an actual deadline or proof of consensus by users, who were not heard.

Yes, I am aware of, and participated in the previous discussion to remove this feature, which was ack’d by Antoine Raird, the author of the feature, and, in my opinion, prematurely closed by Suhas after brigading/bullying.

I would appreciate giving Suhas the chance to reconsider as well.

prusnak commented at 5:49 pm on November 17, 2022: contributor

Duplicate of #26438

NACK

BitcoinErrorLog commented at 5:53 pm on November 17, 2022: none

NACK. Everyone has had a fair chance to express their opinions in #26438. Nothing has changed since then. Let’s not rehash the same arguments here.

I stated what has changed: Full RBF does not remove DoS issues, the author of the feature is willing to remove it, and the community is more educated and looking for a way to express support for the live network state.

I also have new arguments about incentive compatibility in that first-seen policy facilitates a priority competition for next-block inclusion because merchants require market fee rate to qualify for zero-conf.

This priority competition, combined with traditional RBF, may explain the current stasis of the network, as it provides full-spectrum fee saturation for both immediate and eventual block inclusion.

Zero-1729 commented at 5:54 pm on November 17, 2022: contributor

NACK

Already been through this.

luke-jr commented at 5:58 pm on November 17, 2022: member

The current state of the Bitcoin network uses first-seen. I am arguing to keep that state intact.

No, that isn’t the current state, and hasn’t been for years. Besides, keeping the state intact would still be steering anyway.

BitcoinErrorLog commented at 6:01 pm on November 17, 2022: none

No, that isn’t the current state, and hasn’t been for years. Besides, keeping the state intact would still be steering anyway.

More gaslight. Maybe it would be more productive to argue what full RBF solves, why it requires the assistance of this new feature, and why these are worth disrupting a useful use case of merchants for users.

luke-jr commented at 6:06 pm on November 17, 2022: member

You are the one gaslighting. Full RBF is not new, and does not disrupt anything.

sipa commented at 6:07 pm on November 17, 2022: member

No need to rehash this discussion.

ftrader commented at 6:22 pm on November 17, 2022: none

Hey @ziggamon , if you want to have some leverage on this issue, perhaps you should consider accepting Bitcoin Cash through 0-conf on Bitrefill.

With Double Spend Proofs your company could showcase how quick and easy Bitcoin payments can be.

BitcoinErrorLog commented at 6:26 pm on November 17, 2022: none

No need to rehash this discussion.

I would sincerely appreciate your argument as to why a full-RBF agenda should be steered by Bitcoin Core at the cost of the existing user space, as well as your refutation of any of my arguments within.

michaelfolkson commented at 6:26 pm on November 17, 2022: contributor

NACK

brunoerg commented at 6:26 pm on November 17, 2022: contributor

NACK

MiguelMedeiros commented at 6:28 pm on November 17, 2022: none

ACK

iBeizsley commented at 6:38 pm on November 17, 2022: none

Outsider/user-only perspective: I don’t feel strongly about the option existing or not existing, but I’m dubious about the reasoning behind full-RBF. First hearing about this controversy, my knee-jerk reaction was “the mempool can’t be trusted; that’s why we need PoW at all”, but having given it further thought:

Yes, accepting unconfirmed transactions is, and always has been, risky. I wouldn’t do it myself. But it’s not my place, or the place of anyone else, to prevent, or even ‘disincentivise’, others making that choice. If they choose to accept an unconfirmed transaction and get double-spent, they’re only hurting themselves.
Users not knowing about RBF and ending up with a non-RBF TX stuck in the mempool for a long time is not a Bitcoin Core concern. It’s a wallet concern. Wallets should flag RBF by default, or explicitly ask the user what they want per TX/on initialization.
Users accepting unconfirmed transactions unwittingly aren’t going to be prevented from doing so by full RBF. Again, wallet space.

I’ve not really heard any other arguments, besides mempool-split brain and issues w/ CoinJoin & multiparty contracts, but it doesn’t seem full-RBF actually fixes that.

Besides that, no, an unreleased piece of code is not ‘status quo’. It’s true that replacement of non-RBF transactions is already possible, but making it far easier with full-RBF is objectively not ‘maintaining the status quo’.

More than happy to hear other justifications for it. If there’s an actual tehcnical benefit to full-RBF, then we should adopt it by default. But honestly this whole thing feels quite political.

Edit: And to add, I think making it a concern of Bitcoin core to ‘disincentivise unsafe behaviour’ is a huge mistake. It’s taking on an additional responsibility you simply do not have at the moment, with potentially unlimited scope.

cculianu commented at 6:50 pm on November 17, 2022: none

“Never interrupt your adversaries when they are busy making a mistake.” –Sun Tzu

As a Bitcoin Cash developer I must say you should definitely leave RBF in and what’s more definitely make it the default and in fact maybe even do a relay rule that forbids any TXN without that flag. I think that’s what you guys should definitely be doing!

coreyphillips commented at 6:55 pm on November 17, 2022: none

ACK. There is no benefit or technical reason for the switch to full rbf. Understanding that this has been discussed ad-nauseam, it’s still worth pointing out and defending that changing params without technical reason should not be considered acceptable nor should it become an acceptable standard.

MiguelMedeiros commented at 6:57 pm on November 17, 2022: none

Outsider/user-only perspective: I don’t feel strongly about the option existing or not existing, but I’m dubious about the reasoning behind full-RBF. First hearing about this controversy, my knee-jerk reaction was “the mempool can’t be trusted; that’s why we need PoW at all”, but having given it further thought:

Yes, accepting unconfirmed transactions is, and always has been, risky. I wouldn’t do it myself. But it’s not my place, or the place of anyone else, to prevent, or even ‘disincentivise’, others making that choice. If they choose to accept an unconfirmed transaction and get double-spent, they’re only hurting themselves.

Users not knowing about RBF and ending up with a non-RBF TX stuck in the mempool for a long time is not a Bitcoin Core concern. It’s a wallet concern.

Users accepting unconfirmed transactions unwittingly aren’t going to be prevented from doing so by full RBF. Again, wallet space.

I’ve not really heard any other arguments, besides mempool-split brain and issues w/ CoinJoin & multiparty contracts, but it doesn’t seem full-RBF actually fixes that.

Besides that, no, an unreleased piece of code is not ‘status quo’. It’s true that replacement of non-RBF transactions is already possible, but making it far easier with full-RBF is objectively not ‘maintaining the status quo’.

More than happy to hear other justifications for it. If there’s an actual tehcnical benefit to full-RBF, then we should adopt it by default. But honestly this whole thing feels quite political.

I couldn’t agree more with your arguments @iBeizsley .

The part that bothers me the most is seeing the core developers thinking they have to defend users from their own stupidity and claiming it as ‘maintaining the status quo’ and it’s the exact opposite.

I saw many fallacies of: authority, straw man, ad hominem, generalization, etc. Therefore, I recommend rejecting any changes a priori, until this is truly a consensus, as there is no benefit or technical reason for moving to full rbf. I also note that this topic is very political and not very technical.

aureleoules commented at 7:24 pm on November 17, 2022: member

NACK

That’s one way to stress-test the new ACK tracker.

Tigerix commented at 7:37 pm on November 17, 2022: none

ACK I am user! No need to destroy the UX of Bitcoin with Full-RBF by doing so in the name of “Security”.

luke-jr commented at 7:38 pm on November 17, 2022: member

The part that bothers me the most is seeing the core developers thinking they have to defend users from their own stupidity

Strange comment, when it’s this PR that aims to remove user choice in the name of defending users(deluded merchants).

achow101 commented at 7:55 pm on November 17, 2022: member

At this point in time, i think this is pointless. 24.0 has already been tagged and already has numerous guix builds as well as code signatures. As such, this PR would only be included in 25.0+ or 24.1, which, as I understand it, defeats the purpose of removing the option. Users who want the option could just run 24.0. Even if we pulled 24.0, users could still just run 24.0rc4 which is functionally identical to 24.0 (the final release is just the last rc with the version number updated).

Please keep in mind that this option is default false.

In regards to “no technical reason”, I think the recent mempool situation perfectly illustrates why full RBF is useful. Users whose previously high feerate non-opt-in RBF transactions may have suddenly become low priority due to a sudden increase in transaction volume and subsequent rise in feerates. For such users, full RBF would allow them to bump their transactions to higher feerates in order to be confirmed in a timeframe closer to what they had expected with their original feerate.

If I see continued brigading or trolling of this thread, it will be locked. Consider yourselves warned.

iBeizsley commented at 8:01 pm on November 17, 2022: none

In regards to “no technical reason”, I think the recent mempool situation perfectly illustrates why full RBF is useful.

It shows the utility of RBF, which we already have. That’s not a technical argument for full-RBF.

stickies-v commented at 8:02 pm on November 17, 2022: contributor

NACK. The discussion has been had, let’s not waste more time on this. Zero-conf is only becoming riskier over time.

ghost commented at 8:07 pm on November 17, 2022: none

I would appreciate being heard, and having a fair chance to be reviewed and considered.

I think everyone had fair chance and enough time to comment in earlier PRs, mailing list, twitter etc.

In fact this got more attention than lot of other PRs even with lot of devs disagreeing to remove non-default option to use full RBF.

NACK

Tigerix commented at 8:25 pm on November 17, 2022: none

Unfortunately users are not on github!

If you would ask users if they want to wait 30 Minutes to use Lightning or use it instantly you would get a clear answer.

I find it really disappointing that Core Devs are more interested in their own agenda, than in the users!

luke-jr commented at 8:43 pm on November 17, 2022: member

If you would ask users if they want to wait 30 Minutes to use Lightning or use it instantly you would get a clear answer.

Unfortunately, that is not an option; and the deceptive false claim that it is, is half the problem!

BitcoinErrorLog commented at 8:43 pm on November 17, 2022: none

Strange comment, when it’s this PR that aims to remove user choice in the name of defending users(deluded merchants).

Merchants are not deluded, we use an elegant system for establishing a threshold of maximum exposure to zero-conf per block, per period, and lifetime maximum. We check if the txn has rbf off and require it match the fee-rate for likely inclusion in the next block before allowing order completion.

This makes the exposure exact and results in more txns, more commerce, more adoption, and more fees for miners.

luke-jr commented at 8:46 pm on November 17, 2022: member

Merchants are not deluded, we use an elegant system for establishing a threshold of maximum exposure to zero-conf per block, per period, and lifetime maximum. We check if the txn has rbf off and require it match the fee-rate for likely inclusion in the next block before allowing order completion.

Pretending the “rbf off” matters is delusional and discriminatory.

Tigerix commented at 8:49 pm on November 17, 2022: none

Pretending the “rbf off” matters is delusional and discriminatory.

“rbf off” worked very well since the inception of Bitcoin. I don’t know any users loosing money. So I don’t get where the urge comes from to kill it? It is a feature, not a bug in my opinion.

luke-jr commented at 8:53 pm on November 17, 2022: member

“rbf off” worked very well since the inception of Bitcoin. I don’t know any users loosing money.

Only because most people are honest and aren’t even trying to double spend them.

Tigerix commented at 8:56 pm on November 17, 2022: none

Only because most people are honest and aren’t even trying to double spend them.

Exactly, and if that is the case - great! Bitcoin is made for humans - and if they are honest - thats part of reality! Lets be practical about this: We can fix it any time - if humans change - and stealing becomes the default.

luke-jr commented at 8:58 pm on November 17, 2022: member

This PR has nothing to do with trusting customers to be honest. It also has nothing to do with wallet software making an option to double spend (they can continue to offer it only when the flag is set).

BitcoinErrorLog commented at 8:58 pm on November 17, 2022: none

At this point in time, i think this is pointless. 24.0 has already been tagged and already has numerous guix builds as well as code signatures. As such, this PR would only be included in 25.0+ or 24.1, which, as I understand it, defeats the purpose of removing the option. Users who want the option could just run 24.0. Even if we pulled 24.0, users could still just run 24.0rc4 which is functionally identical to 24.0 (the final release is just the last rc with the version number updated).

I cannot let a false rigidity in the current process be an argument for a change that is potentially this disruptive and contrary to the Bitcoin we use today. This is a special circumstance in that it may affect an abnormally high quantity of transactions by opting them into a new behavior they did not choose.

It is also special in that the users it affects are not familiar with the process or how to interface with Bitcoin Core.

It took me roughly 40 hours of research and debate to fully understand the issues at play here, how to explain them, what my options are for helping, and then how to execute this work… An extremely high bar.

Meanwhile the process ignored the controversy.

There are no rules set in stone for process and I hope Bitcoin Core can accommodate a need to be agile when appropriate.

Please keep in mind that this option is default false.

Why add it all then?

In regards to “no technical reason”, I think the recent mempool situation perfectly illustrates why full RBF is useful.

As Sergej noted, even full RBF cannot guarantee inclusion in a congested mempool. When analyzed this is actually an extremely edge case (that could be addressed at the wallet level, allowing zero-conf to persist as an opt-in service) where you have only users that did not use an rbf wallet, did not include a sufficient fee, did not have a change output to cpfp, did not have a recipient willing to cpfp, and did not get dropped from the mempool yet.

If I see continued brigading or trolling of this thread, it will be locked. Consider yourselves warned.

I would appreciate a little bit of patience here, I am not trying to attract trolls, I am trying to be heard and give non-Bitcoin-Core-dev users a chance to have a voice. This may result in some noise but I do not want my effort to help to be undermined by outsiders.

BitcoinErrorLog commented at 9:02 pm on November 17, 2022: none

Zero-conf is only becoming riskier over time.

Please provide evidence that zero-conf is becoming riskier over time and how that circumvents the method described here: #26525 (comment)

petertodd commented at 9:08 pm on November 17, 2022: contributor

NACK @stickies-v

NACK. The discussion has been had, let’s not waste more time on this. Zero-conf is only becoming riskier over time.

FYI my Alice and Bob OpenTimestamps calendars have been modified to do full-rbf replacements regularly (usually they do repeated opt-in rbf replacements to find optimal fee levels).

The past three transactions they’ve done have all been full-rbf replacements:

https://mempool.space/tx/e9793c79fbe9fb0c344dbc1de9a9fdc2e55f202f636192444514fbd81ab8fb71 https://mempool.space/tx/aff6a5d8a6914fd9352596212d4db4160134547e75134c58c18f5fafb66f5954 https://mempool.space/tx/885f3cf70e99d74bc83376cd3dc3bb6541cb67d63130dbc06ec91b1481853a7a

I don’t believe the pools that mined them were running full-rbf. Which just goes to show that as mempools fill up, double-spending non-opt-in unconfirmed txs becomes so easy it happens essentially by accident.

BitcoinErrorLog commented at 9:10 pm on November 17, 2022: none

Only because most people are honest and aren’t even trying to double spend them.

Bitrefill has repeatedly offered to pay Peter Todd and Luke Dashjr to make doublespend attempts on their system so they may learn and improve it. The truth is that the incentives simply are not there, it is harder to pull off than it seems, and such offers are declined.

Merchants offer zero-conf as a service because it saves them money in customer service tickets related to onchain payments. Such merchants will continue to offer this service for as long as the doublespend totals are below the customer service costs.

luke-jr commented at 9:12 pm on November 17, 2022: member

Bitrefill has repeatedly offered to pay…Luke Dashjr to make doublespend attempts on their system so they may learn and improve it.

Not that I am aware of.

BitcoinErrorLog commented at 9:16 pm on November 17, 2022: none

I don’t believe the pools that mined them were running full-rbf. Which just goes to show that as mempools fill up, double-spending non-opt-in unconfirmed txs becomes so easy it happens essentially by accident.

Anecdotal incidental evidence is not a refutation of the topics at hand. None of us can know all conditions of your test, and they do not change that merchants can use thresholds to limit their exposure to only providing zero-conf service to when it matches their risk- and cost-appetite. We could always monitor congestion, blockspace, feerates, etc and only offer acceptance when risk is acceptable.

petertodd commented at 9:16 pm on November 17, 2022: contributor

Bitrefill has repeatedly offered to pay Peter Todd and Luke Dashjr to make doublespend attempts on their system

Nope. I was told in person that they wouldn’t mind if I tried. But was not offered any money nor was I offered any way to do it without spending money on real orders.

And frankly, I’ve got more important stuff to do than exploit unconfirmed txs.

BitcoinErrorLog commented at 9:21 pm on November 17, 2022: none

Bitrefill has repeatedly offered to pay Peter Todd and Luke Dashjr to make doublespend attempts on their system

Nope. I was told in person that they wouldn’t mind if I tried. But was not offered any money nor was I offered any way to do it without spending money on real orders.

This is a message from me to you from when I worked at Bitrefill. I am excluding your responses but you are welcome to share the rest of the conversation.

bitcoin locked this on Nov 17, 2022

achow101 commented at 9:23 pm on November 17, 2022: member

Locking this temporarily as too heated.

bitcoin unlocked this on Nov 18, 2022

proofofjogi commented at 3:16 am on November 18, 2022: none

ACK

As a user, I personally do not want the possibility to spend bitcoin 0conf with merchants to go away. People can manage their own risks, let them.

RBF by default would be less objectionable if lightning use was ubiquitous but that’s just not yet the case and from a user’s perspective, taking away 0conf spending degrades the UX.

zndtoshi commented at 3:22 am on November 18, 2022: none

NACK. Users should have the option to decide mempool policy on their own node.

harding commented at 3:22 am on November 18, 2022: contributor

I think it was a mistake to include mempoolfullrbf in Bitcoin Core 24.0, but at lot of decisions look like mistakes to the people who argued against them. I’ve personally chosen to move on and I don’t plan to support this or any other similar PR unless persuasive new evidence is presented (ideally first in a more appropriate forum, like the Bitcoin-Dev mailing list).

In addition, I wish to remind the maintainers of this project that @BitcoinErrorLog has a long history of abusing open source repositories, e.g.:

If there is evidence that he is engaging in such behavior again in this repository, I suggest that he be permanently banned.

BitcoinErrorLog commented at 3:28 am on November 18, 2022: none

Users should have the option to decide mempool policy on their own node.

They have always had that ability, this PR does not remove a user’s ability to customize their mempool.

If the incentive to do so is there, why aren’t we seeing it?

ghost commented at 3:29 am on November 18, 2022: none

Ack

ariard commented at 3:31 am on November 18, 2022: member

Maintaining my position from #26438. I think there is no conceptual consensus among the Bitcoin Core project and wider community to deploy mempoolfullrbf option, neither there is consensus to remove it.

Moving forward, I think the path should be to rebuild long-term conceptual consensus among all the community stakeholders on Core’s policy design and release process to advance the situation either in the status quo of pre-#25600 or towards a coordinated fullrbf deployment. On the conceptual-side, I think the philosophy proposing a policy regime for each non-interfering Bitcoin use-case should be given more considerations, either to ground it or invalidate it. There is also a more open question, if Core should have a say at all in policy settings (some today are hardcoded and no one has ever asked to change them like MAX_STANDARD_TX_WEIGHT), or we should defer more and more flexibility towars the users in the future. Or even if conflicting transaction monitoring should be addressed by introducing a new P2P protocol.

On the procedural-side, I think one learning of the previous weeks of discussions is the necessity of encompassing the concerns of all the affected class of Bitcoin community stakeholders in the design of policy changes (merchants/second-layers operators/wallets/etc). I think not only by outreaching by default the known public communication channels and community process (e.g the Optech newsletter, the BOLT process, the LSP specification process, etc), but also by giving more leeway and time in each step of design and deployment. How much this “policy design” process should be formalized or tacit, I don’t know. It’s an open question to answer in the future.

From my belief, before we have addressed those concerns and lessons of the past weeks, I don’t think it’s worthy to open more mempoolfullrbf removal PRs. Addressing them in the coming future are none of my current Bitcoin Core engineering priorities, there are a lot of issues drawing my time in the Lightning space such as making LDK more secure or advancing in solving channel jamming. Glad if we see more contributors or users working on the issues of transaction-relay/mempool policy and anyone is free to steer the effort forward, in a respectful and patient fashion according to Bitcoin protocol development standards.

artdesignbySF commented at 3:33 am on November 18, 2022: none

ACK

I agree with this:

Outsider/user-only perspective: I don’t feel strongly about the option existing or not existing, but I’m dubious about the reasoning behind full-RBF. First hearing about this controversy, my knee-jerk reaction was “the mempool can’t be trusted; that’s why we need PoW at all”, but having given it further thought:

Yes, accepting unconfirmed transactions is, and always has been, risky. I wouldn’t do it myself. But it’s not my place, or the place of anyone else, to prevent, or even ‘disincentivise’, others making that choice. If they choose to accept an unconfirmed transaction and get double-spent, they’re only hurting themselves.

Users not knowing about RBF and ending up with a non-RBF TX stuck in the mempool for a long time is not a Bitcoin Core concern. It’s a wallet concern. Wallets should flag RBF by default, or explicitly ask the user what they want per TX/on initialization.

Users accepting unconfirmed transactions unwittingly aren’t going to be prevented from doing so by full RBF. Again, wallet space.

I’ve not really heard any other arguments, besides mempool-split brain and issues w/ CoinJoin & multiparty contracts, but it doesn’t seem full-RBF actually fixes that.

Besides that, no, an unreleased piece of code is not ‘status quo’. It’s true that replacement of non-RBF transactions is already possible, but making it far easier with full-RBF is objectively not ‘maintaining the status quo’.

More than happy to hear other justifications for it. If there’s an actual tehcnical benefit to full-RBF, then we should adopt it by default. But honestly this whole thing feels quite political.

Edit: And to add, I think making it a concern of Bitcoin core to ‘disincentivise unsafe behaviour’ is a huge mistake. It’s taking on an additional responsibility you simply do not have at the moment, with potentially unlimited scope.

Treat people like fools, you will attract foolishness. Treat people like responsible individuals, and you will get responsible behaviour and encourage learning.

BitcoinErrorLog commented at 3:35 am on November 18, 2022: none

I don’t plan to support this or any other similar PR unless persuasive new evidence is presented (ideally first in a more appropriate forum, like the Bitcoin-Dev mailing list).

I encourage you to engage with any of the arguments presented in this thread. I have a lot of trouble using the mailing list, sorry if this format is not ideal.

In addition, I wish to remind the maintainers of this project that @BitcoinErrorLog has a long history of abusing open source repositories, e.g.:

I hope the effort I am going through to sincerely participate in this topic is evident.

I am here to talk about the nuances and voice concerns about the code, policy, and processes related to this feature. I would appreciate it if you do the same.

petertodd commented at 3:59 am on November 18, 2022: contributor

@bitcoinerrorlog

Go ahead and publish the rest of that conversation. As you know I flatly refused to entertain the idea because zero conf is dangerous and we never got to the point of actually discussing a real monetary offer.

And lol, I’m dredging up 3 year old chat messages? Sheesh. I talked to Bitrefill more recently and there were no offers of money, like I said.

Though perhaps don’t publish it, because our three year old private conversations on Twitter DMs are just noise in this thread and contribute nothing to the conversation…

On November 17, 2022 3:21:25 PM CST, John Carvalho @.***> wrote:

Bitrefill has repeatedly offered to pay Peter Todd and Luke Dashjr to make doublespend attempts on their system

Nope. I was told in person that they wouldn’t mind if I tried. But was not offered any money nor was I offered any way to do it without spending money on real orders.

This is a message from me to you from when I worked at Bitrefill. I am excluding your responses but you are welcome to share the rest of the conversation.

– Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1319220684 You are receiving this because you commented.

Message ID: @.***>

SkanderHelali commented at 5:26 am on November 18, 2022: none

NACK. Not this again.

This is a default off option, giving users choice.

If you already understand the risks of 0-conf and can manage them, then realistically this changes nothing for you.

Full-rbf replacements are possible as it is. Anyone who actually wants to use them maliciously can. You’d only take away the option of the average joe to rbf that transaction he signed at 1sat/vb with rbf off before Binance decided to dump 300MB of high fee txs in the mempool.

Yes, accepting unconfirmed transactions is, and always has been, risky. I wouldn’t do it myself. But it’s not my place, or the place of anyone else, to prevent, or even ‘disincentivise’, others making that choice. If they choose to accept an unconfirmed transaction and get double-spent, they’re only hurting themselves.

Correct, it has always been risky. And yes, it is fully the naive merchant’s responsibility to deal with the consequences of making bad security assumptions. However, what this PR suggests is to prevent casual users who are probably not attempting to maliciously double spend from performing a tx replacement. The security of accepting 0-conf transactions will not change with or without -mempoolfullrbf, it was insecure, and it will continue to be insecure.

No one is preventing merchants from continuing to accept this risk.

Users not knowing about RBF and ending up with a non-RBF TX stuck in the mempool for a long time is not a Bitcoin Core concern. It’s a wallet concern. Wallets should flag RBF by default, or explicitly ask the user what they want per TX/on initialization.

Correct, mostly a UX concern. I fail to see how this is an argument that supports removing the default off -mempoolfullrbf option. If anything, this is an argument to NACK.

Users accepting unconfirmed transactions unwittingly aren’t going to be prevented from doing so by full RBF. Again, wallet space.

Precisely, then why attempt to prevent users from making an informed choice on a default off config?

iBeizsley commented at 5:58 am on November 18, 2022: none

Correct, mostly a UX concern. I fail to see how this is an argument that supports removing the default off -mempoolfullrbf option. If anything, this is an argument to NACK.

Precisely, then why attempt to prevent users from making an informed choice on a default off config?

But we already have RBF. Users already have this choice. This PR does not remove that. This PR removes an unreleased change designed to support full-RBF. What additional choice is this configuration option actually giving a user? What is the benefit of setting 1 for them? If they know enough to flag on full-RBF in their node’s config, they know enough to flag RBF on their transactions.

the average joe to rbf that transaction he signed at 1sat/vb with rbf off

Why did Joe flag RBF off?

Either Joe’s wallet defaults to flagging no RBF (and this is still a wallet issue), or it was a payment to a merchant accepting zero conf.

The security of accepting 0-conf transactions will not change with or without -mempoolfullrbf, it was insecure, and it will continue to be insecure.

With full RBF, the risk of a double spend increases. In fact, that seems to be the entire point. There are comments on previous PRs around this whole mess specifically arguing full-RBF is good because it disincentivises zero-conf acceptance. How would it do that if it didn’t change the risk profile?

Transisto commented at 6:56 am on November 18, 2022: none

ACK,

This feature is making it easier and acceptable for miners to removes a decade worth of First seen policy usage.

AFAIK, All wallets that bothered to implement RBF turn it on by default for all transaction. If “First seen” is eventually ignored by miners, none of the wallet that didn’t bother implementing RBF will bother implementing a fee bump option anyway.

All miners currently benefit from higher merchant reliance fast zero-conf payments, the coin they mine and their equipement are worth more since it has more utility in commerce.

This debate seems to have negligible technical benefits, it is being looked at mostly from the angle of purist developers with low understanding of real world usage of merchants doing risk management that consider physical costs and profit margins.

Why not just let the selfish miners trying to scrape pennies from including non-RBF double-spends compile their own fork and organize themselves with thieves to share a cut of the proceeds of unethical double spends?

michaelfolkson commented at 9:38 am on November 18, 2022: contributor

I encourage you to engage with any of the arguments presented in this thread. I have a lot of trouble using the mailing list, sorry if this format is not ideal.

John has managed to use the mailing list multiple times in the past and I’m sure he can manage it again. I will personally offer to help with any struggles he may have posting to the mailing list.

In addition, I wish to remind the maintainers of this project that @BitcoinErrorLog has a long history of abusing open source repositories, e.g.:

https://twitter.com/hrdng/status/878226283162992640 https://twitter.com/hrdng/status/792393416093102081 https://github.com/bitcoin-core/gui/pull/15#issuecomment-652967092 If there is evidence that he is engaging in such behavior again in this repository, I suggest that he be permanently banned.

Open source projects don’t work if commenters and reviewers don’t make any effort to follow norms. A pull request isn’t the right forum for John posting screenshots of Twitter DMs trying to smear commenters and for BCH devs posting Sun Tzu quotes. I’m a +1 to banning John if he continues in this vein (preferably temporarily) and assuming this PR stays open I’d recommend contributors to this repo don’t engage any further with the comments being posted on this PR.

Tigerix commented at 10:16 am on November 18, 2022: none

Self custody mass adoption in Bitcoin needs to happen. In the Ethereum Ecosystem it already happens.

If we add FullRBF, users will be pushed to custodial Lightning Wallets, since instant onboarding won’t work anymore! A big drawback for the UX! And this all in the name of a theoretical attack, which hardly happens in reality?

The iPhone became such a huge success, because Steve Jobs was for the first time in history, putting users first, not developers!

ghost commented at 11:46 am on November 18, 2022: none

Self custody mass adoption in Bitcoin needs to happen. In the Ethereum Ecosystem it already happens.

FYI: Ethereum already has full RBF since any transaction can be replaced by using same nonce and higher fees.

shreyanjoshi commented at 11:52 am on November 18, 2022: none

ACK

There needs to be a strong justification for switching from the already existing default, and from my understanding, it seems to only be convenience as a feature. Each node and all businesses already had the option to toggle with RBF depending on their needs and preferences.

The thing that making RBF default for all nodes does is it meddles with the fee market way too much at the cost of introducing this convenience, because accepting 0 conf transactions was a matter of individual user and merchant decisions and for each specific transaction, which in my opinion is a reasonable bet because chain reorgs are not that common and are probabilistic (no human can cheat their way into reorgs).

Taking away this option from users and businesses forces them to not use Bitcoin L1 for simple daily high volume transactions and forces them to rely on LN; not necessarily a bad thing but disturbing the fee market to a huge extent is a heavy cost to consider.

Key question is what is the need for switching from the current default? Convenience, at the cost of disturbing the fee market and spoiling the user experience of not being able to accept 0 conf transactions, unless explicitly opted into?

Its already present as a feature for users and businesses that want it and the change has unneeded costs.

Tigerix commented at 11:53 am on November 18, 2022: none

FYI: Ethereum already has full RBF since any transaction can be replaced by using same nonce and higher fees.

Correct, but this doesn’t have any drawbacks on the UX of Ethereum, since Ethereum has a block time of ~12 seconds, so the UX is great even with full RBF on!

i5hi commented at 11:57 am on November 18, 2022: none

ACK.

jayt87 commented at 12:45 pm on November 18, 2022: none

ACK

ghost commented at 12:51 pm on November 18, 2022: none

Key question is what is the need for switching from the current default? Convenience, at the cost of disturbing the fee market and spoiling the user experience of not being able to accept 0 conf transactions, unless explicitly opted into? @shreyanjoshi

Default is not changed and you can read more about it in the release notes for v24.0: https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-24.0.md#notice-of-new-option-for-transaction-replacement-policies

FYI: Ethereum already has full RBF since any transaction can be replaced by using same nonce and higher fees.

Correct, but this doesn’t have any drawbacks on the UX of Ethereum, since Ethereum has a block time of ~12 seconds, so the UX is great even with full RBF on! @Tigerix Considering the reorgs, hard forks etc. that happens often on centralized and censored network Ethereum, I won’t consider anything below 36 blocks to be final. This can take 7 or more minutes.

I am not surprised that Bitfrefill considers 4 confirmation as final because some people love taking risks. Zero confirmation was never safe. Although this is offtopic, leaving it in between could be misleading for some users.

krotkiewicz commented at 1:00 pm on November 18, 2022: none

ACK

Despite the fact 0conf is not safe. It is not an argument here.

There is a use case and -mempoolfullrbf will kill it. Fact is that people use it and opinion is that it will be dangerous / useless when mempool will be full.

Also - mempool could be empty for many years to come. I don’t understand why so many people assume with 100% certainty that Bitcoin adoption won’t be slowed down (by i.e. political or other factors).

sarafshailesh commented at 1:37 pm on November 18, 2022: none

ACK

greedyradar commented at 1:46 pm on November 18, 2022: none

ACK - I am not convinced that there is a technical reason to make this change, and I personally use non-rbf transactions several times a month at my local ATM’s to avoid having to wait for confirmations. This change would have a direct and negative impact on how I personally use Bitcoin, and therefore I will not support the referenced mempoolfullrbf option.

nvk commented at 2:15 pm on November 18, 2022: none

NACK

Time to move on from this. We are also merchants, would never ship without confirmation. A huge amount of our customers use RBF flags already. First seen, unconfirmed transactions are not your bitcoin.

shreyanjoshi commented at 2:22 pm on November 18, 2022: none

NACK

Time to move on from this. We are also merchants, would never ship without confirmation. A huge amount of our customers use RBF flags already. First seen, unconfirmed transactions are not your bitcoin.

That’s a reason to turn on RBF on your node, not to make it default for all nodes. How does that justify shifting from the current default status quo on RBF?

Someone might want to make a reasonable bet on accepting 0 conf transactions, I say reasonable because chain reorgs are not that common and are probabilistic (no human can cheat their way into reorgs). A business doing high volume transactions might want to not bother itself with missing out on some transactions because of stuck transactions because of the reason I mentioned and nobody has the incentive to make a stuck transaction anyway. It is a bet for each individual to take on for themselves, not for anyone else to dictate. Key question is why do we need to switch from the current default?

BitcoinErrorLog commented at 2:27 pm on November 18, 2022: none

We are also merchants, would never ship without confirmation.

The merchants and shoppers that have use for zero-conf are point-of-sale checkouts and digitally rendered products, where there is urgency, not mailed items. Obviously there is no incentive to take the risk in your case.

sdaftuar commented at 2:29 pm on November 18, 2022: member

Maintaining my #26438 (comment) from #26438. I think there is no conceptual consensus among the Bitcoin Core project and wider community to deploy mempoolfullrbf option, neither there is consensus to remove it.

I agree with @ariard on this. I don’t have much to add here, other than to say that I don’t think the protocol development questions I raised on the mailing list and in #26438 have been addressed in an adequate way, and I think the next time someone proposes a change to an opt-in policy (whether that be eliminating opt-in RBF/opt-in non-replacement by default, or adding a new opt-in regime like the v3 proposal, or any other proposal where some transactions are processed under different policy rules than others) we should have a thoughtful discussion that addresses the points I’ve raised.

nvk commented at 2:32 pm on November 18, 2022: none

NACK Time to move on from this. We are also merchants, would never ship without confirmation. A huge amount of our customers use RBF flags already. First seen, unconfirmed transactions are not your bitcoin.

That’s a reason to turn on RBF on your node, not to make it default for all nodes. How does that justify shifting from the current default status quo on RBF?

Someone might want to make a reasonable bet on accepting 0 conf transactions, I say reasonable because chain reorgs are not that common and are probabilistic (no human can cheat their way into reorgs). A business doing high volume transactions might want to not bother itself with missing out on some transactions because of stuck transactions because of the reason I mentioned and nobody has the incentive to make a stuck transaction anyway. It is a bet for each individual to take on for themselves, not for anyone else to dictate. Key question is why do we need to switch from the current default?

RBF just formalizes the default spec. All unconfirmed transactions are double spendable.

IMHO wallets should have two buttons “Try to make go faster” and “Try to cancel my transaction”, we should make it easier for users to change their minds on transactions that are unconfirmed. This pushback towards this new default is only being entertained due to the current low fee environment.

PS: This discussion should be on the mailing list, opening a PR for something that seems to have very low buy in only ads noise and waste ppls time. I would recommend closing the PR and locking comments. It’s just becoming silly now.

Tigerix commented at 2:36 pm on November 18, 2022: none

PS: This discussion should be on the mailing list, opening a PR for something that seems to have very low buy in only ads noise and waste ppls time. I would recommend closing the PR and locking comments. It’s just becoming silly now.

Silly because people don’t agree with you? Thats a weak argument to make!

This clearly shows that mempool Full RBF is controversial and shouldn’t happen!

BitcoinErrorLog commented at 2:53 pm on November 18, 2022: none

IMHO wallets should have two buttons “Try to make go faster” and “Try to cancel my transaction”, we should make it easier for users to change their minds on transactions that are unconfirmed.

I agree that this can, and should, be handled at the wallet level, so we have no need to steer or disrupt current mempool policy.

PS: This discussion should be on the mailing list

This discussion is about my PR to actively remove this feature. It is as valid as other PR’s that were deemed reasonable.

The important differences here are that I do not intend to close my PR voluntarily, or be bullied, and that I can provide rationale for all arguments already.

I have nothing to discuss with the mailing list anymore on this topic. The feature clearly should have been removed, I am here to fix that.

iBeizsley commented at 2:58 pm on November 18, 2022: none

ACK.

Main reason I’ve decided to actively ACK:

It seems to me the concern about mempool split-brain is a legitimate concern, but full-RBF does not resolve that, and full-RBF via a default-off configuration flag will result in more split-brain, putting those who aren’t aware of this configuration flag, or what it means, at increased risk.

Edit to expand on the above following further discussion:

Obviously those currently not waiting for confirmations are at increased risk; replacement of non-RBF flagging txs becomes far easier, and is invisible to users unaware of this config option until the replacement has been mined. It’s worse even than accepting a zero-conf opt-in RBF transaction.
Mempool split-brain is a DOS vector for multi-party contracts. Again, replacement becomes easier, and users without this config option can’t see their collaborative tx has been replaced until the replacement is mined. If it happens again, that’s another block wasted. So on.
This implementation (default off config option) seems to damage the existing fee market/existing opt-in RBF; if we have people full-RBF replacing txs which were orignally not flagged as RBF (if they were originally flagged as RBF, full-RBF is providing zero benefit), and people who haven’t configured full-RBF (I’d wager most noderunners won’t be aware of this config option) trying to use existing opt-in RBF competing for priority, all replacements will be visible to full-RBF users, but only the opt-in RBF replacements will be visible to users not configuring full-RBF… which, again, I strongly suspect will be a significant majority of users. People not changing this config value will have no way of knowing they are being outbid.

Ofc as usual, these are already possible, but it gets significantly worse the more people start full-RBFing (unless we have full-RBF by default), which this configuration flag will encourage. Even people following best-practices will be negatively impacted. It seems to me if we really want full-RBF, it should be the default policy, and adoption should have fair warning as these problems would still exist for older versions even with default full-RBF.

Original points:

The only arguments against this I’ve seen are:

Unconfirmed transactions are unsafe to accept. The configuration flag doesn’t improve anything on this front. ‘I don’t like the fact businesses are willing to accept the current risk profile’ is not a good reason to encourage a change to mempool policy, even if you think they don’t properly understand the risks. That’s on them. This argument lays the responsibility of preventing end-user bad practice with the Bitcoin Core team. This is not a current responsibility for the Bitcoin Core team, and has potentially unlimited scope. Taking on such responsibility should be actively avoided.
RBF is good. Yes, RBF is good. And we already have it. Conflating full-RBF with RBF as a whole is a misguided at best, disingenuous at worst argument.

2a. People might accidentally/unknowingly broadcast a non-RBF transaction and get stuck in the mempool. This is just a variant of the ‘RBF is good’ argument. This is a wallet-space issue. Wallets should, by default, enable RBF, or ask the user at TX or wallet initialization time. There is no reason for Bitcoin Core to address this issue further. Bitcoin Core already addresses the issue of stuck transactions: users can flag RBF on individual transactions. There is no trade-off, unless they are paying someone who accepts zero-conf, in which case, stuck transactions are not an issue.
Status quo (we already merged this config flag). The status quo is defined by what nodes are actually running in production. An unreleased change is simply not the status quo.
User choice. This PR does not meaningfully remove user choice. Users can still choose to flag RBF on their transactions. Setting this config flag to 1 does not benefit a user unless others do so too, and even then, anybody setting this configuration value is aware enough and capable enough to flag RBF on their transactions. This is not a question of individual, self-sovereign choice. Users already have the individual, self-sovereign choice to flag RBF. This is a question of changing mempool policy, and forcing that choice on other users. If we really want to change mempool policy, we should do so. If there is technical value in full-RBF, we should adopt it. This configuration flag is a mechanism to adopt it without justifying its technical merits. The mempool is not part of the consensus layer, but mempool policy can have a significant impact on end-users whether they opt in or not. Changes to mempool policy should be made very carefully, and at this point, I do not believe the change this PR reverts was made with an appropriate level of care.
People could adopt this change anyway/full-RBF is inevitable. OK, so why pre-emtively, needlessly support a configuration flag? The inclusion of this flag is an implicit suggestion users should use it. There are Core developers being very explicit and very vocal that users should use it. My question is why, and I’ve not received an answer I find satisfactory.

More than happy to change my mind if someone is willing to engage meaningfully. I already did so once.

Edit: moved main reason for ACKing to top. Came to the realization while writing this, and think it’s a more pressing issue than any debate around full-RBF in and of itself.

benpbolton commented at 3:11 pm on November 18, 2022: none

ACK.

Core must not introduce mempool split brain (not even as an optional flag) that departs from the status quo (even IF it’s in 24.0).

Unconfirmed transactions submitted to the mempool offer functionality at a risk/reward tradeoff that users, merchants, second layers, and more may choose (and, apparently are currently choosing) to benefit from or avoid.

The network effects and complexity of updating the status quo with the introduction of (in my opinion) policy directing changes is … well it’s far more risky than any 0conf high-fee transaction. I will not be following core to 24 in the current state.

If we can’t humbly back away with more time, some will proudly plow ahead and divide us.

tiero commented at 3:39 pm on November 18, 2022: none

ACK.

There is not really any urgency to rush this change before the ecosystem is not ready.

bitcoin deleted a comment on Nov 18, 2022

achow101 commented at 3:53 pm on November 18, 2022: member

But we already have RBF. Users already have this choice. This PR does not remove that. This PR removes an unreleased change designed to support full-RBF. What additional choice is this configuration option actually giving a user? What is the benefit of setting 1 for them? If they know enough to flag on full-RBF in their node’s config, they know enough to flag RBF on their transactions.

Not every user is going to be aware of RBF before they make their transaction. Not every user is using a wallet that is connected to a node that they control. This option, if enough nodes were to enable it (note it is false by default), would help such users in times of sudden feerate spikes such as the one that is happening now. Full RBF allows those users who did not have the foresight to opt-in to RBF, or are not using a wallet which gives them the option to. Many users simply do not change the default settings, and many wallets still default to not opt-in to RBF. As we have seen with the recent mempool situation, many users have found that transactions they previously thought were high priority are now being outbid, resulting in their transactions taking longer than expected. If enough nodes on the network have enabled -mempoolfullrbf, then those users could RBF their transaction, potentially by importing their keys into a wallet that allows them to do so. It’s one of those things that users don’t realize they need it until they do, but by that point, it’s too late.

iBeizsley commented at 3:57 pm on November 18, 2022: none

Not every user is going to be aware of RBF before they make their transaction. Not every user is using a wallet that is connected to a node that they control. This option, if enough nodes were to enable it (note it is false by default)

It’s clear nobody is getting anywhere on the full-RBF debate. I still don’t think this should be addressed by Core, but fine, let’s assume we want full RBF.

It seems to me the concern about mempool split-brain is a legitimate concern, but full-RBF does not resolve that, and full-RBF via a default-off configuration flag will result in more split-brain, putting those who aren’t aware of this configuration flag, or what it means, at increased risk.

This flag, in its current state, is not the way to adopt it.

achow101 commented at 4:15 pm on November 18, 2022: member

I still don’t think this should be addressed by Core

Sure, but this isn’t Core suddenly dictating and forcing a policy change. Obviously it is up to node operators and the community to decide. However the vast majority of node operators run Bitcoin Core. The vast majority of node operators do not know how to compile their own code. They can only choose policies which Core exposes to them in configuration options. The -mempoolfullrbf option is just that - a configuration option for node operators to decide for themselves what they want their policy to be. Obviously policy changes will affect those who do not adopt that option, but that’s a side effect of having to interact with other people.

This option is default false. Core is not addressing anything other than by exposing an option to node operators to choose for themselves.

Furthermore, if Core has the opportunity to add a configuration option for policy (i.e. a PR was opened adding it), and then chose to reject that option, that would be Core “addressing” and dictating policy as it essentially says that node operators are not allowed to change this policy.

It seems to me the concern about mempool split-brain is a legitimate concern, but full-RBF does not resolve that, and full-RBF via a default-off configuration flag will result in more split-brain, putting those who aren’t aware of this configuration flag, or what it means, at increased risk.

Why do you think that is a concern? The mempool has never purported to be the same across all nodes. It is not a consensus mechanism. The only risk is for those who are willing to accept a payment when they have only seen it in their mempool. It is trivial to have multiple nodes that have different mempools. There is no problem to solve here, mempools are not meant to be the unified. If it were possible to have every node agree on what is in the mempool, then we wouldn’t need a blockchain.

jaredcobb commented at 4:20 pm on November 18, 2022: none

ACK

I feel strongly that bitcoin core should not (have) added an optional flag to v24 to allow the node mempools to reject any transaction that does not have replace-by-fee selected.

Transisto commented at 4:43 pm on November 18, 2022: none

Many users simply do not change the default settings, and many wallets still default to not opt-in to RBF.

Please, have you done any research on this? First, list the wallets that implemented RBF, 2nd how many of those have it turned off by default? I’ve tried ~90% of all wallets out there and the few that took the time to implement the rbf flag option have it set to always on, it’s not even on the transaction page I’d be far in the settings to disable it. Almost everyone agree that RBF is better and it’s more important not to get stuck in the mempool than enable zeroconf for in person, compulsory transactions.

The stuck transaction can be fixed from CPFP by more wallets (send all) , usually from either side.

The argument here is basically that there’s more people who don’t know about a feature of their wallet than there are wallet that implemented it. FALSE

That there are more users who disable RBF so they can transact faster than there are bad actors who will try to steal by double spending. Most likely FALSE. Users disabling the default RBF are usually fully aware of the drawbacks, like mempool going against them if they don’t overpay and that it’ll consume ~140 more bytes to get unstuck from a CPFP.

Most transactions are not flagging for RBF because they want benefit from zero conf, it’s because the wallet they use didn’t see a need yet to implement it because the mempool almost always end up clearing below the fee they used as a daily average.

Once you see important wallets that default to RBF but give an option for users to select “RBF opt out” then we could start having these arguments.

If this option is added and makes acceptable to reneg “First seen” and more than 5% of hashrate enables it, zero-conf merchant usage will die suddenly since their risk - reward might fall below their profit margins.

BitcoinErrorLog commented at 4:52 pm on November 18, 2022: none

Sure, but this isn’t Core suddenly dictating and forcing a policy change. Obviously it is up to node operators and the community to decide. However the vast majority of node operators run Bitcoin Core. The vast majority of node operators do not know how to compile their own code. They can only choose policies which Core exposes to them in configuration options. The -mempoolfullrbf option is just that - a configuration option for node operators to decide for themselves what they want their policy to be. Obviously policy changes will affect those who do not adopt that option, but that’s a side effect of having to interact with other people.

The problem here is this is a one-way street. It is merely the appearance of optionality, but expresses as an activation button or switch, where only ~15% of the network can vote to change the mode for the other 85%.

It is worth discussing the nuances because the nature of the feature is what is important, not whether it is off by default.

For example: if there were some other, even more controversial behavior that someone could propose they will always be able to say “Well, it is OFF by default, if people don’t want it, it will not happen!” This method separates the process from the outcome, when they are clearly related.

If the argument for this feature is that it fixes something, the default OFF is inconsistent with that goal. If Bitcoin Core has a goal, then that amounts to steering policy. It would certainly start with an innocuous setting, grease it in with an OFF default, then turn the default ON in a future update.

Overall this creates a staggered path to authority by engineers via separating the steps into parts that are allowable in isolation, even if they aren’t justifiable on the whole.

This option is default false. Core is not addressing anything other than by exposing an option to node operators to choose for themselves.

Unfortunately, there is not also an option for zero-conf users to opt-in after the fullRBF option is activated. So we must recognize this feature ultimately comes with a tradeoff of disrupting the user space and existing infrastructure and risk factors. A more doublespendable mempool will likely result in more doublespends.

achow101 commented at 5:18 pm on November 18, 2022: member

First, list the wallets that implemented RBF, 2nd how many of those have it turned off by default? I’ve tried ~90% of all wallets out there and the few that took the time to implement the rbf flag option have it set to always on, it’s not even on the transaction page I’d be far in the settings to disable it. Almost everyone agree that RBF is better and it’s more important not to get stuck in the mempool than enable zeroconf for in person, compulsory transactions.

My statement also includes wallets that have not implemented RBF, of which there are many. I have worded it that way because opt-in RBF requires specific nSquence values, and as nSequence values are required, all wallets have some default value for them. Many wallets default to nSequences that do not opt-in to RBF. Of course many of those wallets do not allow the user to opt in either.

The rest of your comment is incorrect as it incorrectly assumes that I am only speaking about wallets that have exposed opt-in RBF functionality to the user. But I am referring to all wallets which choose a default nSequence value that is not opt-in RBF.

Once you see important wallets that default to RBF but give an option for users to select “RBF opt out” then we could start having these arguments.

Literally this project. Bitcoin Core’s wallet allows users to easily opt out of RBF, even though it is default on.

iBeizsley commented at 5:18 pm on November 18, 2022: none

Why do you think that is a concern?

Because even ignoring zero-conf, split-brains are a DOS vector for multi-party transactions. If enough people enable this configuration option, it becomes trivial to execute this attack on anybody who hasn’t enabled it, with no way for them to know they are being attacked until the replacement has been mined.

A default-off configuration flag is quite possibly the worst way to enable full-RBF. Even a default on configuration flag would mean that at least those users who aren’t aware of the issue would actually see the replacements in their mempool and be able to counter it.

We can’t completely prevent split-brains, no. But we shouldn’t be actively enabling them.

achow101 commented at 5:26 pm on November 18, 2022: member

Because even ignoring zero-conf, split-brains are a DOS vector for multi-party transactions.

Obviously, but that is why the blockchain exists. It resolves those issues because it is a mechanism for everyone to arrive at the same conclusion. Mempools are not, and so transactions that are unconfirmed should not be treated as settled. What multi party transactions are executing things before transactions confirm? AFAIK, basically every one requires confirmations.

petertodd commented at 5:46 pm on November 18, 2022: contributor

On November 18, 2022 10:52:33 AM CST, John Carvalho @.***> wrote:

The problem here is this is a one-way street. It is merely the appearance of optionality, but expresses as an activation button or switch, where only ~15% of the network can vote to change the mode for the other 85%.

I’m glad that you agree that a small minority adopting full-rbf can make unconfirmed txs completely insecure for everyone else.

That should tell you something important: unconfirmed txs are extremely vulnerable, and should not be trusted.

I’m discussing full-rbf with some small solo miners and mining pools and won’t be surprised if 1%-5% of the hashing power gets around to implementing it in the next few weeks. In fact, there’s a double spend that I’m aware of that makes me suspicious that one of the larger miners was trying out full-rbf.

Don’t use Bitcoin in such a way that a single mining pool sysadmin can make you have a really bad day…

Incidentally – to answer Suhas’s question from earlier – robustness to this is precisely why I think if v3 txs are implemented as is, we should have a command line flag that lets miners easily violate the v3 rules. It’s a good thing if a small % of hashing power is running with that option turned on, to make sure we don’t get complacent to that possibility happening.

Transisto commented at 5:58 pm on November 18, 2022: none

Don’t use Bitcoin in such a way that a single mining pool sysadmin can make you have a really bad day…

We don’t, we already know. It’s already assumed that there are miners out there getting paid to replace zero-conf, we also know it’s impossible to guess which miners will find the next block therefore we don’t trust zeroconf that’s not conservatively aiming for next block inclusion, it’s always been a probability risk-reward issue.

My main problem is the double dichotomy of First seen + RBF vs FullRBF on the same branch. Why not simply fork off, if you’re about to create a simple toggles that delete First seen as if it’s never been of any importance?

bitcoinheiro commented at 6:30 pm on November 18, 2022: none

ACK, concerns are legit.

#26525 (comment)

acidtib commented at 7:02 pm on November 18, 2022: none

NACK

josibake commented at 7:39 pm on November 18, 2022: member

NACK

I don’t have any new arguments to add other than those that were presented in #26438. There are some very well-reasoned and nuanced arguments both for and against on #26438, so I would encourage those commenting here for the first time to take an afternoon to read and digest the discussion on #26438. The author of this PR was involved in the discussion as well and this PR does not seem to present any new arguments, ergo reading #26438 and understanding why it was closed is likely a more productive use of time than re-hashing arguments on this PR.

mzumsande commented at 7:52 pm on November 18, 2022: contributor

NACK

Why not simply fork off, if you’re about to create a simple toggles that delete First seen as if it’s never been of any importance?

Because people shouldn’t be forced to run a fork or switch another implementation just for the sake of a single policy they don’t agree with. I don’t think any alternative implementation comes close to Core in terms of maturity and code quality (many are one-person projects and/or have very little review), and with being the de-facto standard comes an additional responsibility to not dictate policy and give users choices they want - even if we’d prefer they didn’t use these. That’s why users aren’t required to upgrade to newer versions of Core even though it would make life for developers so much easier - just due to the large mix of policies from different Core versions, mempool split-brains are a constant reality.

Therefore I think the responsibility of Bitcoin Core as a project should be to set the default, but it should end there. Users and miners who trust the recommendations of Core should make use of that default. If there is a significant group of people who request a different policy choice, we should offer it as an alternative with a high degree of agnosticism and let the network (nodes + miners) play it out.

It seems fundamentally wrong to me if we got into a situation where a policy is not going to succeed in the network solely because of the technical hurdle of running an own patch / moving to an alternative implementation, but that same policy would have been adopted had we just offered it as a non-default option.

BitcoinErrorLog commented at 10:21 pm on November 18, 2022: none

Because people shouldn’t be forced to run a fork or switch another implementation just for the sake of a single policy they don’t agree with.

The only way to express preference for RBF without imposing it on people that do not share your preference is at the wallet level.

Have you considered that maybe people do not hand-customize this preference in their mempool because they like it the way it is?

being the de-facto standard comes an additional responsibility to not dictate policy and give users choices they want - even if we’d prefer they didn’t use these.

I hope you can see the irony in this statement when you put the shoe on the other foot. I am arguing the same thing for the opposite choice, and my opponents prefer I do not have that choice.

The difference here is that in the current first-seen policy, both sides can have their preference. In a fullrbf environment, the zero-conf use case becomes overridden.

Zero-conf acceptance is responsibly implemented and used for many txns. This has been true for the entirety of Bitcoin’s history. It seems odd to jeopardize the utility we currently enjoy just so a small minority of users can avoid having to think about which wallet to use.

luke-jr commented at 2:30 am on November 19, 2022: member

‘I don’t like the fact businesses are willing to accept the current risk profile’ is not a good reason to encourage a change to mempool policy, even if you think they don’t properly understand the risks. That’s on them.

If they accepted the risk was on them, that’d be one thing. But apparently some are going so far as to discriminate against RBF-prefering transactions and refuse to acknowledge entirely valid payments, even suggesting a URI scheme to tell users they can’t set “RBF please”.

This PR does not meaningfully remove user choice. Users can still choose to flag RBF on their transactions.

They can still choose that regardless. This PR is about user choice of their node’s policy, not their wallet’s transactions.

Core must not introduce mempool split brain

There is no such thing. Each node has its own mempool, and they are not expected to be identical.

iBeizsley commented at 3:13 am on November 19, 2022: none

If they accepted the risk was on them, that’d be one thing. But apparently some are going so far as to discriminate against RBF-prefering transactions and refuse to acknowledge entirely valid payments, even suggesting a URI scheme to tell users they can’t set “RBF please”.

If this is the case, that’s silly. But still, that’s their choice. Don’t buy from them?

There is no such thing. Each node has its own mempool, and they are not expected to be identical.

Oh, come on. There is a common, broad understanding of which transactions will get relayed. Without a somewhat consistent set of rules, I can’t reason about whether my own transactions are likely to make it to miners, whether transactions I have seen are likely to make it to miners, whether I have a remotely complete picture of the mempool, or what kind of fees I should be setting to (probably) get included in X blocks.

There is utility in shared mempool state far beyond zero-conf, and the more consistent it is, the better people can reason about upcoming blocks.

Edit: I’ll give a specific example directly related to the split the configuration flag in question seems likely to cause:

Enough users enable this flag for their non-RBF-flagged replacement TXs to be reliably propagated to miners.

Many users have still not enabled this configuration flag for multiple reasons, chief among them simply not knowing it exists, and what it means.

I think this is a reasonable hypothetical.

Mempool fills up. Users want to RBF to push their transactions through.

Some use full-RBF. They broadcast replacements for transactions which weren’t originally flagging RBF.

Those who haven’t enabled this flag don’t see these replacements in their mempool. They flagged RBF originally, so they can replace their old transactions. But they are now (unknowingly) bidding against a class of users with more information than they have. They bump fees. Maybe, by chance, they bump higher than the full-RBF users. Maybe they don’t. Either way, the full-RBF users see these fee bumps, and can outbid. Those who haven’t enabled this configuration flag don’t see the resulting full-RBF replacements, and don’t even know they have been outbid.

BitcoinErrorLog commented at 3:18 am on November 19, 2022: none

If they accepted the risk was on them, that’d be one thing. But apparently some are going so far as to discriminate against RBF-prefering transactions and refuse to acknowledge entirely valid payments, even suggesting a URI scheme to tell users they can’t set “RBF please”.

If this is the case, that’s silly. But still, that’s their choice. Don’t buy from them?

It is not the case in any situation I have seen. Such merchants simply require 1 conf from anyone paying outside of preferred settings.

As we all know, no one can actually refuse an onchain payment anyway.

SeverinAlexB commented at 6:17 am on November 19, 2022: none

I don’t see any reason why we should force users to use RBF. It breaks current business practices. This should be a users choice. It’s their risk. 0conf is not perfect but worth it.

And even if you disagree with my statements above, we should at least remove the code temporarily to allow further discussions in the community and then decided if we want it or not. It’s too controversial at the moment.

ACK

ghost commented at 8:35 am on November 19, 2022: none

I don’t see any reason why we should force users to use RBF. It breaks current business practices. This should be a users choice. It’s their risk. 0conf is not perfect but worth it.

Nobody is forcing users to use RBF and RBF(opt-in) still remains default. This is a non-default config option which can only be used if users set mempoolfullrbf=1. It would still be irrelevant until lot of nodes and some miners use it. At that point it will be obvious that some users need it.

This is a users choice and a few businesses using unsafe practices should not be the reason for removing it. Even full RBF has some use cases and we would have better insights once it is available for an average user to try it.

Note: I would like to thank PR author and others for this drama because even if this option is removed at some point, we have achieved below things:

More users are aware of services and projects that are vulnerable
More users know the difference between RBF opt in and full RBF
More users know the risks of zero confirmation transaction considered as final
It will be easier to patch bitcoin core and use it or run alternative implementations

Transisto commented at 4:53 pm on November 19, 2022: none

This is a non-default config option which can only be used if users set mempoolfullrbf=1. It would still be irrelevant until lot of nodes and some miners use it. At that point it will be obvious that some users need it.

Like I said earlier, incentivizing only 5% of hashrate to disable First seen policy would make zeroconf unusable for commerce overnight. Why? Because merchants are willing to give up only so much of their profit margin to fraud. Just take a look at the dynamic of credit cards processing, they lose a % to chargebacks and they accept that probability of risk vs reward.

Only 26% of transaction signal for RBF, and that’s definetly not because people prefer zeroconf. It’s because the wallet ecosystem didn’t see enough of a need yet to implement it. Because when they do implement it, they make it default.

As much as this could be good for lightning adoption it is far from ready.

In summary, everyone was mostly getting along very well with First seen being mostly respected until purist developers decided if something is not 100% safe it should not be used at all, so let’s build an “Allow theft” button on the main branch so that miners can have that option without any coding work or 2nd thought.

TheGuySwann commented at 0:00 am on November 20, 2022: none

ACK

As best as I can tell after reading WAY too much of multiple threads on this topic, this is, imo, what it comes down to:

••• fullRBFers: “In THEORY 0-conf doesn’t work and it isn’t safe so you should stop using it. We don’t care about people who use it, because they are using it wrong. There are some fraction of users who need to refresh txns, and don’t know about RBF.”

••• 0-confians with RBF: “In PRACTICE we use 0-conf all the time, RBF is a great tool and option and both 0-conf and RBF work and are great for the respective benefits. The risk of 0-conf is manageable, as literally 1000s have managed it. No one said it was secure, but it DOES matter.”

It genuinely feels to me like this is almost a spiteful change despite SO many merchants, processors, and lightning wallets taking advantage of 0-conf, and the simple fact that the overwhelming majority of nodes having “first seen” mempool policy DOES affect the difficulty of a re-broadcast of an unconfirmed transaction. It is very low assurance, but also most often specifically is associated with low risk transactions.

I would bet money there are fewer 0-conf double spends than there are fraudulent & reversed credit card transactions by volume. The default “first seen” for network nodes is a very soft barrier, but it is a barrier nonetheless. The explanation from fullRBFers in here that “you only need X miners” and “you can easily do X” etc actually confirm this, that you have to go around the node network, which is actually a deterrent. To remove this such that all rebroadcasting is boosted by node policy, that it costs no time, & has its one small barrier removed, seems like a spiteful move that doesn’t even have much of a benefit.

Honestly, as someone who uses BTC/LN every single day, 0-conf channels have been one of the best things in 5 years for Lightning UX and onboarding. I have been a big fan of seeing many of my wallets also start taking advantage of RBF, and I’ve used it a great number of times. a “first seen” policy benefits both. A fullRBF default clearly hurts 0-conf, and is admitted as such by the people pushing it.

I can’t think of anything that needed fixing LESS than the current situation around 0-conf and RBF, and I don’t get why this has suddenly become so important in the face of the huge number of people, services, and wallets that take advantage of it. And they won’t go to something more secure, they will go to something more convenient, ie. the difference will be made up with custodial BTC/LN

TLDR; • More people take advantage of 0-conf than need unstuck Txns • In THEORY 0-conf can’t work — in PRACTICE it works fine & even better than fiat alternatives • Both arguments rely on the acknowledgement that changing this node policy DOES negatively affect 0-conf • RBF and 0-conf have worked together just fine & both have manageable risk & trade offs in their differing uses • If 0-conf ever gets indefinitely & broadly attacked without help from the Core client purposefully weakening it, then it can die & we will bow to the superiority of the THEORY. Managing that risk is not hard. • There is very little trade off for maintaining “first seen” • There is potentially a pretty big trade off from weakening 0-conf by using the node network to support rather than suppress non-RBF rebroadcasts

PulpCattel commented at 7:42 am on November 20, 2022: none

As best as I can tell after reading WAY too much of multiple threads on this topic, this is, imo, what it comes down to:

You say “reading way too much”, but then you ignore 90% of the other side arguments. You are certainly not the only one trolling like this in this thread, so maybe I should not be surprised.

In THEORY 0-conf doesn’t work and it isn’t safe so you should stop using it.

Really, how are you not trolling? Of all the discussions in the previous PR and in this one, all the discussion about user choices and convenience, privacy, incentive compatibility, and whatnot you think it all comes down to this?

The risk of 0-conf is manageable, as literally 1000s have managed it. No one said it was secure, but it DOES matter.

So manage it? And stop trolling users that have other priorities than yours?

It genuinely feels to me like this is almost a spiteful change despite SO many merchants, processors, and lightning wallets taking advantage of 0-conf,

And what about SO many merchants, processors, and lightnings that want to take advantage of full-RBF? Why should we decide for them. Why not let the market decide?

the overwhelming majority of nodes having “first seen” mempool policy DOES affect the difficulty of a re-broadcast of an unconfirmed transaction.

The default is unchanged, the overwhelming majority of nodes will have the same policy as before.

The default “first seen” for network nodes is a very soft barrier, but it is a barrier nonetheless

I don’t want this barrier on my node. It’s stupid. There’s no reason for my node to be a barrier and I don’t want it to be. If unconfirmed txs are safe enough, why is this a problem to you?

To remove this such that all rebroadcasting is boosted by node policy

Are you trolling? Sorry if I keep asking but at this point it must be. The default is unchanged, nobody is removing anything here. If nodes operator want to remove it from their own nodes, then who are you/me/we/ to say no to them? Why artificially make it hard for them?

seems like a spiteful move that doesn’t even have much of a benefit.

You clearly didn’t read the various discussions, or again you are trolling. The usecases and benefits have been presented by both sides. It probably will become spiteful if you all keep getting in the way of node operators with ideas different than yours. It’s so overwhelmingly disrespectful what you are doing, strawmanning the other side arguments like they were just butthurt kids

A fullRBF default clearly hurts 0-conf, and is admitted as such by the people pushing it.

There is no fullRBF default, my eyes are bleeding. Who is pushing this narrative? Can you point me where you got this idea? The default is the same as before. It can become the de-facto default only if many turn it on, at which point (as already mentioned above in this discussion) it will be clear there’s more demand for it than you thought.

I can’t think of anything that needed fixing LESS than the current situation around 0-conf and RBF

Good for you, some disagree. Why don’t offer the option and let the market sort it out?

why this has suddenly become so important

Maybe, just maybe, because there are many people who think is important? Have you ever considered this? Perhaps you have totally missed the point?

Your TL;DR also doesn’t make sense to me.

What really boils down to is: You and others keep saying “unconfirmed transactions are fine”, and I don’t give a damn, accept what you want. But then they are at the same time so fragile and they need so much artificial barriers to work, that apparently you have to prevent even a relatively small part of node operators from choosing for themselves their own policies.

Leave us alone, manage your risks without putting artificial barriers on other people nodes.

Tigerix commented at 12:22 pm on November 20, 2022: none

We Bitcoiners are very proud that we are not like Ethereum.

That we don’t have centralized decision making.

The rule so far was: Don’t make controversial changes to Bitcoin.

mempool FullRBF is such a change. It needs to be removed from the v24 release.

JeremyEllingham commented at 12:38 pm on November 20, 2022: none

We Bitcoiners are very proud that we are not like Ethereum.

That we don’t have centralized decision making.

The rule so far was: Don’t make controversial changes to Bitcoin.

mempool FullRBF is such a change. It needs to be removed from the v24 release.

You have this the wrong way around. The Ethereum community are very cooperative and synchronised on their network changes and roadmap. Bitcoin doesn’t even have a roadmap, so things that come up like this are unexpected and controversial.

SegWit was a titanically controversial change, yet that was heralded as one of the best innovations BTC ever made.

bitcoinheiro commented at 2:36 pm on November 20, 2022: none

SegWit was a titanically controversial change, yet that was heralded as one of the best innovations BTC ever made.

Clearly not the case here. This is just a small totally unnecessary change, regarded as such even by the proposer of the change.

Transisto commented at 4:04 pm on November 20, 2022: none

And what about SO many merchants, processors, and lightnings that want to take advantage of full-RBF? Why should we decide for them.

How would a merchant benefit from full-RBF? I can only think of one way, Instructing a customer to import it’s seed in a new wallet that supports easy doublespending. (I doubt any wallet would support that but doesn’t already have RBF options and sets it on by default) All that instead of having either the merchant or the customer do a CPFP?

More FullRBF nodes could removes a source of revenu from wallet developers that build a feature to override the First Seen policy by sending their tx directly to the few select miners that built an interface to share profit of favoring a non-rbf RBF. If there’s enough demand for thiefs to collude with miners to steal from merchant (or unstuck their transactions) then they’ll figure out how to collect payment and do a profit share aside the mempool.

The miners that want to sabotage the first seen policy for extra profit already have the option to run from a fork. There are almost no arguments to make it easier or ethical for them on this branch.

The fullRBF PR came about as a way to fix a rare pinning attack, that it may not actually fix then merged with very low regard of current real world usage of zeroconf.

My suggestion is to reconsider adding the fullRBF option until either there are more reported cases of non RBF being replaced by miners out of band or that the majority of wallets have implemented RBF and users actually disable RBF for zeroconf reasons.

ghost commented at 5:01 pm on November 20, 2022: none

The rule so far was: Don’t make controversial changes to Bitcoin. @Tigerix this pull request is controversial so it won’t make it to bitcoin

ghost commented at 5:10 pm on November 20, 2022: none

I have setup custom signet if someone interested to test : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021216.html

Its easy to comment and enjoy drama. Difficult to understand related things.

I have even requested people to create a simple website to replace any bitcoin tx: https://nitter.net/1440000bytes/status/1594165768958218243

Tigerix commented at 5:37 pm on November 20, 2022: none

@Tigerix this pull request is controversial so it won’t make it to bitcoin

I already noticed that some people supporting mempool FullRBF are twisting arguments just so they don’t need to hold up to their own standards. So I am not surprised by your comment!

ghost commented at 5:58 pm on November 20, 2022: none

@Tigerix this pull request is controversial so it won’t make it to bitcoin

I already noticed that some people supporting mempool FullRBF are twisting arguments just so they don’t need to hold up to their own standards. So I am not surprised by your comment!

You wanted to make this pull request controversial, isn’t it? Hoping something can be removed from bitcoin core?

Every PR in this repo can be made controversial if twitter influencers try. It cannot be the reason to stop something that helps bitcoin.

Please try contributing regularly if you care so much or don’t use this config option in your node. Don’t try to dictate what others do with their mempool and node.

Tigerix commented at 6:12 pm on November 20, 2022: none

Please try contributing regularly if you care so much or don’t use this config option in your node. Don’t try to dictate what others do with their mempool and node.

Adding this feature means changing the mempool how it worked since Bitcoins inception. So you are again proofing my point of twisting the argument.

The reason I care is because I want non custodial Lightning adoption to happen. Without instant onboarding this won’t happen!

ghost commented at 6:32 pm on November 20, 2022: none

Please try contributing regularly if you care so much or don’t use this config option in your node. Don’t try to dictate what others do with their mempool and node.

Adding this feature means changing the mempool how it worked since Bitcoins inception. So you are again proofing my point of twisting the argument.

The reason I care is because I want non custodial Lightning adoption to happen. Without instant onboarding this won’t happen!

There is no THE MEMPOOL and it never existed.

Improving LN is one of the reasons some devs wanted full RBF default. Its not even default, just an option for users to decide. Please read all the related PRs as I cannot write everything here just because someone wanted to rehash it.

Non-custodial LN will still work and there are further changes required to scale LN irrespective of mempool policies. I understand this market enough that there is no urgent LN onboarding happening in next few months. Even if it does, unsafe practices will always lead to some people getting exploited.

Give up on turbo channels aka vulnerable channels and start researching about alternatives. Some developers already did and one of the solution was shared UTXO. Ironically, it was opposed by author of this PR and marked as an attack on bitcoin.

If you oppose every improvement to bitcoin, it might feel good as cult but doesn’t help bitcoin in long term including lightning.

SkanderHelali commented at 6:41 pm on November 20, 2022: none

The reason I care is because I want non custodial Lightning adoption to happen. Without instant onboarding this won’t happen!

0-conf channels from LSPs to users already involve you trusting the liquidity provider not to double spend. This doesn’t impact that risk calculus at all. The LSP isn’t at a higher risk of a double spend.
Entities accepting 0-conf LN channels from users is already pretty dumb, and I’m not personally aware of someone who does this, arguably this will become more risky with this change.

I fail to see how a change that doesn’t impact (1) is going to ‘hurt’ instant onboarding in LN.

Spend some time actually studying the implications of a change before commenting, please.

The discussion is pretty much past the point of people presenting their arguments and I don’t see a point in keeping it open. Regardless of the fact that it is already a dupilcate.

BitcoinErrorLog commented at 9:01 pm on November 20, 2022: none

I fail to see how a change that doesn’t impact (1) is going to ‘hurt’ instant onboarding in LN.

Spend some time actually studying the implications of a change before commenting, please.

Like most of the replies this weekend, you are displaying each of the shortcomings you are complaining about.

The new full RBF option does not solve any of the problems that inspired it, and irrefutably disrupts all of the qualities zero-conf users are concerned about.

This makes inclusion indefensible, controversial, and a strict downgrade for Bitcoin users.

The setting, if used, is invasive of users that choose not to opt in, makes mempool behavior less consistent, may result in more actual doublespends, and behaves more like an activation than a simple individual user choice.

Since you are curious, the way zero-conf improves Lightning adoption is as follows:

If you combine, as I and other wallet-makers intend to, zero-conf payments to purchase zero-conf channels, with JIT channels, with splicing, wallets can provide frictionless instant LN onboarding and payments in any situation. If the user is onchain they could pay, or be paid, instantly offchain.

This type of creativity and optionality is a huge boon to apps and users because LN is actually quite complicated to convey and provide in a self-custodial way.

The trend right now is for LN users to use custodial, censorable, trusted accounts. This is not necessary or healthy for Bitcoin at all.

I am fighting so hard to remove this feature and cease the full RBF movement because I am deeply aware of, and sensitive to, user and builder needs. I want Bitcoin to remain useful for commerce, and that means letting us continue to have the ability to opt-in to perfectly risk-manageable zero-conf acceptance.

I will not concede my awareness of 13 years of Bitcoin history and proof of utility for full-RBF propents’ speculation about the future.

Users have all the choices at the wallet level, but full RBF mempools would reduce those choices on the whole.

This week, I will be working with Bitrefill to provide actual statistics of the quantity of users affected and volume of Bitcoin commerce currently benefiting from responsible management of zero-conf risk exposure to provide instant acceptance as service.

Zero-conf is thriving and benefiting Bitcoiners across the world. The Full RBF mempool feature is detrimental, disruptive, and fails to solve any of the issues its proponents hope to address.

vostrnad commented at 11:24 pm on November 20, 2022: none

NACK

Even though full-RBF might not actually help mitigate the pinning attacks which were the main motivator of its development, there are other reasons to deploy it. For example, not having to set the nSequence fields in order to make a transaction easily replaceable will over time improve privacy for everyone.

But even if no such reasons existed and this was all about making life harder for zero-conf services, as long as a new default-false local policy option has more than enough development effort behind it, I don’t believe the project maintainers should decide against including it, controversial as it might be.

BitcoinErrorLog commented at 2:54 am on November 21, 2022: none

Even though full-RBF might not actually help mitigate the pinning attacks which were the main motivator of its development, there are other reasons to deploy it. For example, not having to set the nSequence fields in order to make a transaction easily replaceable will over time improve privacy for everyone.

There is no effective evidence I know of that flagging RBF is actually causing a privacy impact to users that is resulting in any form of censorship or attack. This logic is extremely weak and could be applied to basically any distinctive aspect of a txn, like using native segwit, various op_returns, etc.

Further, this new feature does not actually eradicate or hide the behavior of wallets that do facilitate RBF flagging, nor would it be advisable to stop flagging it if your actual goal is replacement optionality. If privacy is your serious concern, you would also be submitting a BIP for wallets to RBF by default, not only mempools. However, you can probably never expect to be able to hide your distinction if actually replacing txns. Overall this is an dubious strawman argument and I am no crow.

But even if no such reasons existed and this was all about making life harder for zero-conf services, as long as a new default-false local policy option has more than enough development effort behind it, I don’t believe the project maintainers should decide against including it, controversial as it might be.

This seems like a word soup saying “I don’t care if there is no good reason to keep this, nor if it harms other use cases, nor if it is controversial. I want what I want because I want it and devs spending time on things is the only justification required.”

vostrnad commented at 4:23 am on November 21, 2022: none

There is no effective evidence I know of that flagging RBF is actually causing a privacy impact to users that is resulting in any form of censorship or attack. This logic is extremely weak and could be applied to basically any distinctive aspect of a txn, like using native segwit, various op_returns, etc.

Any distinctive transaction characteristic is almost certainly being used by chain analysis right now, including RBF flagging. But RBF flagging is different in that there is no technical reason it’s needed for being able to replace a transaction, only a “social” one, and I believe (and will configure my own node accordingly) that it’s time to do away with it.

Further, this new feature does not actually eradicate or hide the behavior of wallets that do facilitate RBF flagging

You don’t need to change the behavior of existing wallets. Once full-RBF becomes reliable, it’s enough that just one wallet starts flagging transactions as opt-in RBF at random, and that will create reasonable doubt for everyone else.

However, you can probably never expect to be able to hide your distinction if actually replacing txns.

The distinction is only revealed for transactions that actually end up being replaced. If I want all my transactions to be replaceable but only end up replacing a small number of them, for the majority of them full-RBF would allow me to hide the fact that they were meant to be replaceable. This is similar to how Taproot improves privacy even when you sometimes need to reveal that a script tree exists.

I want what I want because I want it

If my phrasing didn’t make it clear, I would support the inclusion of a default-false local policy option even if I didn’t personally like it (e.g. something like -notaproot), regardless of anyone’s reasons for wanting it.

benpbolton commented at 2:48 pm on November 21, 2022: none

🤔 Perhaps this PR should’ve instead introduced a way for node operators to refuse connecting to nodes with mempoolfullrbf=1… Escalate the (needless) schism and drop agreement BOTH ways?! Make the network explicitly weaker!

Instead, how about we de-escalate… walk the functionality degradation back (which this PR does). Take a few breaths. That’s what this PR allows.

reardencode commented at 7:49 pm on November 21, 2022: none

Concept NACK (again)

Please stop trying to force individual and business node runners to run less tested, less reviewed software (either by patching and building their own, or by running Knots or another community member’s fork) in order to express their preferences non-consensus aspects of the Bitcoin system.

All of the arguments in favor of this PR seem to boil down to a misconception that there is some concept of consensus on policy rules, when that is obviously false (that is why PoW, difficulty adjustment, etc. are part of Bitcoin’s design). There are already many nodes running mempoolfullrbf or equivalent. It is therefore tautological that adding the option to Bitcoin Core doesn’t break any consensus, and that the consequences of part of the network running with this option already exist. We should watch out for this fallacy in discussion of future P2P changes, and dismiss similar arguments without discussion beyond confirming that they are indeed in this category.

The main effect of merging this PR would to be inconvenience a subset of users, and reduce the security of their nodes.

It is not the job of the Bitcoin Core maintainers to prevent users desiring to run certain non-consensus configurations from doing so. If that were the core maintainers’ job, it would be impossible.

Transisto commented at 4:01 am on November 22, 2022: none

I’ve read a lot about the topic and I didn’t see any sufficiently legitimate reason to include mempoolfullrbf beside that tx relaying and inclusion policy is not part of consensus. If so, then why don’t we focus on removing anything related to transaction relaying or mempool management from Core?

All of the arguments in favor of this PR seem to boil down to a misconception that there is some concept of consensus on policy rules, when that is obviously false (that is why PoW, difficulty adjustment, etc. are part of Bitcoin’s design).

I’m very confused how the way nodes communicate transactions between each other is not important enough to consider it as vital as chain tip consensus, in the absence of a dependable alternative, if there’s anything wrong in the default implementation it could cause major systemic problem.

Meddling with multiple mempool policies in Core remove the main incentivize to develop independent alternative mempool syncing solutions, if that’s the long term intention.

There’s a long history for first seen being important. Miners should have a greater incentive to provide more utility in sporadic commerce than making a few sat from people who didn’t plan properly and got a transaction stuck in traffic.

Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort. Satoshi Nakamoto Sun, 09 Nov 2008 11:14:17 -0800

ghost commented at 6:43 am on November 22, 2022: none

🤔 Perhaps this PR should’ve instead introduced a way for node operators to refuse connecting to nodes with mempoolfullrbf=1 @benpbolton you can check service flag REPLACE_BY_FEE or UNKNOWN of peers and ban them with setban RPC.

Example:

 0    "id": 42,
 1    "addr": "185.21.217.48:18333",
 2    "addrbind": "X.X.X.X:XXXXX",
 3    "addrlocal": "X.X.X.X:XXXXX",
 4    "network": "ipv4",
 5    "services": "000000000400040d",
 6    "servicesnames": [
 7      "NETWORK",
 8      "BLOOM",
 9      "WITNESS",
10      "NETWORK_LIMITED",
11      "REPLACE_BY_FEE?"
12    ],

 0    "id": 2,
 1    "addr": "185.21.217.48",
 2    "addrbind": "X.X.X.X:XXXXX",
 3    "addrlocal": "X.X.X.X:XXXXX",
 4    "network": "ipv4",
 5    "services": "000000000400040d",
 6    "servicesnames": [
 7      "NETWORK",
 8      "BLOOM",
 9      "WITNESS",
10      "NETWORK_LIMITED",
11      "UNKNOWN[2^26]"
12    ],

michaelfolkson commented at 11:39 am on November 22, 2022: contributor

@1440000bytes: One can and anyone is free to ban whichever peers they want. From a network perspective (and perhaps even an individual node perspective) I don’t think it is optimal that the zero conf nodes ban the full RBF nodes or vice versa. The P2P/policy/mempool devs will have a more informed perspective but I would have thought this doesn’t achieve much apart from fragmenting the network into segments. A zero conf node has to eventually verify a valid RBF spend if it is mined in a block even if it initially refuses to allow it into its mempool and refuses to peer with full RBF nodes. It doesn’t seem optimal that it refuses to verify that transaction until the last possible moment i.e. it is forced to verify it because it has been mined.

So free to ban, certainly. But I don’t think it achieves much if anything.

felcreate commented at 12:26 pm on November 22, 2022: none

ACK @PulpCattel

And what about SO many merchants, processors, and lightnings that want to take advantage of full-RBF? Why should we decide for them. Why not let the market decide?

You’re literally flagging transactions as RBF which users don’t want to have flagged. Why should we decide for them. Why not let users decide?

iBeizsley commented at 12:26 pm on November 22, 2022: none

It doesn’t seem optimal that it refuses to verify that transaction until the last possible moment i.e. it is forced to verify it because it has been mined.

So free to ban, certainly. But I don’t think it achieves much if anything.

This is my big problem with this configuration flag as it exists today. How is RBF supposed to work if you don’t know what transactions waiting in the mempool are offering? How are you supposed to participate in a fee market ‘auction’ when there is a (growing) class of people who can see your bids, and you can’t see theirs?

Default config nodes using existing opt-in RBF will be blind to any full-RBF replacements.

This default off configuration flag was the worst choice which could have been made.

michaelfolkson commented at 12:53 pm on November 22, 2022: contributor

This default off configuration flag was the worst choice which could have been made.

I agree @iBeizsley. It would have saved a lot of time and discussion if the equivalent of full RBF on by default had been implemented to begin with. I doubt anyone would have wanted an option if it was already enabled by default. That’s the thing with compromise solutions, they get you over a short term hump but create long term problems. To be fair it is very easy for us to complain today, I’m sure it was impossible to get anything done in the block size war era and so any sort of short term compromise seemed better than nothing.

josibake commented at 1:46 pm on November 22, 2022: member

You’re literally flagging transactions as RBF which users don’t want to have flagged. Why should we decide for them. Why not let users decide?

This is not a correct framing. Nothing is changing about individual transactions.

As an example, consider Alice as the tx creator and Bob as the node runner. All that is changing is that if Bob chooses to run their node with mempoolfullrbf=1, and Alice chooses to create a replacement transaction (even if Alice forgot to signal rbf on the original), Bob’s node will accept the replacement transaction to their mempool. If Bob doesn’t like people sending replacements for txs where the original did not signal rbf, they can leave mempoolfullrbf to the default option of off and their node will reject replacement txs if the original was not signalling rbf.

benpbolton commented at 4:18 pm on November 22, 2022: none

…you can check service flag REPLACE_BY_FEE or UNKNOWN of peers and ban them with setban RPC.

Not only is REPLACE_BY_FEE not a valid broadcasted service flag (nor net permission flag, connection type, etc.)… the point of my comment was that segregation based on these mechanisms is undesirable. (If I wanted a broad net, maybe I’d just block v 24.0)

This is not a correct framing. Nothing is changing about individual transactions.

In your framing, something is changing about the acceptance and ‘good faith’ validity of individual transactions, though. Basically introducing ‘involuntary replace-by-fee’ and ‘your money will spend fine here, but not over there…’ mechanisms

Default config nodes using existing opt-in RBF will be blind to any full-RBF replacements.

Among other issues, this.

Edit: I don’t understand why mempoolfullrbf behavior isn’t present in peerinfo. We mention things like minfeefilter … bah. There’s so much about this that is internally inconsistent, feature reductive, divisive, etc. All for the philosophical goal of pushing the “it aint true until its in the blockchain’ point with no nods for “it ain’t true until it’s been confirmed for X blocks, etc” as a logical extension. Some risk/convenience tradeoff is going to want to operate on ‘good faith’ at lower confirmation counts (or no confirmation counts, as we see). The behavior change this PR correctly reverts changes the pre-consensus rules in inconsistent ways.

josibake commented at 5:03 pm on November 22, 2022: member

In your framing, something is changing about the acceptance and ‘good faith’ validity of individual transactions, though. Basically introducing ‘involuntary replace-by-fee’ and ‘your money will spend fine here, but not over there…’ mechanisms

I’m not sure what you mean by ‘involuntary replace-by-fee’ or the second sentence, but I suspect you’re referring to merchant software and merchant behavior, which is entirely out of scope for this codebase.

As it stands today, a transaction can only be replaced by the originator of the transaction, so there is no “involuntary replacement.” This PR is attempting to take away the ability of bitcoin users to configure their own mempool as to whether or not they reject replacement transactions when the original transaction did not signal opt-in RBF.

There is a larger discussion about how unconfirmed transactions should be treated, but I don’t think this PR is the place to have it. At the end of the day, the Bitcoin network is a p2p network of users running nodes. If users don’t want this option for their mempool, they will leave it to its default setting of off. If users do want it for their mempool, they will turn it on.

Seems like the better place to be having the unconfirmed transactions discussion would be with the users who run the software themselves.

Trying to prevent users from having an option because you don’t agree with the effects it would have on the network doesn’t seem like the correct approach at all to me.

benpbolton commented at 5:16 pm on November 22, 2022: none

Trying to prevent users from having an option because you don’t agree with the effects it would have on the network doesn’t seem like the correct approach at all to me.

I think you and I agree on this. My challenge here is that you’re not applying the logical equally to node operators and transaction submitters.

If I want my transaction to be non-rbf… and a mempoolfullrbf node then accepts a subsequent transaction from me as though it was rbf… that ain’t right. Trying to prevent users from having an option because you don’t agree with the effects it would have on the network doesn’t seem like the correct approach at all to me.

josibake commented at 5:25 pm on November 22, 2022: member

If I want my transaction to be non-rbf… and a mempoolfullrbf node then accepts a subsequent transaction from me as though it was rbf… that ain’t right. Trying to prevent users from having an option because you don’t agree with the effects it would have on the network doesn’t seem like the correct approach at all to me.

In your scenario, you are making demands of other users on the network: “hey, if I send a follow-up transaction, I wan’t you to reject it.” You cannot control what other Bitcoin users do and you certainly cannot control how they decide to configure their nodes. If you want your transaction to be non-rbf, don’t send a replacement transaction.

Transisto commented at 5:38 pm on November 22, 2022: none

Alice chooses to create a replacement transaction (even if Alice forgot to signal rbf on the original)

The odds of these users existing are extremely insignificant, only 26% of transaction signal RBF, ~90% of transaction that signal RBF are by default and dont have an RBF setting at the transaction level. 99.9% of RBF capable wallet were set on by default.

There’s about 10000 more users of lightning than the above.

Fullrbf does force users into RBF by removing any benefits of not signaling RBF while not even having a wallet that support increasing the fee.

The common usage for zeroconf that I commonly see is ; the customers doesn’t expect instant settlement and get to wait multiple blocks or not wait at all, while RBF only wait one block if they keep increasing their fee. (CPFP aside)

I was also a proponent of zeroconf being too risky for merchant until the RBF flag feature legitimized the intent of users not signaling it to miners.

You don’t seems to understand how sensitive this relaying policy is. If only 5% of nodes and miners enables it because they blindly follow Core’s wisdom thousands of merchants will need to have to change theirs practice or lose money because they were not made aware that it was decided by a small group that it’s acceptable enough to delete “First seen” by adding a disable option. Seems like nobody can genuinely argue for a short term benefits of this Fullrbf option except giving @petertodd and the likes a hard-on to destroy what they long argued was too unsafe for use.

If you give users any options a good % will toggle it on at random without much concern for the wider consequences.

It is unacceptable to leverage the reference implementation’s fabric to speed up destruction of “First seen” / zeroconf mainly because “they were never safe enough in the first place”.

benpbolton commented at 5:39 pm on November 22, 2022: none

you are making demands of other users on the network

Yeah. “If i make a transaction not replaceable by fee, reject anything attempting to replace it by fee.” Some other demands include “if I don’t sign this transaction, I want you to reject it”… the same expectation and demands that were in place prior to the commit this reverts.

don’t send a replacement transaction

How about I just mark it first-seen non-rbf. There are fantastical scenarios I could concoct (I send my last btc away non-rbf before the fellows bust in with their guns… now they point a gun to my head and say “just replace it”), but those are all weak beside the argument that a user should not be allowed to break the rules they set. They should not. They wanted this. They asked for it… nodes and network should enforce it.

ghost commented at 6:01 pm on November 22, 2022: none

@1440000bytes: One can and anyone is free to ban whichever peers they want. From a network perspective (and perhaps even an individual node perspective) I don’t think it is optimal that the zero conf nodes ban the full RBF nodes or vice versa. The P2P/policy/mempool devs will have a more informed perspective but I would have thought this doesn’t achieve much apart from fragmenting the network into segments. A zero conf node has to eventually verify a valid RBF spend if it is mined in a block even if it initially refuses to allow it into its mempool and refuses to peer with full RBF nodes. It doesn’t seem optimal that it refuses to verify that transaction until the last possible moment i.e. it is forced to verify it because it has been mined.

So free to ban, certainly. But I don’t think it achieves much if anything. @michaelfolkson Nobody has information about the impact if most of the nodes ban based on service flag.

It was sarcasm and I do not care because he won’t ban or if he does won’t affect anything:

Context: #25600

BAN nodes signalling full rbf with bitcoin knots or #25600

Bitcoin is beyond this and there will be nodes using full rbf without signalling

FYI: #25600 was not merged in core

josibake commented at 6:03 pm on November 22, 2022: member

You don’t seems to understand how sensitive this relaying policy is. If only 5% of nodes and miners enables it

I do understand how sensitive this policy is. If you are relying on > 95% of the network to run a specific mempool policy, knowing that miners and users can set whatever policy they want, then it might be time to reconsider your approach as a merchant. This has nothing to do with Core. If a new implementation comes out tomorrow with mempoolfullrbf on by default or if > 5% of the network decides to run Bitcoin Knots, it would have the same effect.

But as I said before, I don’t think this PR is the right place to be having a discussion about the merits/risks of accepting unconfirmed transactions as payment. The correct place to have that discussion is with the users who run and configure their nodes.

benpbolton commented at 11:22 pm on November 22, 2022: none

I don’t think this PR is the right place to be having a discussion about the merits/risks of accepting unconfirmed transactions as payment. The correct place to have that discussion is with the users who run and configure their nodes.

How do you not see the circles in justification here?

The correct place to have that discussion is with the users who run and configure their nodes.

vs.

The correct place to have that discussion is with the users who send transactions.

I do not want to debate merits/risks of accepting unconfirmed transactions as payment OR the merits/risks of sending RBF vs non-rbf. The point is that the nature of “what are the characteristics of an unconfirmed transaction” is open to shift with 24.0… as is the nature of “what does non-rbf mean if accepting nodes have a convenient toggle to change that definition under load.”

I’ve run luke-jr forks before, and I’ll likely do so again, but I disagree with him here. Implementation wise, this was controversial to begin with, the original DoS legs are shorter than we thought… the real-world use cases are more nuanced and present than we thought… and the original change was against the status quo, adds code-branching (maintenance) complexity, adds complexity to mempool logic under load, degrades consensus by creating two classes of (core) nodes at high mempool states… for what good?

I dunno. I feel like “pre consensus” rules guidelines are worth fighting a bit harder here than just saying “whelp, the tech debt we recently merged that requires us to shift conversation targets (from users to node operators), has unknown risk factors and unclear (any?) network benefits, and blew up some business practices that we didn’t like the risk factors for is already in, so let’s keep going!”

vostrnad commented at 11:55 pm on November 22, 2022: none

@benpbolton There is no shift in conversation targets. If you don’t like a policy that some node operators use, then these node operators were always who you needed to convince. This PR is not about convincing node operators but about forcing them to either run a custom patch or an alternative implementation or to run with an undesired mempool policy.

ghost commented at 0:29 am on November 23, 2022: none

I rectract my NACK

I am neutral and okay with testing full RBF with https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021216.html

so ACK https://github.com/bitcoin/bitcoin/pull/26525/commits/c632df98a2810d6ebded239364dba7258097ea61

petertodd commented at 1:31 am on November 23, 2022: contributor

On November 22, 2022 6:29:51 PM CST, 1440000bytes @.***> wrote:

I rectract my NACK

I am neutral and okay with testing full RBF with https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021216.html

How do you expect people to use this signet without a ‘mempoolfullrbf ’ option?

petertodd commented at 4:59 am on November 23, 2022: contributor

On November 22, 2022 9:44:27 PM CST, Benjamin Bolton @.***> wrote:

How do you expect people to use this signet without a ‘mempoolfullrbf ’ option?

checkout/compile on petertodd:2022-feebump-without-optin, see #26454

That pull-req requires the ‘mempoolfullrbf’ option to work in most circumstances. And of course, people use more than just Bitcoin Core.

ursuscamp commented at 8:35 pm on November 23, 2022: none

ACK

I support full RBF and would probably turn this feature on in my node if it were provided. I am sympathetic to all of the full RBF arguments. Nevertheless, the change is controversial so why force a controversial change? Full RBF is inevitable in the long run anyway, so maybe just let it happen naturally.

ghost commented at 6:22 pm on November 24, 2022: none

On November 22, 2022 6:29:51 PM CST, 1440000bytes @.***> wrote: I rectract my NACK I am neutral and okay with testing full RBF with https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021216.html How do you expect people to use this signet without a ‘mempoolfullrbf ’ option?

RC4

I never wanted to suggest RC for users. I am done with this debate. Happy with any outcome.

petertodd commented at 6:35 pm on November 24, 2022: contributor

On November 22, 2022 6:29:51 PM CST, 1440000bytes @.***> wrote: I rectract my NACK I am neutral and okay with testing full RBF with https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021216.html How do you expect people to use this signet without a ‘mempoolfullrbf ’ option?

RC4

I never wanted to suggest RC for users. I am done with this debate. Happy with any outcome.

Well https://github.com/bitcoin/bitcoin/releases/tag/v24.0 has been released and lots of people are already running it with mempoolfullrbf=1, so that ship has sailed.

ajtowns requested review from ajtowns on Nov 24, 2022

ajtowns removed review request from ajtowns on Nov 24, 2022

artdesignbySF commented at 8:57 am on November 25, 2022: none

Well https://github.com/bitcoin/bitcoin/releases/tag/v24.0 has been released and lots of people are already running it with mempoolfullrbf=1, so that ship has sailed.

Can I manually change it to mempoolfullrbf=0 after I update…? And what would that accomplish, if anything?

vostrnad commented at 8:58 am on November 25, 2022: none

@artdesignbySF The option is default false, so if you prefer not to use this policy on your node, you don’t have to do anything at all, even if you update.

artdesignbySF commented at 9:11 am on November 25, 2022: none

@vostrnad wasn’t the whole point to enable full RBF? Now you say mempoolfullrbf=1 means it is disabled? I’m probably not understanding. Sorry.

Edit: I’m guessing it ships with mempoolfullrbf=0 and folks can toggle it on themselves to =1

vostrnad commented at 9:56 am on November 25, 2022: none

@artdesignbySF The point was to provide users with an option to enable full RBF on their node, if that’s what you mean by “enable full RBF”. If you’re still confused, you might be interested in reading the accompanying release notes.

If you have more questions, please post them on Bitcoin Stack Exchange or elsewhere, as pull request comments are primarily meant for reviewing and discussing the proposed code changes.

artdesignbySF commented at 10:16 am on November 25, 2022: none

Ok, I think I get it now. Thank you for your time and effort. I appreciate it!

ZenulAbidin commented at 5:50 pm on November 29, 2022: contributor

NACK (not a core maintainer of course, just a user/independent developer)

Here’s my 2 sats on this:

95% of wallets and exchanges will never implement the RBF option, even though it is several years (decade?) old. That means the users of those wallets will effectively have their assets frozen while making a transaction, if the mempool suddenly balloons overnight and they are unaware of that.

Full RBF will do away with all that and allow you to import your privkeys into an RBF-supporting wallet and fix the TX manually.

People here are talking about how bad this is going to be for the businesses, but imagine the scenario of users making a payment to a gateway during a congested mempool, without RBF wallets, and then the tx confirms far too late when the payment has already expired. They have even less recourse than the businesses to make up for the lost money.

CraigSellars commented at 12:55 pm on November 30, 2022: none

This is a critical issue. The default change broke the double-spend solution.

If I receive a signed unmined transaction, where I have validated - against my copy of the blockchain - that the unspent output is valid, I can presume the payment is “complete” (because if it’s not in the mempool, I’ll broadcast it), unless the sender has explicitly stated via RBF that they might change the transaction by modifying the fee, I am certain it will not be otherwise spent. (replaced earlier statement saying certain it will be mined)

The change in default made every transaction suspect, removing the certainty expressed above.

stickies-v commented at 12:58 pm on November 30, 2022: contributor

I am certain it will eventually get mined.

No, you can’t be.

SkanderHelali commented at 1:15 pm on November 30, 2022: none

This is a critical issue. The default change broke the double-spend solution.

If I receive a signed unmined transaction, where I have validated - against my copy of the blockchain - that the unspent output is valid, I can presume the payment is “complete” (because if it’s not in the mempool, I’ll broadcast it), unless the sender has explicitly stated via RBF that they might change the transaction by modifying the fee, I am certain it will eventually get mined.

The change in default made every transaction suspect, removing the certainty expressed above.

The flag is set to false by default, so not sure what you’re referring to.

Transisto commented at 2:16 pm on November 30, 2022: none

NACK (not a core maintainer of course, just a user/independent developer)

Here’s my 2 sats on this:

95% of wallets and exchanges will never implement the RBF option, even though it is several years (decade?) old. That means the users of those wallets will effectively have their assets frozen while making a transaction, if the mempool suddenly balloons overnight and they are unaware of that.

Full RBF will do away with all that and allow you to import your privkeys into an RBF-supporting wallet and fix the TX manually.

People here are talking about how bad this is going to be for the businesses, but imagine the scenario of users making a payment to a gateway during a congested mempool, without RBF wallets, and then the tx confirms far too late when the payment has already expired. They have even less recourse than the businesses to make up for the lost money.

95% of the wallet and exchanges??? Once people have been burned by waiting a few hours or days will they not change wallet?

Aside that the mempool has been near empty for 3 years, are you aware that both the sender and recipient can increase the effective fee via CPFP? All wallet that support spending entire balance can do CPFP.

ziggamon commented at 10:33 pm on November 30, 2022: none

As some of you already know, several Bitcoin projects and merchants raised an alarm about the recent proposal to facilitate an agenda to convert Bitcoin mempools from using first-seen policy, to using “full RBF.”

In terms of usage of RBF functionality it’s been shown at the most opportune time during the binance consolidation to be used by less than 1% of bitcoin transactions, or 5% of users signalling opt-in RBF. https://twitter.com/ziggamon/status/1592613046421426179

As it turns out, even the author of this zeroconf-breaking feature supports its removal, and he has suggested that we provide some statistics showing the impact of zeroconf acceptance from our view. These stats show actual utilization of zeroconf to benefit Bitcoiners, at scale. These stats show what utility may be lost if the mempools convert to opting standard txns into RBF policy without their request. We only care about this because Bitcoin users care about this and we want to see Bitcoin used for commerce more, not less.

These numbers are from September 2022, a typical month for us. The unit is in payments, broken down into those that got zeroconf processed and those which didn’t, and why they didn’t:

Total on chain: 46297 Zeroconf: 31983 (68%) Not zeroconf: 14314 (31%)

Not zeroconf reasons: RBF 8345 (18%) Too low fee rate 3014 (6%) Too many unconfirmed ancestors 531 (1%) Not eligble for zeroconf due to high value 2424 (5%)

Transactions cancelled (double-spent) by user 104 Of which received product 0

Not sure if this data changes anything, this is just for our company, there are many competitors, merchant services and individual btcpayserver operators operating in similar ways to us, accepting a certain amount of risk on lower-value transactions in order to benefit users and provide a more clear user experience. How many that is is hard know for sure but it’s safe to say it’s a multiple of the above, all of which will be impacted in unpredictable ways if this new policy becomes used on bitcoin.

ZenulAbidin commented at 10:50 pm on November 30, 2022: contributor

95% of the wallet and exchanges??? Once people have been burned by waiting a few hours or days will they not change wallet?

The wallets maybe, but the exchange is harder to change for some people because they might not support the same deposit/withdraw methods, and dubious geo-restrictions and KYC processes will limit the number of alternatives a user has anyway. I do not know which exchanges do RBF internally if any even do so at all. And the above only applies to bitcoiners like you and me; newbies will just give up on bitcoin instead of switching wallets (or using Lightning).

Aside that the mempool has been near empty for 3 years, are you aware that both the sender and recipient can increase the effective fee via CPFP? All wallet that support spending entire balance can do CPFP.

Unfortunately, that does not work if the parent tx already spends the entire balance (or as much balance so that the remainder is not a sufficient tx fee). So that helps in some circumstances but not in all of hem.

Here’s the big picture:

People who get started on Bitcoin will only give us one chance to make it (bitcoin) work properly. Any kind of UX issue will in most cases cause us to lose that user forever, they are usually not going to come to a forum for technical support. The Bitcoin protocol is slow to change over several years, so people will think they are dealing with the same software more or less. Which means even if the underlying issue gets fixed, psychological state of mind will prevent former users from coming back.

Full RBF is by no means a pancrea. It does not solve all problems of Bitcoin or even transactions. But it is a step in the right direction. Direction is something charted by the Bitcoin community, not by Bitcoin Core developers alone. Community includes users, merchants, developers, regulators, companies, influencers etc etc who are interacting with Bitcoin in some way.

Now most people will never vote on policy issues, so what happens is that a minority of people end of voting instead. 100-200 or so people weighing in on this Github issue and the mailing list thread and forum threads is all we got, and though its a far cry from millions of Bitcoin users, it is what it is.

The phenomenon that OP and some other people are calling gaslighting is just a consequence of having a minority of people discussing this issue. That a large portion of the accused are Bitcoin Core developers is simply because we are on official Bitcoin Core channels.

Segwit and the block size wars was just one example of the community getting split and then reaching a consensus that resolves the issue in a way that is good for everyone. And eventually, this is what will happen here as well. Possibly in the years after Full RBF is deployed en-masse in a future Bitcoin Core version.

ZenulAbidin commented at 10:59 pm on November 30, 2022: contributor

Seperating this from my other comment:

As it turns out, even the author of this zeroconf-breaking feature supports its removal, and he has suggested that we provide some statistics showing the impact of zeroconf acceptance from our view. These stats show actual utilization of zeroconf to benefit Bitcoiners, at scale. These stats show what utility may be lost if the mempools convert to opting standard txns into RBF policy without their request. We only care about this because Bitcoin users care about this and we want to see Bitcoin used for commerce more, not less.

If you really think this is a good idea, it would help to open-source the intelligent double-spending tools in question. Because right now, maybe you and a few other vendors know how to do this properly, but this info is not public. There is not even an internet tutorial on how to write code for correctly classifying zeroconf transactions.

CraigSellars commented at 4:29 am on December 1, 2022: none

The flag is set to false by default, so not sure what you’re referring to.

Under which conditions might the default be changed to true? And what would be the effect?

Transisto commented at 9:57 am on December 1, 2022: none

The wallets maybe, but the exchange is harder to change for some people because they might not support the same deposit/withdraw methods, and dubious geo-restrictions and KYC processes will limit the number of alternatives a user has anyway. I do not know which exchanges do RBF internally if any even do so at all.

I didn’t bother addressing your concern about exchanges because I thought it was such an obvious miss understanding of how those are unrelated. Exchanges have the most ressources to deploy and have zero problem building any transactions that confirms. The best way way for them to operate after a fee surge is to rbf only one child UTXO and leave the large withdrawal transaction intact.

Are you aware that the large exchanges charge about 0.0005 btc to add a single 50 bytes output to their batch? That’s about 1000 sat/bytes when a few sat/B is plenty. People should limit use of exchange to a minimum and No! they should not send 100% of what they just received without having enabled RBF. Your assuming an impossible chain of fails that would imply bad practice from 3 completely clueless entity, including well funded exchanges. This is so unlikely it is ridiculous.

ZenulAbidin commented at 11:35 am on December 1, 2022: contributor

The wallets maybe, but the exchange is harder to change for some people because they might not support the same deposit/withdraw methods, and dubious geo-restrictions and KYC processes will limit the number of alternatives a user has anyway. I do not know which exchanges do RBF internally if any even do so at all.

I didn’t bother addressing your concern about exchanges because I thought it was such an obvious miss understanding of how those are unrelated. Exchanges have the most ressources to deploy and have zero problem building any transactions that confirms. The best way way for them to operate after a fee surge is to rbf only one child UTXO and leave the large withdrawal transaction intact.

Fair enough. But the issue pertaining to wallet software remains - not everyone is using Bitcoin Core or Electrum or Sparrow as their wallet.

iBeizsley commented at 2:19 pm on December 1, 2022: none

Fair enough. But the issue pertaining to wallet software remains - not everyone is using Bitcoin Core or Electrum or Sparrow as their wallet.

It’s a nice idea, but I am utterly unconvinced that any significant number of people currently using terrible wallets will see a transaction stuck in the mempool, go Google solutions, find Full RBF, pick a wallet which supports it, connect to a node (by chance or intention) which will relay their full RBF transaction, and successfully resolve the problem.

These users are (largely) using these wallets because they don’t know any better, and more often than not, their exchange, or some YouTuber told them ‘use this’, and they followed those instructions without even considering there might be alternatives.

That said given the config flag now exists on a stable release, I’m not convinced removing this flag would make much sense anymore. People who have actively configured 1 will just resist updating to a version which removes this flag. If anything, I think (assuming full RBF actually sees any significant level of use) the next step is probably a default 1 value.

BitcoinErrorLog commented at 5:47 pm on December 1, 2022: none

That said given the config flag now exists on a stable release, I’m not convinced removing this flag would make much sense anymore. People who have actively configured 1 will just resist updating to a version which removes this flag.

We can’t have a Bitcoin Core where things are permanent just because they snuck through. The process failed. Normal rules were not followed. A controversial change was rushed in with only the Bitcoin Core developer userbase being aware. The community is now more aware and it is quite clear this is controversial and impacts a lot of people. The mempool status quo is at risk of a negative change. A change I have argued will negatively impact users, merchants, miners, and overall Bitcoin utility.

Now Bitcoin Core has to demonstrate that it can responsibly handle this kind of situation. If Core lets this change stand, it is a message to users that these devs are an authority, and if users ever want to conflict with Bitcoin Core agendas, they will need to be ready to fork the code or undertake a massive campaign, beyond what I had to do here. Does Bitcoin Core care about the trust of users and merchants? I hope so. If not, who is Bitcoin for exactly?

Some people may indeed stick to v24 and run that, but I am skeptical. People run latest versions, and the fullrbf movement could die on the vine if removed immediately. As it should.

brandonblack commented at 5:51 pm on December 1, 2022: none

A controversial change was rushed in with only the Bitcoin Core developer userbase being aware.

The fact that you and others have turned a non-consensus, default-off configuration flag added to bitcoin client software into a controversy is the problem.

BitcoinErrorLog commented at 6:14 pm on December 1, 2022: none

The fact that you and others have turned a non-consensus, default-off configuration flag added to bitcoin client software into a controversy is the problem.

If only everyone would bow to your every whim, then there would surely be no problems.

CraigSellars commented at 6:18 pm on December 1, 2022: none

A controversial change was rushed in with only the Bitcoin Core developer userbase being aware.

The fact that you and others have turned a non-consensus, default-off configuration flag added to bitcoin client software into a controversy is the problem.

I respectfully disagree - raising concerns about the installation of (what is perceived as) a “non-consensus, default-off” self-destruct button is not the problem. The concerns are how it was introduced, how it was approved and how it is being promoted, as well as what the intended (and unintended) effects will be.

The most helpful comments I’ve seen here are those which try to provide metrics on actual prior and potential future usage of RBF to gauge user intent. It seems those metrics haven’t been given due consideration.

SkanderHelali commented at 6:24 pm on December 1, 2022: none

Friendly reminder that this was discussed at length in the mailing list for months. Followed by the discussion pre-24 that is now closed.

Nothing was ‘snuck in’, and the attempt at framing this that way is disingenuous.

You disagree with mempoolfullrbf, and you argued against it. Ultimately more people agreed / you weren’t convincing. The option was merged, and the issue was closed. This entire PR is both a duplicate and a waste of time. Anything of value was already said.

iBeizsley commented at 6:30 pm on December 1, 2022: none

Now Bitcoin Core has to demonstrate that it can responsibly handle this kind of situation.

I understand this argument, just personally not that interested in the politics of this all. You could be right that most who have actively configured 1 wouldn’t hang around on an old version just to keep the config option.

Regardless, I’m uneasy with the current situation for the reasons stated previously (in short, the blindness of default config nodes to full-RBF replacements when attempting to use existing opt-in RBF to speed up a tx being mined), and will be leaving my ACK on this, but I’d also ACK a change to resolve it the other way. Which option is best, I don’t know.

ZenulAbidin commented at 7:04 pm on December 1, 2022: contributor

Note that it will always be possible to run future versions of Core without -mempoolrbf option support just by forking this codebase and applying this patch followed by a compile. I did exactly that when some green trolls attempted to use activism to force a code change here to PoS.

Most people are already running 24 on their nodes with their preferred configurations, and it’s not a good idea to capsize the ship now that it has already set sail.

luke-jr commented at 9:20 pm on December 1, 2022: member

@ziggamon

even the author of this zeroconf-breaking feature supports its removal,

This is not true at all.

These stats show actual utilization of zeroconf to benefit Bitcoiners, at scale. These stats show what utility may be lost

This is just you arbitrarily and discriminatively deciding whether or not to trust people, and threatening to distrust more if you don’t get your way.

It is exactly this kind of discrimination, that is a reason to enable full RBF.

accepting a certain amount of risk on lower-value transactions in order to benefit users and provide a more clear user experience.

This policy does not change your ability to trust users in such a manner. @BitcoinErrorLog

If Core lets this change stand, it is a message to users that these devs are an authority,

YOU are the one trying to force devs to be an authority by telling users what they aren’t allowed to do. Stop spreading these lies.

if users ever want to conflict with Bitcoin Core agendas, they will need to be ready to fork the code or undertake a massive campaign, beyond what I had to do here.

That’s been the case for years now, which is why the last actual two protocol changes to Bitcoin had to go through forked clients. It is not, however, applicable to RBF, which is just a policy, and your policy is still supported (and even the default!). @ZenulAbidin

Most people are already running 24 on their nodes

Less than 5% of the network has upgraded to 24. (This is somewhat normal.)

josibake commented at 4:56 pm on December 2, 2022: member

Transactions cancelled (double-spent) by user 104

Thanks for providing the data @ziggamon. In this category of canceled transactions, how many of the cancellations were from RBF signaling transactions vs non-signaling transactions?

luke-jr commented at 7:27 pm on December 2, 2022: member

how many of the cancellations were from RBF signaling transactions vs non-signaling transactions?

It’s going to be higher for RBF-signalling simply because the wallet software only allows/supports doing it for signalling transactions (ie, not because of relay policies).

ziggamon commented at 8:13 pm on December 2, 2022: none

All of them yes

petertodd commented at 8:54 pm on December 2, 2022: contributor

On December 2, 2022 2:13:32 PM CST, Sergej Kotliar @.***> wrote:

All of them yes

So am I correct in saying no-one has even attempted to double spend you with full-rbf?

Transisto commented at 10:03 pm on December 2, 2022: none

On December 2, 2022 2:13:32 PM CST, Sergej Kotliar @.***> wrote: > All of them yes So am I correct in saying no-one has even attempted to double spend you with full-rbf?

Pretty sure you and Luke both tried but never succeeded at relaying your TXs otherwise I don’t think we’d be here.

petertodd commented at 10:53 pm on December 2, 2022: contributor

On December 2, 2022 4:03:47 PM CST, Transisto @.***> wrote:

On December 2, 2022 2:13:32 PM CST, Sergej Kotliar @.***> wrote: > All of them yes So am I correct in saying no-one has even attempted to double spend you with full-rbf?

Pretty sure you and Luke both tried but never succeeded at relaying your TX otherwise I don’t think we’d be here.

At relaying what TX? I’ve never tried to double spend Bitrefill.

Transisto commented at 11:09 pm on December 2, 2022: none

At relaying what TX? I’ve never tried to double spend Bitrefill.

We’d never know, but you seems committed to enabling other to do it though.

Here’s Luke with strong convictions but all talk https://twitter.com/LukeDashjr/status/1596638058035957760

luke-jr commented at 1:50 am on December 3, 2022: member

I’m not a criminal.

kaloudis commented at 5:30 am on December 3, 2022: none

NACK

greenaddress commented at 9:25 am on December 3, 2022: contributor

NACK - same reasons as provided in https://github.com/bitcoin/bitcoin/pull/26438

i5hi commented at 10:25 am on December 3, 2022: none

It is exactly this kind of discrimination, that is a reason to enable full RBF.

How is this a good reason?

i5hi commented at 10:26 am on December 3, 2022: none

ACK - no good reason for this upgrade.

Asked multiple devs to provide one - no one has been able to explain why this is beneficial to a node operator.

i5hi commented at 10:32 am on December 3, 2022: none

NACK - same reasons as provided in #26438

please point to a specific comment in this PR that provides a benefit in and of itself. Most of the comments are just attacks on zero conf.

Transisto commented at 10:40 am on December 3, 2022: none

I’m not a criminal.

You’re being a fudster. You claim 100% certainty that nonFBF can be reliably double spent then show interest in the offer aside that 0.01 btc to earn 0.09 BTC is too much. Please expand on what kind of double-spend practicing you’re talking about.

I think you’re simply wrong, you fail when you assume zero cost of attack in your model. Your counter offer of 0.1 for 0.1 wouldn’t be a valid test in the merchant context.

In person customers have some form of reputational risk cost but more importantly they also have to pay the merchant profit margin.

MempoolfullRBF in this reference implementation is a dangerous precedent of scattered incompatible conviction.

What would be acceptable instead is a -scorched_earth configuration that doesn’t respect First Seen but also implement a new DoNotRBF tx flag that let spenders announce to the network their intent not to replace due to some bad weather in the mempool. (CPFP works well to solve low fees).

In 2017 bip125 RBF feature has legitimized the use of nonRBF to signal intention of finality.

The mouthful “mempoolfullrbf” is a regression atempt that ads complexity. It should have happened upstream of “First seen” and announced as such.

michaelfolkson commented at 10:51 am on December 3, 2022: contributor

I’m not sure how many of these GitHub pseudonyms are AI generated throwing around dumb AI generated takes. Quite bewildering to follow to be honest.

Are we discussing whether Luke is a criminal now? Ok… I don’t think Luke is a criminal. A criminal wouldn’t have played an important role in building and defending Bitcoin for over a decade. They’d have taken the first opportunity to harm Bitcoin’s long term prospects and enriched themselves in the process.

Enough already, gosh.

Transisto commented at 11:03 am on December 3, 2022: none

Are we discussing whether Luke is a criminal now? Ok… I don’t think Luke is a criminal. A criminal wouldn’t have played an important role in building and defending Bitcoin for over a decade.

Luke bringing in the legal aspect in this context is deflection from explaining why zeroconf without RBF have never been any safer than RBF flagged transaction.

It’s so painful to listen to core devs ignore 13 years of First Seen policy usage now that they’ve built a feature to destroy it. With sole reasoning that more options is better.

michaelfolkson commented at 11:15 am on December 3, 2022: contributor

@Transisto: Nope. Protocol developers (or at least decent protocol developers) are thinking about the long term and building the strongest foundation for higher layers to operate. A remnant from the block size war compromise era isn’t a priority especially when it relies on miners not getting their act together, fees staying low and Bitcoin ultimately not succeeding. I get it is painful when you have a business model that was built on top of that remnant but you should have known that that business model was on borrowed time eventually. We can’t hitch the Bitcoin protocol and the viability of higher layers to your flawed business model. There are plenty of altcoins that will pander to flawed designs and flawed business models, Bitcoin shouldn’t join them.

nvk commented at 11:27 am on December 3, 2022: none

Unsubscribed.

This has devolved into Ad hominem. My suggestion would be to close comments here before further deterioration. Nothing constructive is coming out of this. I think both sides are fully dug in and this PR has no chance.

Transisto commented at 11:41 am on December 3, 2022: none

A remnant from the block size war compromise era isn’t a priority especially when it relies on miners not getting their act together, fees staying low and Bitcoin ultimately not succeeding.

Are you saying First Seen is a remnant of blocksize war? Or you mean opt-in RBF flag instead of removal of first seen was caused by blocksize war era over conservatisim?

Very few business model actually depend on zeroconf, about as many that can rely on lightning at the moment.

Unsubscribed

Yes, @nvk, your online business that ship product doesn’t care, Thanks for your contribution.

nvk commented at 11:53 am on December 3, 2022: none

Yes, @nvk, your online business that ship product doesn’t care, Thanks for your contribution.

I do care, I do business with Bitrefil and care about people having successful businesses on top of bitcoin. But, I care more about people being realistic about zero-confirmation expectations and find better alternatives than relying on a bad foundation.

have a good day sir.

michaelfolkson commented at 11:54 am on December 3, 2022: contributor

Or you mean opt-in RBF flag instead of removal of first seen was caused by blocksize war era over conservatisim?

Every transaction can be RBF’ed. If miners got their act together and/or fees were higher to incentivize miners to get their act together you’d be able to submit a RBF transaction easily to miners bypassing the signaling which would make past merchant data on zero conf safety irrelevant. We don’t need to delude ourselves today.

I agree with @nvk though, commenting on this just seems to feed the time wasting at this stage so will unsubscribe also.

bitcoin locked this on Dec 3, 2022

bitcoin unlocked this on Dec 6, 2022

BitcoinErrorLog commented at 3:09 pm on December 10, 2022: none

@michaelfolkson

Every transaction can be RBF’ed. If miners got their act together and/or fees were higher to incentivize miners to get their act together you’d be able to submit a RBF transaction easily to miners bypassing the signaling which would make past merchant data on zero conf safety irrelevant. We don’t need to delude ourselves today.

If transactions were always as trivially replaceable as you say, then we don’t need formalized RBF, mempoolfullRBF, or any such policy at all.

So which is it, do transactions need mempool policy assistance or don’t they?

hsjoberg commented at 0:49 am on December 13, 2022: contributor

A late Concept ACK. I see no reason to shock the network by releasing this configuration. Furthermore the on-going discussion in the mailing list affirms this.

Daniel600 commented at 12:35 pm on December 15, 2022: none

Adding relevant data that we see it at GAP600 -we offer 0-conf acceptance service- data was previously posted to the mailing list - In addition we are aware of significant merchants who have developed there own tools and offer 0-conf acceptance to their clients.

We service circa 900k Bitcoin unique trx hashs per month, with that representing circa 1.5M different address deposits per month. Clients are primarily payment processors and liquidity providers servicing non-custodial wallets. One of our clients Coinspaids CEO provided an email confirming benefits and address clusters and is open to discuss further- see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html

I can see that from https://ycharts.com/indicators/bitcoin_transactions_per_day that there is on average circa 250k Bitcoin trxs a day - so trxs benefiting from 0-conf are a significant part of the use case.

I would suggest considering adding First Seen Safe - FullRBF as being a way forward here

BitcoinErrorLog commented at 12:52 pm on December 15, 2022: none

For reference, FSS-RBF was proposed by Peter Todd originally in 2015 here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html

And demonstrated here: #6176

I would entertain closing this PR if FSS-RBF were implemented, as my original goal was always to do FRBF at the wallet level, and let merchants communicate exceptions for when to turn it off via extended BIP-21 specs … As a design this is not much different than flagging a txn as FSS-RBF, as long as Bitcoin Core nodes respect it by default as an exception to FRBF policy.

Daniel600 commented at 12:59 pm on December 15, 2022: none

The approach here is slightly different to Peters proposal as that was relevant for OptinRBF and signalling the trxs when it was initially published - in this case with FullRBF it is a mempool inclusion/replacement rule i.e a node will swop out the trx for a newer trx with at least same outputs but a larger miner fee. So lightly different but rule set same.

luke-jr commented at 1:28 pm on December 15, 2022: member

let merchants communicate exceptions for when to turn it off via extended BIP-21 specs

This nonsense alone is reason to go exclusively full RBF and not hesitate or look back.

BitcoinErrorLog commented at 2:35 pm on December 15, 2022: none

This nonsense alone is reason to go exclusively full RBF and not hesitate or look back.

I, and probably everyone, would really appreciate it if you kept your replies to actual technical arguments, or ideally, solutions that improve on proposed designs, instead of making noise about “nonsense” and begging people to ignore ideas.

I am expressing a willingness to compromise, and the compromise is simply asking for fair treatment. If FRBF proponents want to argue optionality as an excuse for FRBF and killing FSS, then it is totally rational for us to request a formalized opt-in FSS feature.

So, either argue why that is impossible or harmful, or help design the best way to achieve that. Or, ACK this PR and move on.

We are all here for the same reasons, and no one’s goal should be to harm use cases. Be helpful, like you used to be! You, and all of us, will feel better.

reardencode commented at 3:07 pm on December 15, 2022: none

I would entertain closing this PR if FSS-RBF were implemented

My node will never run such a thing. One of the main use cases for RBF is to cancel an unconfirmed transaction for a variety of reasons.

artdesignbySF commented at 4:27 pm on December 15, 2022: none

This nonsense alone is reason to go exclusively full RBF and not hesitate or look back.

I, and probably everyone, would really appreciate it if you kept your replies to actual technical arguments, or ideally, solutions that improve on proposed designs, instead of making noise about “nonsense” and begging people to ignore ideas.

I am expressing a willingness to compromise, and the compromise is simply asking for fair treatment. If FRBF proponents want to argue optionality as an excuse for FRBF and killing FSS, then it is totally rational for us to request a formalized opt-in FSS feature.

So, either argue why that is impossible or harmful, or help design the best way to achieve that. Or, ACK this PR and move on.

We are all here for the same reasons, and no one’s goal should be to harm use cases. Be helpful, like you used to be! You, and all of us, will feel better.

Seconded!

BitcoinErrorLog commented at 5:06 pm on December 15, 2022: none

I would entertain closing this PR if FSS-RBF were implemented

My node will never run such a thing. One of the main use cases for RBF is to cancel an unconfirmed transaction for a variety of reasons.

Maybe you didn’t understand what was suggested, but it was for an opt-in* FSS-RBF feature/flag per txn. It would not affect anyone that did not opt in.

Also, claiming you would “never run such a thing” is hyperbolic, considering you probably ran a FSS mempool in your node for most of your Bitcoin history.

reardencode commented at 5:47 pm on December 15, 2022: none

Maybe you didn’t understand what was suggested, but it was for an opt-in* FSS-RBF feature/flag per txn. It would not affect anyone that did not opt in.

So… a user could opt-in to fss-rbf, but many nodes and miners would be running fullrbf, so the opt-in would signal that nodes should apply an fss-rbf restriction to flagged transactions? I think you must be (once again) imagining that mempool policy is a part of consensus and that you can conjure a network where nodes won’t relay any RBF (with certain rules to prevent DOS).

Also, claiming you would “never run such a thing” is hyperbolic, considering you probably ran a FSS mempool in your node for most of your Bitcoin history.

We are all learning, the Bitcoin rabbit hole is deep and wide. Until recently I used opt-in RBF on ~all of my transactions and was simply annoyed when services such as yours treated them differently (although I haven’t personally used yours, I have used other similar services). With the recent discussion of offering the option to change mempool rules such that all transactions would be treated the same again, it is clear to me that this is the correct way to move bitcoin forward. Accepting unconfirmed transactions for payment (or even to lock in an exchange rate) has always been risky, and this may effect the risks involved. Nobody has been able to show that it actually effects the risks.

benpbolton commented at 6:26 pm on December 15, 2022: none

Where I’m leaning philosophically is that there is such a thing as pre-consensus guidelines that answer the question: what makes a transaction ‘valid’ enough that we should bother storing this in the mempool and rebroadcasting it…

“Pre-consensus” guidelines are enforced on the nodes themselves (won’t broadcast/retransmit transactions that don’t meet ___ criteria). Some of these pre-consensus rules are clear and simple (valid signatures, inputs and outputs, etc)… and others of these are (apparently?) more controversial (didn’t include a minimum fee, etc).

Since the ‘mempool’ is a kind of shared experience, it’s ideal for the network if we can agree on what is desirable there and when someone is ‘peeing in the pool’ so to speak. What full RBF breaks in my mind is the arbitrary and capricious changing of the meaning from the first-seen non-RBF transaction to suddenly become RBF.

First-Seen-Safe but allowed RBF feels like a rational move. full-rbf is irrational. If the user wanted rbf, they mark it. Not respecting that as a mempool is… pardon the pun, kinda 💩ing in the pool.

I completely understand that confirmation counts in the blockchain is the consensus mechanism, by definition… but we are spending time and thought discussing a very valid pre-consensus scenario of under what conditions transactions should be allowed to ‘cut in line’ (yes, theoretically against oneself)… and I’m unwilling to sacrifice the (clearly used) functionality of first-seen because we want to allow line-cutting and mind-changing for larger fees.

I’m OK with line-cutting ( fss-rbf ) for larger fees… but not changing minds (edit for clarity when the user initially stated they would not be changing their mind). If the user broadcasts a transaction with the stated intention of not changing outputs, treat it as such. I believe it’s still worth striving for closer alignment on what constitutes a valid pre-consensus mempool-worthy transaction. Remove -mempoolfullrbf imo

Daniel600 commented at 6:31 pm on December 15, 2022: none

@BitcoinErrorLog - what are your thoughts on FSS-FullRBF i.e FullRBF with the added requirement that trx2 (which replaces) trx1 must include at least the same outputs as trx1 ? In such 0-conf will not be effected, and fee can be increased with additional inputs.

BitcoinErrorLog commented at 6:34 pm on December 15, 2022: none

@BitcoinErrorLog - what are your thoughts on FSS-FullRBF i.e FullRBF with the added requirement that trx2 (which replaces) trx1 must include at least the same outputs as trx1 ? In such 0-conf will not be effected, and fee can be increased with additional inputs.

I am okay with that also, I just thought FSS-RBF as a single txn flag would be more agreeable to the opposition. Your way means that people would still need to opt into old-school RBF if they want to be able cancel/doublespend.

BitcoinErrorLog commented at 6:41 pm on December 15, 2022: none

I think you must be (once again) imagining that mempool policy is a part of consensus and that you can conjure a network where nodes won’t relay any RBF (with certain rules to prevent DOS).

You either agree that mempool polices enforced by default work or they do not. If you do not, then you also do not care about RBF flags or fullrbf. If you do, then my ideas make just as much sense as RBF or fullrbf. Whether these things are consensus only affects interoperability, not whether the designs affect outcomes.

We are all learning, the Bitcoin rabbit hole is deep and wide. Until recently I used opt-in RBF on ~all of my transactions and was simply annoyed when services such as yours treated them differently (although I haven’t personally used yours, I have used other similar services). With the recent discussion of offering the option to change mempool rules such that all transactions would be treated the same again, it is clear to me that this is the correct way to move bitcoin forward. Accepting unconfirmed transactions for payment (or even to lock in an exchange rate) has always been risky, and this may effect the risks involved. Nobody has been able to show that it actally effects the risks.

Everyone always treated RBF txns the same. Merchants make them wait 1+ confs. fullrbf means they will be forced to do that for nonRBF txns too, instead of offering 0conf as a service. This is strictly worse for you as a Bitcoin shopper.

To be clear, mempoolfullrbf means no option for fast buying at merchants. Opt-in FSS ideas mean that you could get faster treatment when supported. You have nothing to lose, only to gain, as a consumer.

Daniel600 commented at 6:47 pm on December 15, 2022: none

I am okay with that also, I just thought FSS-RBF as a single txn flag would be more agreeable to the opposition. Your way means that people would still need to opt into old-school RBF if they want to be able cancel/doublespend.

Yes. With OptinRBF & FSS-FullRBF - users will be able to flagit and completely change a trx (this is a well known option across the wallets/merchants/developers), or not flag it but only be able to increase the fee if so wish & still have 0-conf as an option - those options appears to cover the needs of 0-conf use case as well as enabling speeding up inclusion if desired.

reardencode commented at 8:41 pm on December 15, 2022: none

You either agree that mempool polices enforced by default work or they do not. If you do not, then you also do not care about RBF flags or fullrbf. If you do, then my ideas make just as much sense as RBF or fullrbf. Whether these things are consensus only affects interoperability, not whether the designs affect outcomes.

Default relay/mempool policies are just that, defaults. There are dynamics here somewhat analogous to soft vs. hard forks of the consensus code. If there is a more permissive policy run by some nodes (threshold ~1%? 5%? depending on preferential peering) then that policy overrides a less permissive default policy. If there is a less permissive policy run by some nodes, it has no impact on the more permissive default policy. Game theory here says that once a more permissive policy gains even a small foothold in the network, the only rational move is to change the default. You are trying to fight this game theory by making it harder for people to run the more permissive policy, but the cat is already out of the bag. There is a preferential peering network, Knots, and many node runners like myself who continue to make the default less and less relevant.

Everyone always treated RBF txns the same. Merchants make them wait 1+ confs. fullrbf means they will be forced to do that for nonRBF txns too, instead of offering 0conf as a service. This is strictly worse for you as a Bitcoin shopper.

The point that I (and others) are making is that you are FUDing unconfirmed transaction acceptance in a fullrbf world. You are assuming that fraud rates on unconfirmed will be enough higher to break the business model. You do not have evidence of this. Do you think fullrbf unconfirmed payments will have as high of a chargeback rate as legacy credit card payments? I don’t. One big reason for chargeback is buyer’s remorse which doesn’t really impact the safety of unconfirmed acceptance. The measures that businesses already have in place to detect replacement transactions and screen customers before accepting FSS unconfirmed transactions will also work on fullrbf unconfirmed transactions. They already are.

luke-jr commented at 3:43 am on December 16, 2022: member

This isn’t a technical PR. It’s an attempt to abuse dev influence to force your preferred policies on other people. There is no compromise with such tyranny. You don’t get to dictate what policies others use - PERIOD.

BitcoinErrorLog commented at 8:15 am on December 16, 2022: none

It’s an attempt to abuse dev influence to force your preferred policies on other people. There is no compromise with such tyranny. You don’t get to dictate what policies others use - PERIOD.

Not anymore than the PR that added this feature. The mempoolfullrbf feature literally overrides non-RBF txns and dictates them to be RBF, regardless of whether they chose that behavior for their txn. The tyranny!

luke-jr commented at 9:08 pm on December 17, 2022: member

RBF is a property of your node, not transactions.

i5hi commented at 7:49 am on December 19, 2022: none

This isn’t a technical PR. It’s an attempt to abuse dev influence to force your preferred policies on other people. There is no compromise with such tyranny. You don’t get to dictate what policies others use - PERIOD.

I have not been involved in the early discussions (how it all started) around this issue so please correct me if I’m getting something wrong here.

Many of us feel like the devs are trying to influence a change here NOT the other way around. There seems to be no solid benefit in and of itself and it has a side-effect that breaks a use-case for many vendors (albeit a dangerous use-case).

How is fullmempoolrbf=1 a useful option for my node?

My wallet already allows me to chose whether I want RBF or not, and many default to RBF. So why change the node policy?

It seems to be this is just a convenience upgrade for developers (no need to explicitly set rbf anymore).

petertodd commented at 3:23 am on December 21, 2022: contributor

Updating my NACK with some users of mempoolfullrbf:

Blockstream - Running it on blockstream.info and other Esplora backends: https://github.com/Blockstream/esplora/pull/422/commits/289cc6539497c3f42ab5c591c2369b75d90046e6
Start9 Labs - https://github.com/Start9Labs/bitcoind-wrapper/commit/5696eee846a3dcada826c21f926e728c8319eb3d
mempoolexplorer.com - https://github.com/kylemanna/docker-bitcoind/issues/106#issuecomment-1354482321
nixbitcoin.org - https://github.com/fort-nix/nixbitcoin.org/commit/c2eb4fad9408a15520916dffb4d33ad2ed6843a2
Luxor Tech - mining full-rbf

And of course many individual nodes have chosen to enable mempoolfullrbf, as can easily be seen on social media. So much so that @0xB10C reported on the bitcoin-dev mailing list that their mempoolfullrbf=1 node behind https://fullrbf.mempool.observer was getting full-rbf replacements naturally, without adding a full-rbf peer. This option is clearly more popular than many other mempool config options like datacarrier, which we maintain despite ~0% of the hashing power using it.

BitcoinErrorLog commented at 2:57 pm on December 21, 2022: none

And of course many individual nodes have chosen to enable mempoolfullrbf, as can easily be seen on social media.

Roughly, how many nodes would you say have enabled this feature, and what % of the network is that?

petertodd commented at 9:45 pm on December 21, 2022: contributor

And of course many individual nodes have chosen to enable mempoolfullrbf, as can easily be seen on social media.

Roughly, how many nodes would you say have enabled this feature, and what % of the network is that?

That’s difficult to determine the true number. But we can easily determine a lower bound based on the number of nodes that advertise the FULL_RBF service bit: based on my DNS seed records there are currently 40 IPv4 nodes advertising the FULL_RBF service bit, out of ~5400 reachable IPv4 nodes in total, making 0.74% the lower bound. For IPv6 nodes my DNS seed records show 12 nodes advertising the FULL_RBF service bit, out of ~1100 reachable nodes in total, making 1.1% the lower bound.

As I explained on the bitcoin-dev mailing list it’ll take ~400 IPv4 nodes, with well-distributed IP prefixes, for there to be a 50% chance of a IPv4 node having a full-rbf peer in their 8 outgoing connections.

Note: Bitcoin Core does not advertise the FULL_RBF service bit. Only my full-rbf peering fork and Bitcoin Knots do. So these numbers only represent the minority who have chosen not to run Bitcoin Core, and have chosen to enable mempoolfullrbf. Based on social media posts, the super majority of people running mempoolfullrbf are doing so via Bitcoin Core.

BitcoinErrorLog commented at 11:40 am on December 22, 2022: none

So, basically, only the antagonists in these threads are running it, and the only miners running it are ones lobbied by those same people. Tell me how I am supposed to distinguish this from an attack on Bitcoin users by a minority interest.

I guess the good news is that there really might not be enough incentive for enough people to ever turn this on for it to matter.

BTW, some of us also contacted some of these miners, and their knowledge on the topic was pretty limited and amounted to “but Peter Todd told us to do this.”

The idea that Bitcoin users at large are informed on this topic (or any new feature, really) is wholly absurd.

petertodd commented at 3:12 am on December 23, 2022: contributor

@BitcoinErrorLog

I guess the good news is that there really might not be enough incentive for enough people to ever turn this on for it to matter.

Update: I measured full-rbf adoption among Bitcoin Core v24 nodes and determined that at least 17% are running with mempoolfullrbf=1: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021296.html

BTW, some of us also contacted some of these miners, and their knowledge on the topic was pretty limited and amounted to “but Peter Todd told us to do this.”

Who are “these miners” exactly? Because I suspect you just made up that quote.

i5hi commented at 6:37 pm on December 26, 2022: none

Updating my NACK with some users of mempoolfullrbf:

This just shows that some companies are using it, but nothing about how this is actually beneficial apart from not having to add an rbf flag to transactions from their wallet and still be able to bump. The whole point of having the option was important to many.

Would the lack of this feature prevent any of the above mentioned projects from having a particular use-case?

I’ve also seen many devs, including yourself, publicly ask plebs to add this flag on twitter. Why would you need to do that if the benefits are clear? And now many advocate for it without really understanding why this is beneficial for their node ONLY because they trust your technical judgement.

i5hi commented at 7:03 pm on December 26, 2022: none

I have no business interest in this PR, my concern is that there seems to be a false sense of utility being projected with this upgrade, when it seems like just a convenience upgrade for wallets (no need to use rbf flag anymore) which in the process is breaking utility for several users without adding any real benefit to my node.

It is concerning that certain businesses use 0-conf in dangerous ways, but that’s upto them. We can make the public aware of the dangers of these projects (in true bitcoin spirit) without attacking them with changes in core; Please correct me if I’m wrong about this being an attack on these projects by sharing some benefits that I as a node operator gain from this.

By making it more dangerous so as to disincentivize projects from using it does not really constitute an improvement in security. People will still accept zero-conf, and now the chances of them getting rekt is higher. Protecting users from zero conf can only be achieved through more education on the dangers of zero conf.

vostrnad commented at 7:32 pm on December 26, 2022: none

@i5hi One benefit of using this on your node is that you get a more complete picture of the current fee market, leading to improved fee estimation. Right now this effect is negligible, but as mempools fill and block subsidy diminishes, the difference between a first-seen mempool and a full-RBF mempool could become more significant.

(This assumes you believe the general wisdom that miners are incentivised to replace transactions even if they aren’t opt-in RBF. If, like John, you believe they don’t have this incentive, you should leave the option turned off, as full-RBF replacements will make you overpay on fees.)

BitcoinErrorLog commented at 0:03 am on December 28, 2022: none

@i5hi One benefit of using this on your node is that you get a more complete picture of the current fee market, leading to improved fee estimation. Right now this effect is negligible, but as mempools fill and block subsidy diminishes, the difference between a first-seen mempool and a full-RBF mempool could become more significant.

Do people really believe this hot air? Fee estimation is not meaningfully improved with this feature. If anything, it is less certain as more txns may be suddenly replaced at any given time. Why are mempoolfullrbf proponents so willing to perform mental gymnastics just to have some shred of an argument? Then, you go even further by speculating about conditions that could maybe occur a century from now? Please, be respectful of our time.

(This assumes you believe the general wisdom that miners are incentivised to replace transactions even if they aren’t opt-in RBF. If, like John, you believe they don’t have this incentive, you should leave the option turned off, as full-RBF replacements will make you overpay on fees.)

I never said I do not believe miners have incentive to take incidentally increased fees on misc txns. What I suggested is that miner incentives ultimately align with user incentives over the long term, as they are invested in Bitcoin, in equipment, etc. A more useful Bitcoin makes them more money, more reliably. Lots of users like zero-conf under FSS. Very few users value being unwillingly opted into RBF.

Yours, and many of the mempoolfullrbf arguments have been extremely disingenuous, obtuse, speculative, deceptive, and irrational. I hope cooler heads can see that.

Daniel600 commented at 8:07 am on December 29, 2022: none

There is a way forward here ie adding the swopping rule to FULLRBF by which a replacement trx to the mempool needs to at least include the same outputs as the original trx.

This gives the option to increase fees under full mempool instances but keeps 0-conf status unchanged.

What goal of fullRBF (as is now implemented) is not achieved by First Seen Safe Swopping rule?

petertodd commented at 11:57 pm on January 13, 2023: contributor

@Daniel600

There is a way forward here ie adding the swopping rule to FULLRBF by which a replacement trx to the mempool needs to at least include the same outputs as the original trx.

This gives the option to increase fees under full mempool instances but keeps 0-conf status unchanged.

What goal of fullRBF (as is now implemented) is not achieved by First Seen Safe Swopping rule?

You are incorrect. Full-RBF in it’s full form is necessary for, among other things, preventing DoS attacks on multi-party protocols, as I explained in detail on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html

My FSS proposal from many years ago is insufficient for this and many other reasons, and implementing it is pointless.

Daniel600 commented at 8:15 pm on January 14, 2023: none

Your FSS proposal was specific for Opt in RBF - this is in reference to FULL RBF and would require the swopping logic to be very similar if not identical to your proposal.

This is an edge case risk which has ongoing dispute about it necessity see here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021331.html , even so Optin RBF, FSS Full RBF, and common sense seem to offer enough coverage.

0-conf although may not be liked by some actors in Bitcoin, is engaged with free choice and understanding of the risks. 0-conf is a long standing and significant use case which should not be ignored. 0-conf demise should be viewed as being a major and unnecessary cost to FullRBF as currently implemented.

BitcoinErrorLog commented at 8:58 pm on March 16, 2023: none

Just reviving this. Four months have passed. What are the current stats on people flagging mempoolfullrbf=1?

My guess is that literally only the hostile devs in this thread run it, and whichever miners they managed to persuade personally, and that there is no significant signal of support or usage of the feature in the wild, or am I wrong?

It would be nice for the remaining thousands of users and merchants to not have to look over our shoulder and wonder if Core will sneak it on by default in the future, so can we just merge this PR and call this a lesson learned?

Can we treat this as a failed forced activation? Thanks.

petertodd commented at 10:22 pm on March 16, 2023: contributor

https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf

17% of Bitcoin Core v24.x nodes were running full-rbf and successfully propagating when I measured it, and full-rbf transactions propagate well. Quite a few services are using this flag too, eg BTCPay now activates full-rbf by default: https://github.com/btcpayserver/btcpayserver-docker/pull/736 Both Umbrel and Start9 Labs, among others, have added support for this flag to their node offerings.

Also full-RBF replacements are getting mined quite frequently now due to mempools being full and transactions getting evicted/expired. 😂

Re: usage of full-RBF, as you know for multiparty transactions, the mere existence of full-rbf miners and nodes is sufficient to mitigate low fee double spend attacks: https://petertodd.org/2023/fullrbf-multiparty-protocols These protocols do not need to implement any specific code beyond having full-rbf available. Meanwhile, with mempools being constantly full the consequences of low fee double spends are much worse than usual, with low fee transactions taking days or even longer to get mined. On balance, reliable multi-party Lightning channels and especially coinjoin are certainly more valuable to Bitcoin than the tiny handful of people still trying to make zeroconf a thing.

This pull-req should be closed. With mempools being constantly full it’s quite ridiculous to claim that zeroconf still has value. Indeed, the value of on-chain transactions for person to person/merchant transactions has diminished significantly from a few months ago due to high costs. At this moment mempool.info estimates a $0.60 fee for a standard transaction at low priority; I’m certainly not inclined to spend $0.60 in fees for an on-chain transaction to pay a $15 phone top-up on Bitrefill. A lightning transaction will cost pennies or less, and it’ll be instant.

On March 16, 2023 9:58:16 PM GMT+01:00, John Carvalho @.***> wrote:

Just reviving this. Four months have passed. What are the current stats on people flagging mempoolfullrbf=1?

My guess is that literally only the hostile devs in this thread run it, and whichever miners they managed to persuade personally, and that there is no significant signal of support or usage of the feature in the wild, or am I wrong?

It would be nice for the remaining thousands of users and merchants to not have to look over our shoulder and wonder if Core will sneak it on by default in the future, so can we just merge this PR and call this a lesson learned?

Can we treat this as a failed forced activation? Thanks.

– Reply to this email directly or view it on GitHub: https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1472729383 You are receiving this because you were mentioned.

Message ID: @.***>

nostitos commented at 3:06 am on March 17, 2023: none

I’m certainly not inclined to spend $0.60 in fees for an on-chain transaction to pay a $15 phone top-up on Bitrefill.

Not sure where that’s getting at but my typical “refill” is for 500$ food or uber cards.

ariard commented at 3:24 am on March 17, 2023: member

Just reviving this. Four months have passed. What are the current stats on people flagging mempoolfullrbf=1?

My guess is that literally only the hostile devs in this thread run it, and whichever miners they managed to persuade personally, and that there is no significant signal of support or usage of the feature in the wild, or am I wrong?

It would be nice for the remaining thousands of users and merchants to not have to look over our shoulder and wonder if Core will sneak it on by default in the future, so can we just merge this PR and call this a lesson learned?

Can we treat this as a failed forced activation? Thanks.

On the conceptual discussion, I would say we’re still on the same stage than we were four months ago:

I think 0conf transaction acceptance is still exploitable from using advanced non-RBF tricks like mempool-partitioning [0].
I believe the design philosophy to each use-case its policy regime has not been argued further [1], even if I pointed out it might exposed use-cases to exploitable fee asymmetries [2].
I think the idea of a new p2p extension to monitor conflict has not been really explored further [3].
I think the conciliation of the 0confs use-case with new policy regime like nversion=3 has not been very discussed (e.g I believe 0conf software might have to upgrade themselves to reject future nversion=v3 transactions).

I still hold the belief that replacement by default is long-term the best solution for the Bitcoin ecosystem to satisfy contracting protocols and multi-party applications (coinjoin, lightning channels, dual-funding, splicing) requirements. Though, I still think we should build consensus on the above questions (whatever the direction outcome) before Bitcoin Core removing mempoolfullrbf option or activating by default.

Independenttly of the final outcome on mempoolfullrbf, I still think we should improve Bitcoin Core communication standards in term of mempool policy rules changes (at least when it changes a years-long default) and maybe commit them in bitcoin/doc/policy

[0] https://github.com/jamesob/mempool.work#attack-mempool-partitioning [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html [2] #26438 (comment) [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021142.html

glozow commented at 10:06 am on March 17, 2023: member

Philosophical arguments about full RBF aside, this PR proposes deleting an option that is (1) used by a significant amount of nodes and (2) does no harm to the node operator. It would be inappropriate to simply take such an option out from underneath users/downstream software without very strong rationale and a proper deprecation cycle.

Daniel600 commented at 10:15 am on March 17, 2023: none

GAP600 stats update - GAP600 enables 0-conf acceptance

circa 500k unique BTC Trx hashes in Jan 2023
circa 460k unique BTC Trx hashes in Feb 2023

There is still a significant use case for 0-conf acceptance - primarily by payment processors (servicing industries like gaming) and non-custodial liquidity providers serving non-custodial wallets. GAP600 has not seen as of yet an impact of FULLRBF on activity and risk.

FullRBF approach is a significant change to the behavior of the protocol, and runs the risk of pushing this trx activity away from BTC. FullRBF necessity is not clear and is debatable, the cost is clear.

Keep in mind OptinRBF is very available option for ecosystem actors. FullRBF does come across as attempt to manage the market for perceived benefits, while inflicting a significant cost.

FullRBF with an FSS rule appears to mitigate most of the risks, but keep intact an ongoing use case.

Daniel600 commented at 10:18 am on March 17, 2023: none

Philosophical arguments about full RBF aside, this PR proposes deleting an option that is (1) used by a significant amount of nodes and (2) does no harm to the node operator. It would be inappropriate to simply take such an option out from underneath users/downstream software without very strong rationale and a proper deprecation cycle.

Isnt that an argument for not disabling 0-conf

BitcoinErrorLog commented at 11:41 am on March 17, 2023: none

Philosophical arguments about full RBF aside, this PR proposes deleting an option that is (1) used by a significant amount of nodes and (2) does no harm to the node operator. It would be inappropriate to simply take such an option out from underneath users/downstream software without very strong rationale and a proper deprecation cycle.

Where were you when this was happening to first-seen 0conf users? Where was the very strong rationale and proper deprecation cycle then?

Separately, what is “significant” and “harm” here is both subjective and of quantity lesser than stats provided to the contrary within this thread and the email list about 0conf first-seen usage.

ajtowns commented at 12:44 pm on March 17, 2023: contributor

this PR proposes deleting an option that .. (2) does no harm to the node operator.

This isn’t true. Running a non-default mempool makes it easier to put different txs in your mempool compared to the majority of the network, which:

makes it easier to fingerprint your node and its network peers
creates pinning vectors
can allow your counterparties to hide unconfirmed payments to you or hide double-spends of payments to you
lowers the effectiveness of compact block relay

A node operator may well decide that they aren’t concerned about any of those drawbacks, or that the benefits outweigh the harm/risks, of course, but it’s not true that there is no harm.

Looking through fullrbf.mempool.observer’s data, the first page currently has 23 “replaced” txs mined, compared to 3 replacement txs (one of which was itself replaced). Of the three “replacements” that were mined, two of them replaced txs that were only in the fork.observer mempool for 2 or 3 seconds, and never made it to my mempool. The other tx (0ac289b3058bc6a09e071e91496361b2562e792fe878802142ce81c3a60386af) replaced its predecessor 18 minutes after the predecessor was first broadcast upping the feerate from 4.58sat/vb to 24.05sat/vb, but only improved its confirmation time by ~10 minutes. The vast majority of “fullrbf” txs on pages 1-9 that have been mined are ones that were replaced after expiring from the default mempool, so did not take advantage of the fullrbf logic at all. Of the remainder, almost all seem to be opentimestamps transactions mined by Luxor.

There’s also been a lot of stale blocks recently, with fork.observer reporting two in the last couple of days (780979 and 780994) and nine in total over the last 5 months (since October when this was available in rcs). That’s a lot compared to the previous 5 months in which there were zero stale blocks (21 May to 21 Oct), but it may just be seasonal, as the 7 months prior to that had 12 stale blocks (21 Oct 2021 to 20 May 2022).

petertodd commented at 5:21 am on March 25, 2023: contributor

@ajtowns

this PR proposes deleting an option that .. (2) does no harm to the node operator.

This isn’t true. Running a non-default mempool makes it easier to put different txs in your mempool compared to the majority of the network, which:
* makes it easier to fingerprint your node and its network peers

How specifically does turning on full-rbf enable that attack?

* creates pinning vectors

Can you explain what exactly you mean by this in the context of full-rbf?

* can allow your counterparties to hide unconfirmed payments to you

Why is the deliberate hiding of unconfirmed payments to you even a problem?

or hide double-spends of payments to you

How does turning on full-rbf make it easier to hide double-spends of payments to you? Note that BTCPay now turns full-rbf on by default in their docker image, specifically because it makes it marginally more likely for you to notice a double-spend.

* lowers the effectiveness of compact block relay

You seem to be arguing two contradictory things: full-rbf isn’t used, and yet it also materially lowers the effectiveness of compact block relay.

A node operator may well decide that they aren’t concerned about any of those drawbacks, or that the benefits outweigh the harm/risks, of course, but it’s not true that there is no harm.

Looking through fullrbf.mempool.observer’s data, the first page currently has 23 “replaced” txs mined, compared to 3 replacement txs (one of which was itself replaced). Of the three “replacements” that were mined, two of them replaced txs that were only in the fork.observer mempool for 2 or 3 seconds, and never made it to my mempool. The other tx (0ac289b3058bc6a09e071e91496361b2562e792fe878802142ce81c3a60386af) replaced its predecessor 18 minutes after the predecessor was first broadcast upping the feerate from 4.58sat/vb to 24.05sat/vb, but only improved its confirmation time by ~10 minutes.

Note that fullrbf.mempool.observer has not been working for at least the past two weeks.

The vast majority of “fullrbf” txs on pages 1-9 that have been mined are ones that were replaced after expiring from the default mempool, so did not take advantage of the fullrbf logic at all. Of the remainder, almost all seem to be opentimestamps transactions mined by Luxor.

Can you give examples of these transactions that you claim were expired? By expiring, to be clear, you mean expiring due to the expiration time being reached? Because that would be a transaction previously broadcast two weeks prior, and I’m not aware of any such examples.

There’s also been a lot of stale blocks recently, with fork.observer reporting two in the last couple of days (780979 and 780994) and nine in total over the last 5 months (since October when this was available in rcs). That’s a lot compared to the previous 5 months in which there were zero stale blocks (21 May to 21 Oct), but it may just be seasonal, as the 7 months prior to that had 12 stale blocks (21 Oct 2021 to 20 May 2022). @1440000bytes’s plot of stale blocks doesn’t show any clear link to anything.

Anyway the data from miningpool.observer/template-and-block shows that blocks routinely include a dozen or so unexpected transactions. It’s not clear if those are transactions not in miningpool.observer’s mempoo, and thus relevant to compact blocksl; @0xB10C, can you clarify this point?

petertodd commented at 5:53 am on March 25, 2023: contributor

@ariard

I think the conciliation of the 0confs use-case with new policy regime like nversion=3 has not been very discussed (e.g I believe 0conf software might have to upgrade themselves to reject future nversion=v3 transactions).

To be clear, 0conf users have to “upgrade” every single time mempool policies/conditions change for any non-trivial amount of hashing power. Pretty much any mempool policy change can be exploited to double-spend unconfirmed transactions. That’s why the only entities with any hope of relying on them are large, centralized, transaction processors with significant engineering resources. The nVersion=3 proposal is not special in this regard.

I’m not aware of any “end-user” wallet that even bothers to make it clear to users if BIP-125 RBF is enabled. It’d just give a false sense of security.

0xB10C commented at 9:44 am on March 30, 2023: contributor

Anyway the data from miningpool.observer/template-and-block shows that blocks routinely include a dozen or so unexpected transactions. It’s not clear if those are transactions not in miningpool.observer’s mempoo, and thus relevant to compact blocksl; @0xB10C, can you clarify this point?

Transactions listed under “Extra Transactions” are transactions that weren’t in my mempool but the pool knew about. These are transactions my node would have to learn about with either (prefilledtxn in HeaderAndShortIDs) or request (getblocktxn) when learning about new compact block.

https://fullrbf.mempool.observer is back up (there were only a few requests per day and I needed the a node to run a different branch for a few days). Fwiw there’s also https://fullrbf.mempool.observer/no_opreturn/ listing no OP_RETURN and thus no opentimestamps replacements. Also happy to provide ‘historical’ data on the transaction replacements for this fullrbf node (i.e. this txhex was replaced by this other txhex).

petertodd commented at 1:39 pm on April 6, 2023: contributor

Anyway the data from miningpool.observer/template-and-block shows that blocks routinely include a dozen or so unexpected transactions. It’s not clear if those are transactions not in miningpool.observer’s mempoo, and thus relevant to compact blocksl; @0xB10C, can you clarify this point?

Transactions listed under “Extra Transactions” are transactions that weren’t in my mempool but the pool knew about. These are transactions my node would have to learn about with either (prefilledtxn in HeaderAndShortIDs) or request (getblocktxn) when learning about new compact block.

Right, so I’d be correct in saying that based on blocks from all mining pools generally containing about a dozen Extra Transactions on your miningpool.observer site, blocks generally contain about a dozen transactions not previously broadcast that compact blocks can’t accellerate.

Thus, full-rbf usage has absolutely nothing to do with propagation, as far more transactions get missed by compact blocks anyway.

https://fullrbf.mempool.observer is back up (there were only a few requests per day and I needed the a node to run a different branch for a few days). Fwiw there’s also https://fullrbf.mempool.observer/no_opreturn/ listing no OP_RETURN and thus no opentimestamps replacements. Also happy to provide ‘historical’ data on the transaction replacements for this fullrbf node (i.e. this txhex was replaced by this other txhex).

Thanks.

It looks like https://fullrbf.mempool.observer is missing significant #’s of full-rbf replacements. All the recent ones on https://alice.btc.calendar.opentimestamps.org are not showing up. You may have a propagation issue - I would suggest running the full-rbf peering patch if you are not already: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0.1

ajtowns commented at 4:51 am on April 7, 2023: contributor

Right, so I’d be correct in saying that based on blocks from all mining pools generally containing about a dozen Extra Transactions on your miningpool.observer site, blocks generally contain about a dozen transactions not previously broadcast that compact blocks can’t accellerate.

No, you wouldn’t. Of the last 460 blocks, 375 (81%) required no additional txs, and an additional 67 (14%) required only one or two additional transactions. All of the 8 Luxor pool blocks in that set required between one and three extra transactions.

Most of the “extra” transactions miningpool.observer reports are just ones that its template dropped because they were at the bottom of the block, and were pushed out because of high fee rate transactions that are marked as “young”.

That said, a couple of extra transactions make negligible difference as far as I’ve observed. I see 393 instances (86%) where the block was reconstructed within the same second with between 0 and 10 txs requested, and 59 instances (12%) where block reconstruction happened in the following second (I don’t have sub-second precision in my logs) with between 0 and 325 txs requested. An additional 5 blocks took between 2 and 4 seconds before the block was reassembled, with between 3 and 3528 txs requested, and a single outlier block, 784173, that took 37 seconds to be reconstructed with 109 txs requested, because the peer my node requested the txs from was slow to respond.

Thus, full-rbf usage has absolutely nothing to do with propagation, as far more transactions get missed by compact blocks anyway.

Fullrbf transactions currently have near zero relay impact because they currently have near zero usage, there’s no additional explanation necessary.

petertodd commented at 3:24 pm on June 2, 2023: contributor

FYI it appears that in addition to Luxor, AntPool and possibly one or two other pools are mining full-rbf replacements now with at least some of their hashing power. Wasabi also recently had a double-spend that would have been resolved with full-rbf, exactly as I and others have been arguing. Binance also appears to be doing full-rbf replacements to bump-fees on their consolidation transactions. And finally, myNode has enabled this flag by default.

Obviously, mempoolfullrbf is getting a lot of usage. Removing it would be clearly taking away a useful feature used by many.

ariard commented at 1:46 am on June 5, 2023: member

To be clear, 0conf users have to “upgrade” every single time mempool policies/conditions change for any non-trivial amount of hashing power. Pretty much any mempool policy change can be exploited to double-spend unconfirmed transactions. That’s why the only entities with any hope of relying on them are large, centralized, transaction processors with significant engineering resources. The nVersion=3 proposal is not special in this regard.

Not all the mempool policies/condition changes are equal in term of practicality of exploitation. The question is more if in the future policy change like nVersion=3 should be announced as they might have disruptive effects on end-users and second-layers, hard to foresee from Bitcoin Core usual set of contributors. See has been discussed in the past on the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019421.html

Obviously, mempoolfullrbf is getting a lot of usage. Removing it would be clearly taking away a useful feature used by many.

To satisfy the needs of 0confs users (which encompass 0confs LN channels), a mempool monitoring protocol could be deployed, where nodes are relaying to each other replacements and clients are subscribing to UTXOs of interest. A transaction-relay network over Nostr as presented here could be a good fit: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html

petertodd commented at 1:47 pm on June 5, 2023: contributor

On Sun, Jun 04, 2023 at 06:47:08PM -0700, Antoine Riard wrote:

To be clear, 0conf users have to “upgrade” every single time mempool policies/conditions change for any non-trivial amount of hashing power. Pretty much any mempool policy change can be exploited to double-spend unconfirmed transactions. That’s why the only entities with any hope of relying on them are large, centralized, transaction processors with significant engineering resources. The nVersion=3 proposal is not special in this regard.

Not all the mempool policies/condition changes are equal in term of practicality of exploitation. The question is more if in the future policy change like nVersion=3 should be announced as they might have disruptive effects on end-users and second-layers, hard to foresee from Bitcoin Core usual set of contributors. See has been discussed in the past on the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019421.html

You are incorrect and need to think about this issue more. Essentially all mempool policy changes can be used to double spend unconfirmed transactions, even the dynamic min-relay-fee. It’s extremely easy.

You create two conflicting transactions, tx1 and tx2, such that tx1 is accepted by some % of miners and nodes but not your target, and tx2 is accepted by your target. You broadcast tx1 first, and then broadcast tx2. You win if tx1 happens to be mined first.

Even the dynamic min-relay-feerate can be exploited in this fashion. Broadcast tx1 with a very low fee, such that most nodes do not accept it. Your target is unlikely to know tx1 existed. Next broadcast tx2. Finally use CPFP to bump the fee of tx1 sufficiently that tx1 is preferable to mine over tx2. You can also use full-rbf to double-spend tx1 with a higher fee than tx2: plenty of hashing power is running full-rbf, and you can also take advantage of increases in the limit kicking tx1 out.

I’ve heard claims that many miners are using unusually large mempools, which would make this attack particularly feasible. Of course, the precise dynamic min-relay-fee varies from node to node, so simply picking a feerate close to the limit of most nodes would work well too.

Obviously, mempoolfullrbf is getting a lot of usage. Removing it would be clearly taking away a useful feature used by many.

To satisfy the needs of 0confs users (which encompass 0confs LN channels), a mempool monitoring protocol could be deployed, where nodes are relaying to each other replacements and clients are subscribing to UTXOs of interest. A transaction-relay network over Nostr as presented here could be a good fit: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021700.html

All uses of 0conf LN channels that I’m aware of in the wild are not relying on unconfirmed transactions being secure. That of course would be nuts. They’re simply relying on the fact that the initiator of the channel has all the private keys and does not need to worry about the user double-spending them (eg Phoenix’s use of 0conf LN channels for onboarding users). Do you have a counter example?

Re: mempool monitoring, mempoolfullrbf=1 is an example of such a scheme, as it increases the chance of learning about an economic double-spend. This is precisely why BTCPay enables mempoolfullrbf=1 by default: https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1- You are in fact arguing that mempoolfullrbf=1 should be the default.

The constant attempts to shoehorn random stuff into nostr is hilarious. nostr is a highly centralized system revolving around a handful of nodes; nostr has no mechanism to decentralize note distribution. You might as well just create a centralized transaction monitoring service, such as mempool.space

ariard commented at 11:35 pm on June 5, 2023: member

Note for the clarity, I think effectively both a loosening (e.g nVersion=3 where TX_MAX_STANDARD_VERSION allows nVersion=3 transaction propagation) and a tightening (e.g some nSequence field usage being banned from propagation) can be used to commit a double-spend.

With a loosening, if the victim full-node is not upgraded, they won’t accept your new nVersion=3 transactions, and you can feed the rest of the upgraded network with your nVersion=3 double-spend.

With a tightening, if the victim full-node is upgraded, they won’t accept your abusive nSequence transaction, and you can feed the rest of the non-upgraded network with your abusive nSequence transaction.

So it sounds to me we’re in sync, my observation was about the attacker cost of committing a double-spend, that can be slightly tweaked by the type of policy changes. For e.g, if we allow segwit v3 spends (a policy loosening), where the size of spends is smaller than other spends, the satoshi cost (whatever the sat/vb) of committing a double-spend is lower. This what I meant by saying “not all the mempool policies change are equal in term of practicality of exploitation”.

All uses of 0conf LN channels that I’m aware of in the wild are not relying on unconfirmed transactions being secure. That of course would be nuts. They’re simply relying on the fact that the initiator of the channel has all the private keys and does not need to worry about the user double-spending them (eg Phoenix’s use of 0conf LN channels for onboarding users). Do you have a counter example?

This assumption is correct as long as the initiator of the channel has all the private keys. This is not true anymore with dual-funding or splicing, where inputs can be contributed by 2 or more Lightning nodes. And iirc the BOLT spec, you can combine dual-funding with option_zeroconf. This type of deployement can be advantageous from a user safety viewpoint as you don’t have to trust the LSP with your pre-paid payment in exchange of an instant inbound channel. Now, of course you have mempool issues, so it sounds more a trade-off in term of security model?

Re: mempool monitoring, mempoolfullrbf=1 is an example of such a scheme, as it increases the chance of learning about an economic double-spend. This is precisely why BTCPay enables mempoolfullrbf=1 by default: https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1- You are in fact arguing that mempoolfullrbf=1 should be the default.

I still think the conceptual points raised in my above post would be better to be addressed before to turn mempoolfullrbf=1 by default. Note, I think turning mempoolfullrbf=1 increases the change to learn about an economic double-spend (e.g a LN node double-spending a dual-funding because the liquidity market conditions have changed), however a protocol relaying all the conflicts would be even better as you might have multiple counterparties in a collaborative transaction, and you might want to know all who have done so for application-specific reputation system.

The constant attempts to shoehorn random stuff into nostr is hilarious. nostr is a highly centralized system revolving around a handful of nodes; nostr has no mechanism to decentralize note distribution. You might as well just create a centralized transaction monitoring service, such as mempool.space

The thing is Nostr is so young an architecture than it can becomes anything as of today, even a Ethereum unicorn if it wants :)

On the contrary, I think Nostr offers very different decentralization trade-off than base-layer transaction-relay network, where end-users can pay to have their notes reliably delivered to subscribing clients. If such delivery mechanism takes the form of e.g LN onion routing you might have even more privacy-preserving transaction broadcast than current mechanism. The payment ensures a native DoS prevention mechanism, an issue we had with more privacy-preserving transaction broadcast on the base-layer like dandelion.

From a second-layer perspective, redundancy and privacy of transaction broadcast matters as much as decentralization of the transaction-relay network itself.

ajtowns commented at 1:31 am on June 6, 2023: contributor

Note for the clarity, I think effectively both a loosening (e.g nVersion=3 where TX_MAX_STANDARD_VERSION allows nVersion=3 transaction propagation) and a tightening (e.g some nSequence field usage being banned from propagation) can be used to commit a double-spend.

Any mempool acceptance policy difference between two nodes can be used to prevent your node from seeing transactions the other node accepts. If you outright reject tx A, then spending an output from that tx will suffice. If you accept tx A but the other node outright rejects tx A, then the attacker can construct “X spends A,B (high fee rate)”, “Y spends B (low fee rate)”, “Z spends Y (high fee rate, but not sufficient to rbf X)” and hide Z from you.

If you only have different replacement policies, where you’ll accept “A replaces B” but the other node rejects “A replaces B” then it depends on the details – if you don’t have package relay, then having C spend A will cause you to reject C, eg.

The conclusion that should be drawn from that is that we should be trying to maintain consistent policies throughout the network, whatever those policies happen to be.

petertodd commented at 2:08 pm on June 6, 2023: contributor

On June 6, 2023 1:36:09 AM GMT+02:00, Antoine Riard @.***> wrote:

Note for the clarity, I think effectively both a loosening (e.g nVersion=3 where TX_MAX_STANDARD_VERSION allows nVersion=3 transaction propagation) and a tightening (e.g some nSequence field usage being banned from propagation) can be used to commit a double-spend.

With a loosening, if the victim full-node is not upgraded, they won’t accept your new nVersion=3 transactions, and you can feed the rest of the upgraded network with your nVersion=3 double-spend.

With a tightening, if the victim full-node is upgraded, they won’t accept your abusive nSequence transaction, and you can feed the rest of the non-upgraded network with your abusive nSequence transaction.

So it sounds to me we’re in sync

Agreed.

, my observation was about the attacker cost of committing a double-spend, that can be slightly tweaked by the type of policy changes. For e.g, if we allow segwit v3 spends (a policy loosening), where the size of spends is smaller than other spends, the satoshi cost (whatever the sat/vb) of committing a double-spend is lower. This what I meant by saying “not all the mempool policies change are equal in term of practicality of exploitation”.

For any practical use of on-chain Bitcoin the cost of fees has to be a small % of the economic value of the transaction. Thus only in really pathological cases will differences in feerates for double spend transactions be relevant.

All uses of 0conf LN channels that I’m aware of in the wild are not relying on unconfirmed transactions being secure. That of course would be nuts. They’re simply relying on the fact that the initiator of the channel has all the private keys and does not need to worry about the user double-spending them (eg Phoenix’s use of 0conf LN channels for onboarding users). Do you have a counter example?

This assumption is correct as long as the initiator of the channel has all the private keys. This is not true anymore with dual-funding or splicing, where inputs can be contributed by 2 or more Lightning nodes. And iirc the BOLT spec, you can combine dual-funding with option_zeroconf. This type of deployement can be advantageous from a user safety viewpoint as you don’t have to trust the LSP with your pre-paid payment in exchange of an instant inbound channel. Now, of course you have mempool issues, so it sounds more a trade-off in term of security model?

As I said, “all uses of 0conf LN channels in the wild”

Do you have an example of a deployed service that is actually vulnerable to this? Or are you only discussing hypothetical services that could be deployed in the future?

I still think the conceptual points raised in my above post would be better to be addressed before to turn mempoolfullrbf=1 by default. Note, I think turning mempoolfullrbf=1 increases the change to learn about an economic double-spend (e.g a LN node double-spending a dual-funding because the liquidity market conditions have changed), however a protocol relaying all the conflicts would be even better as you might have multiple counterparties in a collaborative transaction, and you might want to know all who have done so for application-specific reputation system.

What you are proposing is the creation of new 0conf infrastructure for new applications. Let’s be clear: are you proposing that we encourage more services to adopt 0conf reliance?

Given that a significant % of hashing power is mining full-rbf right now, and the many unavoidable exploits I’ve mentioned, this is reckless.

The constant attempts to shoehorn random stuff into nostr is hilarious. nostr is a highly centralized system revolving around a handful of nodes; nostr has no mechanism to decentralize note distribution. You might as well just create a centralized transaction monitoring service, such as mempool.space

The thing is Nostr is so young an architecture than it can becomes anything as of today, even a Ethereum unicorn if it wants :)

I’m talking about nostr at present. If you want to discuss future hypothetical proposals, you should not confuse them by using the name of existing services with concrete architectures.

On the contrary, I think Nostr offers very different decentralization trade-off than base-layer transaction-relay network, where end-users can pay to have their notes reliably delivered to subscribing clients.

Nostr is trust based by virtue of having no built in mechanism for clients to learn that a relay is censoring them. Nostr could have implemented a blockchain. But did not. A future service could of course fix this; it may or may not be called nostr.

If such delivery mechanism takes the form of e.g LN onion routing you might have even more privacy-preserving transaction broadcast than current mechanism. The payment ensures a native DoS prevention mechanism, an issue we had with more privacy-preserving transaction broadcast on the base-layer like dandelion.

What you are talking about has no relevance to double spend detection. That requires a broad effort to learn about all possible transactions. Not a specific one that the initiator wants you to know about.

From a second-layer perspective, redundancy and privacy of transaction broadcast matters as much as decentralization of the transaction-relay network itself.

Again, you are getting off topic here. That discussion has nothing to do with mempoolfullrbf.

petertodd commented at 2:08 pm on June 6, 2023: contributor

On June 6, 2023 3:32:01 AM GMT+02:00, Anthony Towns @.***> wrote:

Note for the clarity, I think effectively both a loosening (e.g nVersion=3 where TX_MAX_STANDARD_VERSION allows nVersion=3 transaction propagation) and a tightening (e.g some nSequence field usage being banned from propagation) can be used to commit a double-spend.

Any mempool acceptance policy difference between two nodes can be used to prevent your node from seeing transactions the other node accepts. If you outright reject tx A, then spending an output from that tx will suffice. If you accept tx A but the other node outright rejects tx A, then the attacker can construct “X spends A,B (high fee rate)”, “Y spends B (low fee rate)”, “Z spends Y (high fee rate, but not sufficient to rbf X)” and hide Z from you.

If you only have different replacement policies, where you’ll accept “A replaces B” but the other node rejects “A replaces B” then it depends on the details – if you don’t have package relay, then having C spend A will cause you to reject C, eg.

The conclusion that should be drawn from that is that we should be trying to maintain consistent policies throughout the network, whatever those policies happen to be.

That conclusion only holds from the argument above if you believe we should actively attempt to make 0conf reliable.

Are you arguing that we should prioritize the reliability of 0conf transactions against double spending attempts?

ekzyis commented at 10:55 am on July 30, 2023: none

@BitcoinErrorLog I am wondering how this change which takes away an option from node operators is compatible with the slogan “Digital freedom starts with you” on https://synonym.to/ which seems to be a company you are the CEO of?

Is this change not infringing the digital freedom of node operators by making it harder to enable full-RBF on their nodes?

DrahtBot added the label Needs rebase on Aug 3, 2023

DrahtBot commented at 5:23 pm on August 3, 2023: contributor

🐙 This pull request conflicts with the target branch and needs rebase.

DrahtBot commented at 9:06 am on August 8, 2023: contributor

There hasn’t been much activity lately and the patch still needs rebase. What is the status here?

Is it still relevant? ➡️ Please solve the conflicts to make it ready for review and to ensure the CI passes.
Is it no longer relevant? ➡️ Please close.
Did the author lose interest or time to work on this? ➡️ Please close it and mark it ‘Up for grabs’ with the label, so that it can be picked up in the future.

BitcoinErrorLog commented at 10:20 am on August 8, 2023: none

I have not lost interest I simply do not have the technical expertise to maintain this (I’m not a dev, a Core dev helped me submit this), nor the patience to respond to newer gaslighting comments that were already addressed in earlier conversation.

My prediction that this feature would later be used to sneak in an “on” by default is already true too…

Not sure how all of you can be so comfortable with this kind of distortion of status quo, particularly when it serves no one but Peter Todd, some misguided wannabe Core Wizards, and whichever miners Peter can persuade to run code they dont really care about anyway.

Either remove all the policy bullshit, or recognize that status quo is only getting worse, and less useful, the more devs get involved with tweaking it.

petertodd commented at 11:10 am on August 8, 2023: contributor

Not sure how all of you can be so comfortable with this kind of distortion of status quo, particularly when it serves no one but Peter Todd, some misguided wannabe Core Wizards, and whichever miners Peter can persuade to run code they dont really care about anyway.

FYI excluding Luxor, I haven’t had any significant communications with any mining pools. I of course attempted to contact every mining pool I could find contact details for. But other than two I didn’t get any responses back, and those responses was just generic “We’ll forward your message to our engineering staff” type responses.

Any “persuasion” appears to have happened purely through my blog posts and talks, and the fact that full-rbf is useful and has no significant downsides. For example, people have noticed Binance using full-rbf to fee-bump their consolidation transactions on occasion; Binance Pool seems to have been one of the earlier pools to turn on full-rbf.

ajtowns commented at 0:49 am on August 9, 2023: contributor

I have not lost interest I simply do not have the technical expertise to maintain this

Closing and marking as up for grabs.

ajtowns closed this on Aug 9, 2023

ajtowns added the label Up for grabs on Aug 9, 2023

DrahtBot removed the label Up for grabs on Sep 3, 2023

bitcoin locked this on Sep 3, 2023

DrahtBot removed the label Needs rebase on Sep 4, 2023

Remove -mempoolfullrbf option #26525

Reviews

Conflicts