Remove mempoolfullrbf option #26438
Remove mempoolfullrbf option #26438
Conversation
Reverts 25353
|
Concept ACK. Admittedly, I haven't been following this issue very closely, but wow, that mailing list post was very persuasive. The analogy between the
Adding options for different nodes to see different subsets of the transaction universe seems something we would really want to avoid unless the options provide very compelling benefits. And given limitations of EDIT 2022-11-07: After discussion below I still support main idea behind the PR: that adding mempool options which cause different nodes to have different views of transactions could be bad in the long term for transaction propagation and network reliability and complexity of the mempool implementation. So it would be bad to add options that don't have practical individual use cases and let them accumulate over time. But I'd also support postponing this PR, and letting people experiment with the option until we can see whether it gains usage or has any practical effect at all. I just think in the long term, we should streamline options that make the network behave less homogeneously and don't have useful local behavior. |
|
NACK
Zeroconf businesses and projects are vulnerable by design. This can be fixed without changing anything in Bitcoin Core. Full RBF offers 2 benefits:
Its reasonable to try and collect some insights based on usage. This could be used to improve things in future.
I do not understand this question, v3 tx relay is still being discussed afaik and not sure how it's related to an option to use full RBF as Gloria mentioned in this email: "If you don't want your transactions to be subject to And some projects would continue to use nVersion=1 and nVersion=2. Full RBF is already available as an option in Knots and custom bitcoind if someone running core with patches. This option could only make it easier for average users to try it and better insights. |
As discussed in the mailing list thread, the security problem with a coinjoin protocol/multiparty funded transaction protocol that Antoine described can still occur even if fullrbf were the norm. So I believe this to be false (in the sense that I don't think @ariard or @instagibbs, who seem most familiar with the protocol being described, think the problem would be solved with fullrbf -- if I'm misunderstanding that viewpoint though I would welcome being corrected).
"Providing another policy option" is a circular reason. The question I'm trying to get at is: what harm is there to the network from some users choosing to opt their transactions out of RBF? The example Antoine gave would be in that category if fullrbf actually solved the problem he described, but since it doesn't seem to solve the problem I'm looking for other examples.
We have had 7 years to gain insights based on usage. Something like 20-30% of all transactions opt-in already, I think? I don't think we're going to learn anything more that we can't already learn from looking at current usage patterns. Perhaps another way of phrasing this argument is, if you're going to advocate for fullrbf because non-replacement is not incentive compatible, then you should also be able to argue that our fullrbf policy is incentive compatible. And I'm pointing out that fullrbf as it exists in master (when this
If you read my full email and still do not understand my question then I'm not sure I can explain this any better here, but I tried to argue that the restriction on not allowing replacements of non-rbf-signaling transactions is similar in concept to a restriction to not allow arbitrary children of a v3 transaction, in the v3 transaction relay proposal that is being advanced. I like the v3 proposal, and I think we should pursue it, and I worry that setting a precedent of breaking a policy for no network benefit could be used in the future to interfere with v3 down the road, because many of the same arguments would seem to apply. So I'm looking for people who think that (a) the v3 transaction policy proposal is good and (b) that fullrbf is good to explain how those can be mutually compatible viewpoints, because from how I think about both of these issues, I'm unable to justify supporting fullrbf right now (given my understanding of current usage patterns on the network, where there seems to be little demand for transactions that opt-out of replacement under BIP 125 being doublespent) without also justifying offering knobs to break v3 in the future, which I would be opposed to doing. |
|
NACK with longer form here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021136.html
"I want to steal from 0-conf merchants" is the "use-case" you're ignoring, and where the argument falls apart imo. It's the whole reason we're having this debate, it's that merchants are scared about it. If people didn't believe it was incentive compatible, we wouldn't be having this conversation at all. Ostensibly, we are trying to allow people to bid fees for inclusion to blocks. Excluding people from bidding against themselves is clearly different than V3 type patterns which are for making bidding a robust process. edit: and for anyone reading I'm completely against stealing from merchants, and personally will not be working towards fullrbf-default-on efforts because of lack of ethical use-cases. |
One question I have from that post is about:
To me this is sounds like an argument for removing the option, not an argument against removing the option, because if we see miners actually taking the effort to patch their software in this way it gives us a real empirical confirmation that our mempool policy is not incentive-compatible, and that it needs to change. In general, if bitcoin core software is designed around following a single mempool policy, and if we can observe whether or not miners are following that policy, it puts us in a solid position to be able to improve the policy over time, and have a network that is reliable and performant without painful edge cases and usability problems. If different mempools have different policies, it seems like it would be a lot harder to evaluate any one policy or for the network to be reliable and improve over time. |
I don't think we should be encouraging miners to run even more patches to be profitable. That said, I think it's an ok argument for leaving it in as false unless other data comes in. (this is my current stance fwiw) |
I completely agree that the fullrbf policy currently in master is incentive compatible enough to help people steal from 0-conf merchants. The issue with incentive compatibility that I was trying to bring up here is that if you look at our rbf policy as a whole, you'd find problems with its design (namely, the lack of comparison between the ancestor feerate of an incoming transaction, and the actual feerates of all the transactions that would be evicted, can mean that we'd evict transactions that would be mined in the next block in favor of a transaction that may not be mined for a long time). So in that sense, adopting fullrbf is trading one set of incentive compatibility problems for another. It's not like we have a policy A that is so perfectly designed and incentive compatible on the one hand, and this irrational non-replacement policy B on the other hand, and we're just trying to move everyone who is suffering in the backwards B world into the enlightened A world. Instead, A itself has some good things about it, and it has some issues, and B has some good things about it, and some issues of its own. So if you put aside the question of 0-conf and just tried to look at the policies on their face, it's hard to argue that this is a strict improvement over giving people a choice of which policy regime to opt into.
I think this gets at the fundamental issue, which I think we both largely agree on, which is that the main use case of fullrbf is helping users steal from 0-conf merchants. It's not that an opt-in non-replacement policy is fundamentally bad; it's just that businesses offering 0-conf services seem to be offering a reason to subvert the very policy on which they (predominantly) rely.
I just want to make sure that no subtlety in my argument here was overlooked -- I do think that the v3 transaction proposal, as an opt-in set of restrictions on certain transactions to support a particular use case, makes sense. I also think that when applied to the use cases we have in mind, the v3 proposal should make it easier for the best transactions to propagate to miners. I would also argue that a non-replacement policy, when used correctly, can also help miners get the best transactions, if the transaction participants are better able to coordinate when to use CPFP and when not to. The pinning issues with RBF highlight this issue exactly (wouldn't it make sense for wallets to be more willing to spend unconfirmed outputs from non-signaling incoming transactions and just fee bump them appropriately? with rbf transactions, pinning and the greater chance of having your child transaction becoming invalid make this messier). My comparison of v3 to non-replacement transactions is in the use cases that we do not foresee, which might in turn create incentives that could be argued would theoretically make the v3 ruleset not incentive compatible. This is essentially how I see 0-conf merchants' use of non-replacement transactions; they have turned a neutral policy into something that theoretically may not be incentive compatible, by creating an incentive to break it. What I'm arguing though is that we should wait to see evidence that there are actually transactions being broadcast and mined that subvert the policy, and not just postulate that there are reasons for the policy to be subverted and therefore we should move to break it prematurely. This is because there may be countering reasons why the policy isn't being subverted (perhaps because people are mostly honest), and I don't think it's great to break a theoretically useful policy (non-replacement) without a really good reason. In the analogy to v3 transactions, a similar scenario could occur if lots of non-lightning services start using v3 transactions for reasons that (likely) wouldn't make any sense, creating theoretical demand for more child transactions for fee bumping and access to unconfirmed coins. I would hope that we would try to support the v3 use case by just communicating that this is a bad idea and not the intent of the policy, and wait until we were to actually see evidence of transactions being relayed and mined that violate the policy, rather than offer tools to subvert the policy prematurely just because of a theoretical incentive compatibility problem. |
|
I think we're primarily disagreeing on if a knob should exist; I think it's fine and respectful, while picking a "good" default. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. 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. |
|
Reading the reasoning on the mailing post, I think there are more long-term implications in the suggestion of adopting the transaction-relay policy of non-interfering use cases to what the network supposes. Especially the concern we might create mining income asymmetries due to unequal access to transactions flows bypassing policies, in a future where fees should substantially contribute to block reward. Beyond, policy design miner-incentive misalignement could create "hidden" security risks for protocols like Lightning, leading to sudden wreckage (e.g miner-bribing contract to ignore version=3 policy). I think a more complete layout of those implications should be pursued on the mailing list. To be clear, I'm not saying a transaction-relay philosophy "to each use-case, a set of policy rules" AFAIU isn't a reasonable path forward, just we should rather understand better the implications. Answering on the direct questions, as argued multiple times, full-rbf removes one DoS concern for multi-party transactions flows. The solution is satisfying in the sense, if full-rbf is deployed on the majority of the network, a participant to a coinjoin transaction can expect the target transaction, if it offers a better fee in the definition of BIP125 to propagate to the miners. The coinjoin protocol execution doesn't have to halt, and it can keep progressing forward as long as you have fee-bumping reserves available to compete with blockspace demand >
However, reading this statement, I'm not sure if we all think about the same success/failure terms for the security problem raised ? The arguments why the solution is not satisfying are not clear to me. Another more distant concern (yet to be backed up by more research), full-rbf removes a mass mempool-partitioning vector, where an attacker could partition all the network mempools states and from then alter fee-estimation or leverage this as a building block for advanced pinning (cf. the last attack scenario [0]). Of course, partitioning mempools states due to policy difference is always a potential outcome (e.g Taproot transactions between upgraded and non-upgrade nodes), however I wonder what level of difficulty and cost we should burden on an attacker, or consider this as inevitable. On the second question, if we had a stronger model of what we mean by incentive-compatible, rather to evaluate any rule on a binary approach (i.e either compatible or not), we could adopt a quantitative approach. Each policy rule impact could be measured in deviation from an "ideal" mining income (as we're doing in cryptanalysis where we deviate from the perfect security of the one-time pad) and to be pondered with other dimensions like privacy or full-node DoS surface increased. If we had a consistent modeling of miner incentive-compatibility that we'll agree on, we could make legible statement if enforcing BIP125 rules on all transactions or not is a improvement. One could argue today that the non-replacement policy regime as expected by zeroconf operators is "incentive-compatible" in the sense it favors Bitcoin adoption as a payment system, as such increase fees volume (all depends how you construct your model, and what variables you select or not). On the last question, if someone proposes a command line option that breaks v3 transaction relay in the future, I think I would be in favor of such change. I could understand a full-node operator which is not partaking in Lightning neither interested to have compelling fee-estimation, and willing to reduce the CPU DoS surface of a low-performance node. Any transaction-relay rules or mempool acceptance rules, even wisely designed and reviewed, increases the bug surface of a full-node, a risk a node operator could choose to not burden with. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html |
|
Strong NACK By doing this we're setting an extremely bad precedent that zeroconf "breaking" is our responsibility. Zeroconf is antithetical to the trustless, economic incentive driven, design of Bitcoin. It's a dangerous practice that has repeatedly bitten naive users leading to large losses. Any option that changes mempool policy breaks zeroconf if used by miners because any difference in mempool policy can be exploited. |
@petertodd I'm not entirely sure I follow your argument, so I'd appreciate a clarification. I understand that you think two things: (a) zeroconf is antithetical to Bitcoin and should be eliminated, and (b) this PR (or the one that introduced I think I can accept both of those statements as your position, but if they are both true, why would you care strongly whether this PR is merged or not? Why does anyone need the ability to enable fullrbf in the way that |
|
On Wed, Nov 02, 2022 at 06:04:51AM -0700, Suhas Daftuar wrote:
>By doing this we're setting an extremely bad precedent that zeroconf "breaking" is our responsibility. Zeroconf is antithetical to the trustless, economic incentive driven, design of Bitcoin. It's a dangerous practice that has repeatedly bitten naive users leading to large losses.
@petertodd I'm not entirely sure I follow your argument, so I'd appreciate a clarification. I understand that you think two things: (a) zeroconf is antithetical to Bitcoin and should be eliminated, and (b) this PR (or the one that introduced `-mempoolfullrbf`) does not affect the safety of zeroconf in a material way, because it's inherently dangerous.
I think I can accept both of those statements as your position, but if they are both true, why would you care strongly whether this PR is merged or not? Why does anyone need the ability to enable fullrbf in the way that `-mempoolfullrbf` does, if not to improve the ability to steal from zeroconf merchants? I'd like to understand if there's another case for the fullrbf flag that I'm missing.
First of all, people do on occasion send non-opt-in-signalling transactions
that need to be fee-bumped to get mined in a reasonable amount of time.
Similarly, it's perfectly valid to try to cancel a transaction sent in error,
regardless of opt-in status. That alone is more than enough reason to support
full-rbf. The need to signal opt-in status is also of course a privacy harm.
Again, that's enough reason to support full-rbf.
More generally, zeroconf is dangerous. Both to users to mistakenly believe it
to be secure and get defrauded, and all Bitcoin users who are harmed by
attempts to make it secure. What you are doing here with this pull-req is
politics: you're trying to take away an option in an attempt to make it
inconvenient enough for miners and other users that this dangerous feature
continues to live on. And in the process, you're setting precedents that will
harm Bitcoin development by constraining what we can do in the future without
running into yet more nonsense politics from the people trying to continue to
keep zeroconf on life support.
We're lucky that we haven't yet invited legal action from businesses trying to
keep zeroconf a thing. We're much better off killing it while we can, at a time
when it's hardly used.
|
|
I have a question that is making me reconsider my concept ACK for this PR: Do people who support keeping the I might have gotten the misconception from not reading deeply enough that having this option or not having it would basically make no practical difference for the network, because few people would be interested enough to set the option, and unless a large fraction of nodes did set the option, it wouldn't practically affect what transactions ultimately get propagated and confirmed. But maybe this is not the case, and only a few nodes and miners need to set the option for it to have a real, noticeable effect. If this is the case, I'd rescind my ACK, because I do think miners should have freedom to decide what transactions they want to confirm (whatever their reasoning), or even if they shouldn't have that freedom, trying to remove it by deleting a few lines of mempool code would just be a dumb/heavy-handed/ineffective tactic. Following this logic, I'd also support having (I am only thinking here about what policy options it is good for bitcoin core software to support, and don't have an informed opinion about whether full RBF is good policy or not. Suhas's arguments that full RBF behavior is actually complicated and hard to reason about, and that RBF signalling can make usage simpler and mempool optimizations possible make sense to me. But ariard's concerns that RBF signalling could create attack vectors and be unsustainable also ring true. Peter Todd's concerns about zero conf may also be reasonable.) I just think regardless of whether full RBF policy is good or bad, that the |
|
`mempoolfullrbf=1` by itself won't do much for transaction propagation unless a non-trivial fraction of nodes enable it. In conjunction with `addnode` however it does make it much easier for people to opt-in to effective full-rbf relay policy for their own nodes, regardless of what % of nodes choose to run it. For example, a friend of mine told me that he was waiting for v24.0 to be released to run full-rbf, because his node was on Umbrel, and installing a custom patch would be annoying; he was going to peer with another full-rbf node to ensure propagation worked.
As for miners, again, if they _only_ use the `mempoolfullrbf=1` option it's symbolic until a non-trivial percentage of nodes enable it. But again, by using `addnode` to connect to other full-rbf nodes, it will get full-rbf replacements mined even with very little hash power running it.
I and others are currently running a dozen or so nodes that have both full-rbf enabled, and preferential peering via a full-rbf service bit. So finding a node to peer with to get tx propagation to work reliably isn't too hard.
tl;dr: if people choose too, they can use `mempoolfullrbf` to make a genuine difference. If people don't use it, it'll make no difference at all.
…On November 2, 2022 5:02:27 PM GMT+01:00, Ryan Ofsky ***@***.***> wrote:
I have a question that is making me reconsider my concept ACK for this PR: Do people who support keeping the `-mempoolfullrbf` option believe keeping it will have a practical effect on network transaction propagation, and that removing it would be a real change? Or would removing the option basically be symbolic, and not likely to have a significant and observable effect on the behavior of network?
I might have gotten the misconception from not reading deeply enough that having this option or not having it would basically make no practical difference for the network, because few people would be interested enough to set the option, and unless a large fraction of nodes did set the option, it wouldn't practically affect what transactions ultimately get propagated and confirmed. But maybe this is not the case, and only a few nodes and miners need to set the option for it to have a real, noticeable effect. If this is the case, I'd rescind my ACK, because I do think miners should have freedom to decide what transactions they want to confirm (whatever their reasoning), or even if they shouldn't have that freedom, trying to remove it by deleting a few lines of mempool code would just be a dumb/heavy-handed/ineffective tactic.
Following this logic, I'd also support having `-disable_v3_transaction_enforcement` option if we believed enough people might enable that option for it to have a practical effect on the network (good or bad). I don't think bitcoin core should support options that are just symbolic ineffective signaling mechanisms without good use cases. I think if policy options like `-mempoolfullrbf` or `-disable_v3_transaction_enforcement` are added that are mostly intended to affect global network behavior rather than local node behavior, they should only be added on a temporary basis, as ways of providing backwards compatibility, or as ways of experimenting and gathering information so default P2P behavior can be more performant and reliable in the future. I think it would be bad thing to let mempool policy options accumulate over time, because it would make network behavior harder to reason about and create corner cases that make it less reliable.
(I am only thinking here about what policy options it is good for bitcoin core software to support, and don't have an informed opinion about whether full RBF is good policy or not. Suhas's arguments that full RBF behavior is actually complicated and hard to reason about, and that RBF signalling can make usage simpler and mempool optimizations possible make sense to me. But ariard's concerns that RBF signalling could create attack vectors and be unsustainable also ring true. Peter Todd's concerns about zero conf may also be reasonable.)
I just think regardless of whether full RBF policy is good or bad, that the `-mempoolfullrbf` option should have a shelf-life. It does not seem like a good thing in the long term for individual nodes to consciously choose different views of the transaction universe.
--
Reply to this email directly or view it on GitHub:
#26438 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
If we merge this, anyone who wants to use the feature can do I haven't had time to read all the mailinglist discussion. It could make sense to punt this feature, reopen the original PR and merge it later - depending on the outcome of that discussion. Unless there is an urgent reason to have this feature in the current release. Nit: commit message could point to the previous commit instead of the PR (Github will find the PR for you once you click on the commit). |
|
As I said above:
“For example, a friend of mine told me that he was waiting for v24.0 to be released to run full-rbf, because his node was on Umbrel, and installing a custom patch would be annoying; he was going to peer with another full-rbf node to ensure propagation worked.”
The fact is, we're punting on this in response to a tiny handful of people complaining that they wanted zero conf to continue to work. And the effect of taking away options is to just put up barriers to people who quite rationally, think economically rational mempool policy is preferable over trust.
…On November 3, 2022 9:03:38 AM GMT+01:00, Sjors Provoost ***@***.***> wrote:
If we merge this, anyone who wants to use the feature can do `git cherry-pick 3e27e31` and compile. So the cat crawled slightly further out of the bag.
I haven't had time to read all the mailinglist discussion. It could make sense to punt this feature, reopen the original PR and merge it later - depending on the outcome of that discussion. Unless there is an _urgent_ reason to have this feature in the current release.
Nit: commit message could point to the previous commit instead of the PR (Github will find the PR for you once you click on the commit).
--
Reply to this email directly or view it on GitHub:
#26438 (comment)
You are receiving this because you were mentioned.
Message ID: ***@***.***>
|
|
My two cents: IMHO, “full RBF” will be inevitable - without BIP125, an explicit flag in Core, or anyone’s blessings. Once the block subsidy is gone, miners will fight for scraps for survival and do everything they can to get better margins (fees). If Core doesn't explicitly allow full RBF transactions in its mempool, there will be other non-Core mempools or some sort of black market forming. So either we formalize full RBF, which is preferable, or it will arise out-of-band. If you want to give zero-confs businesses some grace period, shipping |
|
@petertodd but is that an urgent need? As you point out in your mailinglist post, your friend could run the v24.0rc3 release candidate binary, in case we drop it from the final release. That said, this wouldn't be safe if there are additional bug fixes in future release candidates, and running release candidates in production is not a good idea in general. The debate around RBF has been going on for almost a decade. I think it can wait a few more months for a point release. We can determine if your bounty program worked out (i.e. created a fait accompli) through something like miningpool.observer. |
|
ACK 4a40866 (update 2022-11-07: merging this still has my preference, but I don't consider this PR release blocking) v24.0 release notes will have to be edited (when this is backported) The term Full RBF is confusing. As @sdaftuar points out in his mailinglist post, It would be even more confusing to have "full rbf" available now and "maximal rbf" later. Maybe it turns out we can't come up with a "maximal RBF" that is meaningfully more incentive compatible than "full rbf", but I think this should be explored a bit more. I also agree with @ajtowns that the general issue of divergent mempool policies is worth thinking through more. Since |
@sdaftuar we have NO insights about usage of full rbf. I remember you suggesting full-rbf a few week backs in IRC. I think @petertodd is right and its just egos and politics else technically its very clear this option will help bitcoin. |
@petertodd Thanks for providing these examples; I think they’re worth consideration and reviewers should decide how compelling they are.
This is either poor phrasing or you have misunderstood my motivation: I have no intent with this PR to keep zeroconf going, and I am not arguing that zeroconf is a good or safe practice for the network. It appears from Antoine’s recent mailing list post that he may also misunderstand me as somehow trying to protect zeroconf merchants or their business practices, so I will try to clarify my views here because that is not my interest at all. Let me start by saying that I think I mostly share your views that zeroconf – ie selling a product in an irrevocable way prior to a transaction having any confirmations – should not be relied upon for anything of material value. It seems to me that engaging in a practice like that is asking for trouble, and as I have thought about this issue in recent weeks it is unfortunate that zeroconf merchants exist, as their existence appears to be a lightning rod that attracts interest to pushing for fullrbf (which I now view as a protocol development mistake, at least at this time). Because I share your view, I’m surprised that zeroconf services appear to still be in operation, and it further makes me wonder if there’s anything that we can do at the protocol level that would affect the existence of those operations. Perhaps the services that exist today only engage in these practices in situations where theft could be detected and deterred via off-chain mechanisms (and hence, it may not be “zeroconf” in the sense I defined it above, if there is recourse in the event the transaction doesn’t confirm). If so, then even if such practices are bad for Bitcoin (which I think is hard to say without looking at concrete examples of merchant behavior), they may not go away in a fullrbf world either. If non-replacement were something that I believed only existed to support zeroconf merchants, I would have stayed out of this debate. However, I realized that what we are actually doing here is taking our opt-in non-replacement policy regime and deciding to get rid of it. And it occurred to me that this is a policy that is independent of zeroconf practices – which are an outside-of-the-protocol merchant behavior, which we may be able to influence but not definitively eliminate – and moreover that non-replacement is actually a useful idea on its face. In fact it’s such a useful idea that I think I’d propose it or something like it in the future, if we were in a fullrbf world with the rbf policies we have today – but not for anything that has to do with zeroconf merchant practices, which seem insecure regardless of whether we have a non-replacement policy. Since I perhaps didn’t explain this thoroughly in my mailing list post, I will expand on it here. The RBF rules we have today are clumsy, and I have personally had countless discussions over the years with other developers about how to improve on them, primarily due to the pinning issues that exist and the incentive compatibility considerations that come with it. On top of that, transaction chains themselves are hard to reason about in the context of coming up with optimal transaction selection for a miner and preventing mempool DoS in various ways (these are also topics I have substantial experience working on for this project). In thinking about all this, one conclusion I’ve reached is that Bitcoin’s transaction relay protocol and user behavior would likely have been far better from the start if the expectation was that the network wouldn’t generally relay transactions with unconfirmed parents – a position that I think is easy to justify if you look at the various anti-DoS rules we’ve put in place over the last 10 years which have generally served to limit the transactions which get relayed on the network, in comparison to what early versions of the software supported. From a blank slate/initial policy of never allowing transactions with unconfirmed parents, relaxing that policy in specific situations to support narrow use cases which can be easily reasoned about would have been much better than the free-for-all we have now (where arbitrary transaction chains topologies are permitted, with the only limits being on certain kinds of package size and count). In such a world, there would be a meaningful difference between transactions that can be replaced via feerate considerations, and transactions that the sender does not intend to replace. In the latter case, CPFP is a far more reasonable strategy than in the former, because the recipient who chains a transaction has greater reason to believe that they are doing something helpful rather than harmful by creating the chained transaction which feebumps the parent (and not just pinning the transaction and irritating the sender, or creating a transaction that will disappear when the parent is replaced and need to be reissued, or creating a DoS vector for the network by relaying something that will need to be evicted later – which is the central issue that creates the pinning consideration in the first place). Now I get that we aren’t starting from a blank slate; I wanted to take everyone through that thought experiment to try to understand that non-replacement is not intrinsically evil. Note that the CPFP use case I describe is completely benign, provided that the wallet engaging in it can reasonably handle the (likely rare, but certainly possible) situations where the first transaction doesn’t confirm for some reason (eg by being able to reissue a payment if needed). Maybe you think improved CPFP policy is not compelling; that is fine and we can debate and perhaps disagree. Or, perhaps the CPFP signal can still be in place on a network where the non-replacement is not enforced; that is hard for me to say without a lot more thought. If you think about the policy regimes we have now or are currently discussing: (1) we have a way to opt-out of RBF (but still have lots of child transactions), (2) we have a way to opt-in to RBF (and still have lots of child transactions), and after the v3 proposal is deployed we will also have (3) a way to be able to opt-in to RBF and have just 1 child transaction (which itself will be limited). In some ways option (2) is the least well-designed option, in that the transaction graph complexities interact with the replacement rules in ways that result in outcomes that are both suboptimal for wallets and also sometimes incentive incompatible for miners, and it would make more sense to have option (2) restrict the child transaction graph further than it does today (but perhaps not so limited as option (3) will be, which is really tailored to a single use-case). If that were a road we go down, then that would make (1) a more compelling option to have available as a policy on the network to facilitate use cases that involve lots of child transactions, and if we eliminate (1) now I fear that any attempt to bring it back in the future will fail due to concerns about zeroconf merchants – something outside our control as protocol developers. And as I said on the mailing list, I also fear that eliminating (1) for the reasons given could also apply to eliminating (3) in the future. If you look at the reasons you gave above for not having (1) as a policy, I think at least two of them easily apply to the v3 transaction proposal – the consequences of users making mistakes and inadvertently using version 3 transactions when they intended to chain multiple children, and the privacy implications of another distinguished transaction type. Now I think we have good answers to those objections – namely that no one should be using v3 transactions unless they mean to – but if your arguments are found to be compelling in this case, I fear that the v3 policy design may be subverted in the future and the efforts we’re putting in now are a waste of time. — Perhaps it would be helpful to reviewers for me to explain what I think some of the best reasons to oppose this PR would be, in the interests of advancing the debate:
|
|
FYI: https://twitter.com/lightcoin/status/1588249269412057088
Not the same person as the friend I mentioned above. |
|
Tentative concept ACK. Am still forming my opinion on this pull relative to #26287, but given the controversial nature of adding the option, the most prudent course may be not to include it for v24, while continuing discussion for future releases. |
Unconfirmed transactions are not spent yet, and no one can tell which are fraudulent. In case of mutually exclusive transaction the mined transaction becomes the valid one, and others still aren't necessarily fraudulent, just invalid. You are trying to justify a moral super authority over consensus rules by drawing in the specter of fraud. |
|
@dr-orlovsky wrote:
No, but they can cause (very brief) chain splits. A compact block that includes This probably isn't an issue at the current high propagation speeds, but it might be in a more censorship heavy world where blocks are relayed the hard way (Tor, satellite). In other words, the concern about mempool policy bifurcation in this case could be addressed by a commitment to changing the default to 1 in the not-too-far future. But such a commitment can't be made. |
|
NACK - Not adding an option to bitcoin core when that option is already deployed in ~1% of the network increases risks of various sorts that arise from node operators patching their source or running forked releases. This is an option that has been proven to be demanded by the community, and it is exactly that community of node runners that defines bitcoin. Core maintainers' job is to follow the will of the community and maintain the software that facilitates that will. If certain businesses desire a bitcoin which is strictly opt-in RBF: that thing does not currently exist, but they are free to create it. |
Given the number of people commenting here who are not familiar with the details of the P2P protocol, you should be making alarmist claims like this. @dr-orlovsky is correct. By your definition every time a block is found there is a "chain split", as not all miners have the block instantaneously. That is not "causing" a chain split. That's just making the inevitable one-block difference in consensus take slightly longer. Miners regularly mine blocks containing transactions not already seen by the rest of the network. Indeed, because the mempool doesn't have consensus, and it's common for conflicting transactions to exist that can't be resolved by fee, this is inevitable. Particularly if someone chooses to broadcast a lot of divergent transactions. What full-rbf does do is reduce the chance of a divergence in a subset of the problem, when one transaction pays a sufficiently higher fee than the other. It also discourages zeroconf attackers from doing that, by simply making zeroconf not a thing. |
This is FUD, not a serious rationale. If block propagation is an issue, miners should think more carefully about what blocks they mine. Reduce the size [limit?] if necessary. |
|
From the original mailinglist post "On mempool policy consistency":
What I said follows directly from this.
When there's two different policies, the rational thing might be to exclude bumped transactions that don't signal RBF, as well as the original. The trade-off there is between the increased risk of mining a stale block and the fee revenue lost.
I said:
I'm not going to account for people being alarmed because they're not reading what I'm saying. This is not a safe-space for people who don't like thinking through edge cases :-) |
|
NACK In my amateur opinion we should not hold back bitcoind development to support ill-advised application layer design decisions. Full RBF simplifies mempool policy and aids the development of multiparty contract protocols. These protocols will be essential in spreading adoption and usability of bitcoin. Zero-conf txs are insecure and do nothing to increase bitcoin adoption. It's 2022, if you need instant bitcoin transactions you need to run a lightning node. Furthermore, removing the full RBF flag permits the continued concealment of a consensus-compatible local capability that node runners already have. This strikes me as a deceptive, user-unfriendly dark pattern that should not be permitted in a free and open protocol. This is the kind of behavior I expect from monopolistic software service companies. Bitcoin should do better. |
No, the hyper-rational thing to do is to work out the increase in stale rate per byte of transaction, and ensure that the bump in fees is high enough to be worth the tiny increase in stale rate. The easiest way to accomplish that would be to just increase the minimum mining fee for your node to something that actually makes a difference to revenue. Of course, doing that can make double-spending quite easy... |
As we all know, you can't rely on transaction expiration because anyone else can just rebroadcast the transaction. Indeed, we've seen this happen before! That's why I said it's a convoluted alternative with clearly worse outcomes. Even if it did work, you're suggesting that users wait multiple days at minimum for a chance at getting their transaction mined; two weeks with the current expiration time. No-one has raised any technological reasons why wallets like @greenaddress shouldn't simply use full-rbf. They and other wallets clearly want to offer their users this capability, and the capability has helped users in the past.
When someone proposes what appears to be clearly worse solution, without any technical reasons as to why, it helps the conversation along if we discuss what are the actual reasons for proposing that solution. Now, if you want to protect zeroconf, go ahead and say it. But if you don't, you have not brought to the table any reason why we should put up arbitrary roadblocks in the way of wallets like @greenaddress to use full-rbf. |
|
Green wallet already offers users full rbf. Even our wallet has the setting. Core does not need to be involved. In fact, any wallet could switch to default-rbf-on at specific fee rate ranges or block capacity thresholds, when congestion is detected. It could even warn the user if they turn it off during such times. UX is an app concern. Policy is a user concern. Neutrality is a Core value. Core is not here to anticipate or steer how Bitcoin is used, it is here to be a maximally useful tool while being as simple as possible. Just because code is able to do something does not make it necessary or appropriate at the protocol level. Bitcoin is for users, not academic proof. 0conf is useful in an inverse way to rbf, yet neither can be a guarantee. Both are valid use cases and thankfully both already work fine. |
|
I am not sure at this point which users or use cases are important:
Full RBF can never be stopped, 0 conf is non sense and we can improve full rbf later or make it default. If maintainers are unable to take the basic decision after 30+ NACKs with valid reasons, then maybe I am missing something. Path of least resistance after all the drama : Close this PR and release v24.0 for users that want full rbf (the users who run this software) |
That is necessary, but not sufficient. You don't know if other miners and nodes in between do the same. If they pick the higher fee and you don't, your block propagates more slowly. If you stick to the lower fee and they don't, same problem. If you leave the transaction out entirely you're safer (at an opportunity cost). The choice is between picking the higher fee version, picking the lower fee version and avoiding both. (this sounds completely impractical to implement though) Note that this is not an argument for or against |
This is not a voting system, such is sybilable anyway, and none of the affected users are actually in this forum or understanding the nuances. Core cannot and should not attempt to change Bitcoin or pretend they know what users want, nor what they "should" want. The last thing we need is me or Bitrefill lobbying for 0conf users to come here and "vote" against devs. I prefer the basic argument of: please stop meddling with Bitcoin, we have no way to get proper user input. If you ask users if they want merchants accepting 0conf, they will say yes. If you ask them if they would like the ability to undo/bump a txn they will say yes. If you ask them if it is okay to take away 0conf they will say no. Simple. |
I have been contributing to bitcoin core for sometime, founder of joinstr (coinjoin implementation) that is affected by opt-in rbf, write a blog for privacy (rbf using by setting nSequence < maxint-1 on at least one input affects privacy) , work as dev for an exchange (non-kyc, we don't need opt-in rbf) and proud regular bitcoin core contributor. |
Green wallet does not currently offer full rbf. It supports opt-in rbf. we plan to support full rbf soon with both esplora/blocksteam info as well as green wallet.
With that mentality we wouldn't even have even opt in rbf. However opt in rbf is far from optimal and while better than nothing (and an inherit UX problem) it perpetrates this idea that more infrastructure around unconfirmed transactions could be probabilistically relied upon when it comes to block inclusion which will likely result in systematic risks when inevitably it doesn't. Without fullrbf users are forced to wait potentially indefinitely for transactions to get unstuck when things go wrong with forgetting to set the flag, or likewise they may set it and get denied service potentially for hours or more. I agree this could be slightly improved with better software/mempool state detection/ bip21 flags but it really is a house of cards, potentially a big weakness in Bitcoin waiting to be exploited |
Given I was the proposer of #26323, I think it's pretty absurd to cast me as a protector of zeroconf. My goals are:
All of these things seem fairly straightforwardly desirable to me, even if you take "zeroconf delenda est" as your guiding principle. Of course, one reason to be against any or all of them is if you care more about some competitor to bitcoin: bitcoin handling new use cases is just more competition for you; review missing design problems and bugs is already a PR win and if devs don't even do anything about them that's even better; making surprising changes that stops businesses from using bitcoin is both new potential customers for you, and an opportunity to discourage unrelated people from considering bitcoin; inconsistent mempool policies is a great way to make tx relay even more unreliable; and not being forthright about policy changes is just an opportunity to stir up more drama later.
I've written at length about all of the above both on the list and in various PRs on this topic. |
GitHub is not sybilable. The NACKs are associated with long-standing, real-world, identities. I personally know the people behind the following NACKs, all of which have given clear rationals for their NACK here and elsewhere, including but not limited to: @RCasatta - Blockstream dev with a long history (also contributes to OpenTimestamps) It is not productive to this conversation to imply that the NACKs may be a sybil attack. |
Anyone trying this is ignoring the feedback and depends on a small number of maintainers who should not be able to decide everything including config of mempool or freedom of bitcoin users. This is not sybil attack or brigading but similar to people going against governments in their country. Example: Truckers and Farmers in different countries. Even they were told about rules and regulations. This option exists for users and let them decide. |
|
If you want this to be a voting system, it becomes sybilable, because we need to get actual users in here, not Core devs, etc. It is not a vote afaik, and I doubt you really want it to be either. This conversation is getting noisy, a chore. The author of the work ACK'd its removal. The topic is controversial. The user space could be violated. Etc etc etc. This thread probably should be closed, and the feature removed. Please stop meddling with Bitcoin. Love, All the users that are not Core devs. |
You should secure applications. I won't blame you alone as most of the LN devs live in some fantasy and this is what I got answered for sharing something about turbo channels. I cannot search but there was a dev and it was a spec approved by lot of devs. I was answered " it works on trust" so not vulnerable. Please continue that trust and this was done months back. |
|
I don't think anyone is claiming it's a voting system. As you say, Bitcoin's operation should be up to primarily the users, not the bitcoin core developers. Bitcoin core v23 doesn't facilitate the users' will because it forces users to run patched or forked versions in order to express their will. The proposed v24 with You yourself said that core should be neutral. This PR (removing |
Actually, the miner can't know which transaction other nodes have accepted into their mempool (hypothetically it could even be both, though I don't know if any nodes implement that at present). It's also possible that nodes have rejected both transactions entirely. Therefore, the stale rate must always be considered in all fee considerations, replacement or not. |
|
I think a lot of this general higher level discussion can move elsewhere (e.g. mailing list, IRC). All the information seems to be available to the maintainers at this point. They are ultimately responsible for merging pull requests and signing off on Bitcoin Core releases (that's just the reality). If you feel strongly enough on decision(s) they make there are consensus compatible forks (e.g. Knots) and alternative implementations. By all means hold them accountable and request information on why certain decisions were made after the fact though. As I've said elsewhere I personally will support whatever decision is made on this issue, I think it is a tricky decision for this particular release given the makeup of the comments. I would be very disappointed though if there wasn't full RBF support in either this release or a future release though. The vast majority of comments not only seem to want this but also think supporting the zero conf use case shouldn't be a major consideration. |
I think this PR should not have been created here before some users and devs agreeing on other platforms. |
|
@1440000bytes: I'm happy to discuss this anywhere online you want (within reason). Just not this PR, this repo. Decisions have to be made and we move on. |
|
There is a line in https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#communication-channels: The developer mailing list should be used to discuss complicated or controversial consensus or P2P protocol changes before working on a patch set. I think we can change to any controversial changes and until settled on other platforms |
People change their minds. You're actions right now are consistent with trying to protect continued uses of zeroconf, and indeed, you even say so below:
I find it extremely disrespectful to the wallet authors that have spoken up with clear usecases for full-rbf that you and others continue to say that replacement is solved by opt-in RBF. It obviously is not for the precise reason that opt-in RBF transactions get discriminated against, people have a reasonable desire to send without that bit, and some of the time those transactions get stuck and need fixing. Also, re: the pinning attacks, as we all know full-rbf does in fact eliminate large classes of them, and thus forces attackers to use more expensive attacks that tie up more funds. It also of course eliminates unintentional attacks where transactions are double-spent by accident (eg by people importing seeds into different wallets, something that has happened regularly with Wasabi). Finally, the default-off That there are still some questions around that specific use case does not justify the removal of that widely desired option.
Again, the default-off You can't seriously argue that full-rbf needs to be "fixed" to achieve the goals people want to use it for.
The effect of your actions in NACKing this pull-req are to protect continued use of zeroconf. As is easy to see on Twitter, Reddit, etc. the fact that zeroconf is insecure is widely known. But a small minority of people like @BitcoinErrorLog are trying to argue that it is in fact secure. By pulling this default off option, you are inevitably sending a message that Bitcoin Core is in fact in control of mempool policies that make zeroconf secure. If you wanted to minimize this risk, we'd simply ship with full-rbf enabled, and make the fact that we're doing that very public to eliminate usage of zeroconf as fast as possible. The fact is you are doing the exact opposite, increasing the total exposure to this risk.
This is clearly a case where getting consensus over mempool policies is difficult for political reasons, not technical. And far from providing a worse experience, multiple wallet authors have spoken up with clear use-cases where it provides a better user experience. The obvious thing to do with that kind of political disagreement is provide the option for people to use. With more use, we'll probably be able to resolve this disagreement with actual usage rather than endless theoretical discussions on GitHub.
The fact is Core has lots of knobs to control relay policy, including many knobs controlling things with a much smaller interested audience than full-rbf. Past practice on Bitcoin Core clearly allows people to pick mempool policies. Where is this discussion of knobs going anyway? As you well know, we already ship with settings like the maximum mempool size and min relay fees that, if set, make zeroconf unreliable. Are you planning on removing those settings?
You are clearly interfering with desirable use-cases by taking away this option.
What are you trying to insinuate here?
Surprising? We've been telling people for years that zeroconf is insecure. Full-RBF is not surprising for anyone who isn't in the tiny minority trying to accept it. Are you saying you expect more people to start relying on zeroconf? And that it's a good thing? Because that's how this reads.
Full-RBF nodes are entirely compatible with opt-in-rbf nodes. How specifically does full-rbf make tx relay "even more unreliable"?
We're talking about a default-off option. That is not a policy change. |
|
I’ll start with a summary of how I see the review feedback here. I’d broadly categorize the most common responses expressing support for
There were also circular answers given for why we should offer this as a flag, namely that users of our software demand it (why do they?), or that fullrbf is inevitable (why?), and therefore we must support it eventually. There were also several comments that seemed to indicate clear misconceptions as the justification for why we should have fullrbf, which I’ll gloss over quickly: some thought this PR would eliminate all forms of RBF, or that this PR implies we are trusting miners to not follow their incentives (perhaps worth debating, but not an assumption built into this), or that the only possible utility from a non-replacement signal is if a user trusted that it would be confirmed (or give users a “false sense of security”) – this ignores the points I raised on why non-replacement can be useful, and also ignores evidence that came up indicating that some modern wallets and protocols use non-signaling transactions in certain limited situations (such as for LN funding transactions or coinjoin protocols deployed today). Another user thought that RBF should be opt-out only, and not opt-in, misunderstanding that our RBF policy today can equivalently be thought about as an opt-in or opt-out policy, because every transaction that is authored has to pick, via the choice of sequence values, whether it will be subject to RBF or not. Another commenter mentioned that we should not incentivize the use of unconfirmed transactions. I thoroughly appreciate this comment, because I would be the first to agree that our software would be far simpler, and the network would work much better in many ways, if users were on board with us eliminating relay of transactions that spend unconfirmed outputs – the most visible form of “use of unconfirmed transactions” on the network today. I have avoided proposing this because I believe that Bitcoin users would find this too restricting, but I would welcome others’ efforts to move Bitcoin’s culture in this way if it’s practical for the ecosystem. This would make our RBF policy code much simpler, too, and would eliminate reasons to have a non-replacement policy – unless we then wanted to support some limited transaction chains, which would work much better for transactions that weren’t subject to replacement. Finally, I’ll get to what I think are the best reasons to oppose this PR. I laid some of these out already in an earlier post, but I’ll restate them here more concisely. It seems to me that we have not reached consensus about this PR, so in the interests of not holding up this project with more debate I thought I’d acknowledge what I believe to the best reasons to continue ahead with the First, this PR unfortunately has conflated two separate debates: whether we should be moving towards a fullrbf policy on the network, and regardless of that, whether it’s reasonable to offer this default-off command line option to our users. My view on this is that if fullrbf as our default policy doesn’t make sense, then it also doesn’t make sense for us to offer it as an option, but I know that others might disagree with that logic. I won’t repeat my arguments for why I think encouraging a more homogenous network policy and promoting broad standards for transaction makes sense for users to have a better experience transacting on the network, but I will acknowledge that the existence of debate on this point is a reason that (from a maintainer’s perspective) I’d expect this PR to have a high threshold to clear in order to be merged. Second, I think there are logical reasons to want the network to be fullrbf:
Moreover, the objections I have to the concept of fullrbf on the network are philosophical in nature. I opened this PR to try to discuss the higher level protocol development concerns that come with decisions like this – such as how we evaluate incentive compatibility or meet disparate use cases (but disappointingly, reviewer feedback has largely avoided engaging on these points). And in thinking about the alternative, I don’t expect that offering a default-off flag is going to materially alter the network in the near term, as a practical matter. I do still plan to raise these protocol development concerns in the future, if and when they are applicable again to work happening in this project. So even though I remain unconvinced by the NACKs here, and despite what I see as deplorable behavior by some of the participants, I think it makes sense to close this PR due to lack of consensus, and my recommendation to maintainers would be to move forward with the 24.0 release without reverting #25353. |
Reverts #25353
I've laid out my reasoning for removing this option on the mailing list (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html).
If any reviewers are unconvinced by my rationale, I'd appreciate answers to the questions I laid out at the end of that email:
Does fullrbf offer any benefits other than breaking zeroconf business practices? If so, what are they?
Is it reasonable to enforce BIP 125's rbf rules on all transactions, if those rules themselves are not always incentive compatible?
If someone were to propose a command line option that breaks v3 transaction relay in the future, is there a logical basis for opposing that which is consistent with moving towards fullrbf now?