Remove -mempoolfullrbf option #26525
Conversation
Reverts PR 25353.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
|
NACK. We've been over this already too many times.
Steering policy is exactly what this PR does. |
|
NACK |
|
We had copious amounts of debate already, status quo reigns NACK |
|
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. |
|
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. |
|
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. i agree with john that it’s worth reconsidering this. |
Gaslight. The current state of the Bitcoin network uses first-seen. I am arguing to keep that state intact. |
Your definition of status quo has not been adopted by users yet. They have not been heard or fairly considered. |
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. |
|
Duplicate of #26438 NACK |
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. |
|
NACK Already been through this. |
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. |
|
You are the one gaslighting. Full RBF is not new, and does not disrupt anything. |
|
No need to rehash this discussion. |
|
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. |
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. |
|
NACK |
1 similar comment
|
NACK |
|
ACK |
|
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:
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. |
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! |
|
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. |
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. |
|
NACK That's one way to stress-test the new ACK tracker. |
|
ACK |
Strange comment, when it's this PR that aims to remove user choice in the name of defending users(deluded merchants). |
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:
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). |
How specifically does turning on full-rbf enable that attack?
Can you explain what exactly you mean by this in the context of full-rbf?
Why is the deliberate hiding of unconfirmed payments to you even a problem?
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.
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.
Note that fullrbf.mempool.observer has not been working for at least the past two weeks.
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.
@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? |
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 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. |
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 ( 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). |
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.
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 |
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.
Fullrbf transactions currently have near zero relay impact because they currently have near zero usage, there's no additional explanation necessary. |
|
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, |
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
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 |
|
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
|
|
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".
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
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 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. |
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. |
|
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.
|
|
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?
|
|
@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? |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
|
There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
|
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. |
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. |
Closing and marking as up for grabs. |
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.