-permitrbf to false
#7388
Can’t believe that the original pull request got merged just after 3 hours. I’m leaving for work now, so will be gone for 10 hours.
Edit: This PR will result in nodes not relaying and mining RBF transactions by default. If we merge this there will be no policy change from the last stable version which is Bitcoin Core 0.11.2.
Can't believe that the original pull request got merged just after 3 hours. I'm leaving for work now, so will be gone for 10 hours.
utACK.
We will be doing something similar to this (but more thorough) in Classic. It would be nice if a git pull were enough to incorporate it. https://bitcoinclassic.consider.it/revert-opt-in-rbf
ACK
RBF is steal. This PR should be merged asap to prevent potential financial loss.
I’m willing to consider this due to the unexpected controversy this is causing. I do however think this due to a misunderstanding:
And, no, opt-in RBF is not theft. It’s indicating that you’re not sure whether what you’re submitting is the final form of the transaction. This is the exact semantics that nSequence had since the earliest version of Bitcoin.
We have accepted the nSequence based opt-in RBF proposal in #6871. Merchants and wallets should already “listen” for the nSequence INTMAX if they rely on 0 confirmation transactions, otherwise they really should do it now.
It safely re-enables the mempool replacement feature original implemented by Satoshi and disabled by him as a SPAM protection (http://sourceforge.net/p/bitcoin/code/140/).
I don’t think it’s wise to limit Bitcoins potential just because some people are not willing to check if their implementation (wallets/merchants) are opt-in-RBF save.
NACK.
@wangchun It’s only an issue for merchants who accept 0-conf transactions, not wallets (who typically don’t count unconfirmed transactions from the outside as spendable anyway). Several payment processors and analysis services (which aim to make 0-confirmations safer) already treat non-max nSequence as unsafe (and they should, regardless of whether opt-in RBF gets adopted or not).
If anyone feels they need more time to deploy this, or knows of use cases that aren’t mentioned above, I’d very much like to hear this, and reconsider. I will gladly admit we could have done a better job at communicating, but please don’t claim things like “RBF is theft”; this is a well-considered and (according to many) necessary feature.
@jonasschnelli Could you please tell me which wallet has been ready to warn users for potential RBF transactions?
Some wallets might want to add an extra warning if a RBF transaction are among the unconfirmed incoming transactions. That would be possible.
But most (all) wallets do already treat unconfirmed transactions/balance as unconfirmed. People should really not rely on unconfirmed balance. It’s unconfirmed. As recently shown by Peter Todd, it’s quite easy to double spend your transaction, and this was without RBF being deployed. If they rely on 0-conf they should use a merchant tools which includes risk analysis.
If you are selling services or goods after you have received a 0-conf transaction, you should be very careful with handing out the good/service while the transaction is not confirmed and you should certainly not use a standard wallet (you would take a very high risk).
@wangchun I think there was an expectation that interested parties were keeping watch with bitcoin core development, but it seems many were relying on 3rd parties to report on core development for them; and therefore there has been this lapse in communication. @sipa as discussed on IRC:
It’s only an issue for merchants who accept 0-conf transactions, not wallets (who typically don’t count unconfirmed transactions from the outside as spendable anyway)
Isn’t actually true, with mycelium accepting zero conf almost 7 months ago. Another example is breadwallet, and several others.
“Everyone knows 0-conf is perfectly save and rbf will break it” … Not
As recently shown by Peter Todd, it’s quite easy to double spend your transaction, and this was without RBF being deployed.
Thus, NACK.
It takes quite a while for a new major release to be widely deployed. It’s not like the network will all switch in one day after 0.12 release. The P2P network is a mix of various versions. There is even now a part of nodes that runs with RBF enabled (at least those running master). Even a part that does full (non opt-in) RBF (see https://en.bitcoin.it/wiki/Transaction_replacement#Peter_Todd.27s_full-RBF_patchset ).
But it will take at least months before a large enough part of the network does replacement this feature is reliably usable from the viewpoint of a wallet user.
No matter what happens here, you need to take nSequence into account in your risk computations even now if you accept zero-conf. If you accept only confirmed transactions, there is no need to worry about RBF at all.
utACK
miners who are economically rationale may likely still set -permitrbf to true.
…in the future. But currently they are more interested in high BTC price because the block reward is much higher than the tx fees, and the amount of transactions in block is quite limited. 0-confs are unsafe but usable, breaking them may negatively affect the BTC price.
@wangchun The wallets that don’t warn about the opt-in RBF flag are trivially vulnerable to multiple ways of doublespending transactions. For instance, I don’t know of any standard wallets that warn you if someone sends you a really low fee tx, even though they can be trivially doublespent with a higher fee tx. Similarly, because v0.12.0 changes what’s allowed in OP_RETURN, you’ll be able to easily doublespend by sending txs that use this new OP_RETURN format, followed by a tx that doesn’t.
As for dedicated zeroconf providers like blockcypher, I don’t know of any who haven’t added opt-in RBF detection.
Maybe - even if we don’t agree with zero-conf - we should still create some guidelines on how to accept them as safely as possible.
I mean it’s a bit like promoting abstinence as a way to prevent unwanted pregnancies and STD’s, it just doesn’t work. So we better also make sure it is as safe as possible.
My personal view is that Opt-in RBF improves zero-conf by making it very clear what can and can’t be replaced. But wallet/merchant developers still need time to account for it.
Default settings are advice from the Bitcoin Core team; I believe it is bad advice to disable a feature that helps Bitcoin users as a whole for the sake of concerns that aren’t justified by evidence.
That would be not unlike shipping Bitcoin with transaction relaying for P2SH turned off, because of an controversy about it that wasn’t supported by the facts.
People who still disagree are welcome to run other software.
On 21 January 2016 16:11:09 GMT-05:00, Arsen Gasparyan notifications@github.com wrote:
@petertodd why not to make this controversial change disabled by default and let the node operators chose?
Reply to this email directly or view it on GitHub: #7388 (comment)
@sipa “It’s only an issue for merchants who accept 0-conf transactions, not wallets (who typically don’t count unconfirmed transactions from the outside as spendable anyway).”
I don’t buy that. A wallet user is a financial actor. The question is not whether they will spend those particular received bitcoins, but what actions they will or may take on the receipt of those bitcoins. At the ery minimum the wallet GUI should expose whether the transaction (or one of its ancestors) was opted in - this functionality shouldn’t be limited just to RPC IMHO.
Even though I believe opt-in (and only opt-in) RBF is an improvement for overall zero-conf reliability, and has other use cases, the community clearly does not want the network to honor any kind of RBF at this time. So there should be a switch (thank you #7386) and the default should be do-not-permit.
ACK.
@sipa It is not us that should show you that services for 0-conf acceptance have implemented discard function for non-final nSequence values. This is something that you should know all about and show us before you implement such dramatic changes to policy. @petertodd You are the one implementing new policies. Because of this you are the one that must justified by evidence that this new policy helps Bitcoin users as a whole.
I think it is really bad the way you guys are trying to force bitcoin into lightningcoin. Stealing fees from the miners will kill the long term viability of the Bitcoin network.
You can see what the community thinks of RBF here:
@petertodd wrote: “Similarly, because v0.12.0 changes what’s allowed in OP_RETURN, you’ll be able to easily doublespend by sending txs that use this new OP_RETURN format, followed by a tx that doesn’t.”
So this OP_RETURN hard fork incompatibility is now an attack vector against 0-conf spends, by someone who has already publicly defrauded Coinbase using a double spend attack.
Nice work!
ACK. I suggest setting the default to false so that volume of opt-in RBF does not exceed the intentionality of the Bitcoin network. Once it has been demonstrated that a significant majority of volume has proper detection, only then does it makes to me to revisit setting the default to true.
I know for a fact that no one has yet confirmed that a significant majority of volume has proper Opt-In RBF detection.
So this OP_RETURN hard fork incompatibility is now an attack vector against 0-conf spends, by someone who has already publicly defrauded Coinbase using a double spend attack.
Every policy change (and it’s not a hard fork or an incompatibility, just a change in what transactions get relayed) introduces an increased chance for succesfully double spending. That’s inevitable. Worse, it can’t be prevented, as anyone can change their software to modify policy.
I’m sure you don’t want to never change policy rules, though. We used to have a minimum 0.01 BTC rule, for example. Should that never have been removed?
Policy changes are sometimes necessary, so the temporary differences in what nodes relay too. You can however personally make the judgement that a 0-conf transaction is acceptable to you. Perhaps because you trust the sender. Perhaps because you can undo what you do in return if it fails to confirm. And perhaps because you’re doing analysis of the transaction to estimate the chances, or let someone do it for you. And if you do the latter, you should take the nSequence value into account, because it already and since Bitcoin 0.1 is used in determining whether the transaction was final.
@sipa with the greatest of respect, you could close vulnerabilities like that if you weren’t all so afraid of a planned hard fork.
What’s more important - the raw number of nodes (even with masses running on AWS, running pre-0.8, etc.) or the number of functioning nodes?
Is there a concern that a hard fork will expose the emperor has no clothes? i.e. that planned hard forking isn’t catastrophic, and that actually the large number of nodes on the network were just illusory anyway, old machines forgotten about in university server rooms.
Right, enough politics on GitHub. I’ll take it elsewhere. If it means anything - utACK.
“People who still disagree are welcome to run other software.”
Gotcha, so what you are saying is that you don’t care about consensus. This is a new feature that you want, and it is going to be implemented regardless if the majority of the community disagrees.
@stale2000 By no means is this a new feature. Replacing transactions was originally in Satoshi’s first version. Since this is node policy, not consensus (it won’t cause a fork). Where does the majority of the community disagree? Are they disagreeing because they don’t understand how Opt-In works? @sandakersmann by that logic any implementation of Bitcoin and any new feature added and any new feature planned is “central planning”. If that didn’t happen, nothing would get done and we wouldn’t see new features.
How are they interfering with the free block space market? By not deploying a hard fork to increase the block size limit right now? Soft forks can be problematic, hard forks can be worse. They have good reason to avoid hard forks. Anyways, this is off topic.
NACK for this PR
NACK. Consider me as someone who absolutely opposes full-RBF, but if Core is going to support opt-in RBF semantics then it’s illogical to disable this by default.
I think most people ACKing this PR don’t understand how the currently implemented opt-in behavior works. At the very least the OP comments on this PR don’t make any sense given that #7386 didn’t change any existing behavior.
Maybe the flag should be renamed to -permitoptinrbf to prevent confusion?
Did you read this?
@sandakersmann you’re aware that the new behavior is opt-in right? As in, the sender of the transaction explicitly requests that they want the ability to double spend, and to the merchant/recipient it’s clear as daylight that this feature has been enabled. By default Core does not create these transactions, or even have the ability to create them currently.
So this is just adding extra flexibility to bitcoin if some people want to use it. Is there a good reason for reducing the flexibility of bitcoin transactions?
The reason this mempool policy change is so incredibly dangerous is that the entire bitcoin ecosystem is built around the assumption that the vast majority of nodes will (and are) rationally running a First-seen-safe policy. Since 99% of node operators do not change the default settings, this has been a safe-enough (not 100% safe obviously) assumption.
This change radically changes that assumption as retailers must now use wallets with advanced new RBF features. They must also come up with new workflows to deal with clientele who accidentally flag transactions as RBF. Most retailers wont bother with this hassle (at best) and potentially ignorant retailers will lose a lot of money (at worst). This policy change (and by policy i am referring to the default settings since 99% of node operators will not change the defaults) is the equivalent of a nuclear bomb on the retailer community.
@sandakersmann I have read that comment.
It is not us that should show you that services for 0-conf acceptance have implemented discard function for non-final nSequence values. This is something that you should know all about and show us before you implement such dramatic changes to policy.
Sipa is saying that there are no services which accept 0-conf transactions that accept non-final transactions. Since opt-in makes it non-final, they are already prepared for that. He (and everyone else on the team) has already looked at the services and have already determined that they all already deal with non-final transactions. He is saying that you would not be able to find any service that doesn’t already deal with those non-final 0-conf transactions because they all do.
I think it is really bad the way you guys are trying to force bitcoin into lightningcoin. Stealing fees from the miners will kill the long term viability of the Bitcoin network.
How is it stealing fees from miners? If anything, it increases fees for them.
You can see what the community thinks of RBF here:
How accurate is that survey? Does it accurately survey and represent the entire population? Do those who were part of that survey actually know what Opt-In RBF even means? @skajake Any service who already accepts 0-conf transactions will already check for certain things to be sure that the incoming transaction will be confirmed. One of them is the nSequence, and if it is not MAX_INT, then the transaction is non-final. Even if they do not upgrade, this code is already there because an nSequence that is not MAX_INT is already considered non-final and thus dangerous to accept 0-conf on. Thus that is irrelevant.
Also, if they only accept transactions with confirmations (as many do), then this doesn’t matter to the retailer.
Sipa is saying that there are no services which accept 0-conf transactions that accept non-final transactions. Since opt-in makes it non-final, they are already prepared for that. He (and everyone else on the team) has already looked at the services and have already determined that they all already deal with non-final transactions. He is saying that you would not be able to find any service that doesn’t already deal with those non-final 0-conf transactions because they all do.
I would like some documentation on that.
How is it stealing fees from miners? If anything, it increases fees for them.
Limiting transactions on the main chain will result in less fees. There is a limit to what people will pay before they seek alternatives.
How accurate is that survey? Does it accurately survey and represent the entire population? Do those who were part of that survey actually know what Opt-In RBF even means?
Those who want to change policy should provide documentation, but here is another survey: http://bitcoinocracy.com/arguments/rbf-replace-by-fee-policy-should-not-be-adopted-because-it-breaks-0-conf-transactions-and-needlessly-imposes-extra-development-costs-on-existing-merchants
I would like some documentation on that.
https://bitcoin.org/en/glossary/sequence-number
Part of all transactions. A number intended to allow unconfirmed time-locked transactions to be updated before being finalized; not currently used except to disable locktime in a transaction
https://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence is probably a better explanation. In this case their application replacement for increased miner incentives.
nLockTime and CLTV, which is itself new).
NACK, I can’t fathom why we should make this change. Opt-in RBF is already here, we’re planning on keeping it, disabling it by default just seems ridiculous. Wallet developers should update their wallets to properly make users aware of RBF when allowing 0conf.
If people are worried about users not being educated on RBF, then there should be a proposal on making sure users are informed. Not disabling RBF by default. It’s not the boogeyman, there is a flag, and this is a useful feature.
ACK
RBF needs to be pot-in. Let miners make an informed decision on such a controversial topic, don’t “silently” or automatically change this behavior.
I like the opt-in flag, don’t like that it is/was opt-out.
@ripper234, no the opt-in aspect is the fact that senders opt-in by flagging a transaction as RBF replaceable. The wallet owner can then choose to trust it before it gets a confirmation.
This is different than non opt-in RBF where there would be no flag and all transactions would be replacable before a confirmation.
If I’m understading this new option correctly, this change would actually prevent even transactions that opted in from reaching the mempool.
@ripper234 this PR proposes opt-in to opt-in RBF as the default.
Without this PR, the current situation is opt-out to opt-in RBF.
Wow this shit is complicated :)
Ok, if I understand it correctly: What I want is opt-in to opt-in.
If I understand correctly, then ACK this.
@ripper234, I believe this would also force nodes to opt-in manually as well. I believe this change could reduce the usefulness of RBF.
I fail to understand the support for this change. RBF does not harm nodes or miners, at all. It makes sense for them to choose to disable it by personal preference as someone who doesn’t know or care about RBF wouldn’t be affected in the slightest.
Wallets regardless of this change will have to still be safe, and educate about 0-conf and RBF. This change does nothing but hurt RBF, and doesn’t seem to benefit anyone.
As @skajake has stated the overwhelming reason that people oppose RBF is not lack of knowledge about it, but the potential impact it has on businessss that accept Bitcoin. The last thing we should be doing is making it harder it scarier for businesses to interact with or accept Bitcoin transactions. Of course someone with @petertodds level of skill can double spend, but businesses accept risk of counteroffer money being used for purchases but governments aren’t making a huge issue about it so they self regulate those risks. If the news cycle were to suddenly start talking about the potential risks for accepting cash if would cause China’s and confusion. Just as RBF is doing.
This is bad for Bitcoin and having this turned on as a default is bad for Bitcoin.
Did devs talk to merchants about this. Because a lot of people in the retail space think this is horrible.
@laanwj. What businesses or retail business owners are NACKing on this thread? Or are you referring to dev consensus as consensus?
If you are that’s fine, but I feel like consensus is a word often used by devs about devs. I think this is a problem as consensus is tossed around a lot in here. For instance devs re: RBF talk about having had consensus months ago. Should we not strive for a much more robust definition of consensus to be used going forward? Maybe that way we can avoid a separation in dev consensus and user consensus that Jeff is referring to that can be seen in the consider.it polling.
This is bad for Bitcoin and having this turned on as a default is bad for Bitcoin.
Having the possibility of opt-in RBF does not mean that transactions are created with RBF opt-in by default. As far as I know, no wallets have this possibility at this point at all, let alone do it by default.
However, transactions that do opt-in to RBF are distinguishable (that’s the whole point of opt-in versus full RBF), so a merchant that normally accept zero-conf can take that into account and only accept the transaction when it has confirmed. There’s no extra risk when doing so.
It just increases flexibility to have this available. There are lots of complaints about stuck transactions that never confirm. WIth opt-in RBF it is possible to raise the fee on existing transactions (that opted in), so that transactions that initially had too little fee make it into the block chain.
By arguing to disable this you are killing a useful feature. No one will dare touch this again one it is disabled.
“By arguing to disable this you are killing a useful feature. No one will dare touch this again one it is disabled.”
If it is such a useful, needed, desired feature why would no one dare touch it if it was disabled??
I seems like if there is indeed great market demand for it, it will be used.
However, do you know for a fact that retail merchants will NOT have to do code integrations and/or updates in their systems for this? Has there been any (I really hope the answer is yes) surveying of experts in the bitcoin retail sector on how they feel about RBF and especially about it being defaulted as “on.” All I am hearing outside of devs on here is that it is not wanted. The only people saying it is useful are devs or non-retail related individuals. If I am wrong great. But I am simply looking at the evidence available.
If you are bound and determined to make this change, isn’t it reasonable to give people the option to “opt in” (all the way around, not just on one side) instead of opting out of something they simply may not understand or want?
Sidenote for @JonComer
[…] Maybe that way we can avoid a separation in dev consensus and user consensus that Jeff is referring to that can be seen in the consider.it polling.
Users consensus is very hard to measure. Did you know I can buy 1'000 twitter followers for 10USD? I’m pretty sure you can do something similar with consider.it or with github ACKs.
We should not start public voting for high complex technical discussions unless every bitcoin users must vote and must spend two days reading and studying the technical topic. Otherwise we start something that is called political parties. And this would be really bad for Bitcoin IMO.
I seems like if there is indeed great market demand for it, it will be used.
Opt-in RBF is a compromise that can’t be used if the network doesn’t support it. It is not very useful if only a few nodes support it. @petertodd’s full-RBF patch solves this by adding a version bits so that nodes that support full RBF can find each other. That’s the other path. It allows some users to use RBF without marking transactions in a way that opt-in RBF does.
Opt-in RBF is a compromise that keeps the sanity. Users that want to use RBF can do so without harming users that don’t want to use it. Full RBF on the other hand allows full double spending and (absent other precautions) makes zero-conf completely useless.
It’s naive to think that keeping back opt-in RBF will also discourage full RBF. If anything, some users and miners have got so annoyed by this political maneuvering that they’ve started to support full RBF.
@jonasschnelli I nowhere said we should “vote”. However business analyst exist in this world because they act as bridges between user/consumer/client desires and demands and engineers/technicians/coders. Otherwise “innovation” is done in a vacuum. We are, in my opinion, seriously lacking in the equivalent of business analysts in the bitcoin community. Right now we seem to be operating by the sole principal that “devs know best.” In the real world this is simply not true. Does it not concern you at all that there is so much “potential” push back on this subject?
Or are devs just the smartest people in the room and the rest of us have not the intelligence to count as opinions?
A couple of questions just to clarify where you stand on this topic.
Do you support RBF because you think its important to give people the option to “move to the front of the line” by paying more fees or is it more (or equal) to try and “protect” retailers from double spends?
If you only think the former is a case for then ignore this next part. But if you think the latter is a case for, then why do you think it is that no one is double spending? (outside of @petertodd)? And can you possible see how people feel that there is a solution looking for a problem? In other words, “if it ain’t broke, don’t fix it.”?
@JonComer I know for a fact that those using zero conf will have to update regardless of opt-in RBF because virtually any release introduces some network changes (min relay fee, min dust, mem pool limiting, OP_RETURN updates isStandard changes, etc) which can and will be exploited for double spends.
I’m not even the first one to say this in this very page, you should probably read what the others already said before contributing your opinion as we otherwise further confuse people.
Dealing with zero conf has always been a catch up game. opt-in rbf gives us the best of both worlds.
The changes to detect opt-in RBF should be already implemented since originally Satoshi has designed the nSequence number to mean that a transaction can either be final or non final. Even if not, it is pretty much a trivial change, sometimes a one liner.
People that do zero conf professionally seem to already take into account this (as they should!)
@JonComer: I totally agree with you. But we are discussing on a technical platform (the heart of the technical project management of Bitcoin Core).
Business analysts may help write BIPs (bitcoin improve proposals) or help people choosing which bitcoin software they should run.
But this is the wrong place for analyst level discussions.
I opened a consider.it page.
https://bitcoin.consider.it/set-permitrbf-to-false
If anyone has a better description for this feature, let me know. I used:
RBF: Miners opt-in (config) to allow tx opted-in by users to be Replaced-By-Fee.
This is fortunately or unfortunately the most and only direct root to most devs. “This is not the place” is not true in my opinion. Those anaylst level discussions just are not being held other places. I think you can expect more people like myself looking to speak directly to the source in the future. And I think that communication is valuable both ways. If you can point out the best place (or a much better place) then I will do my best to spread the word to the community.
But the truth is decisions that effect the community are being ACKed and NACKed right here on github. And up to recently a large majority of the bitcoin eco system didn’t even know it was happening.
@JonComer: See https://bitcoincore.org/en/contribute/ and https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#decision-making-process
But the truth is decisions that effect the community are being ACKed and NACKed right here on github.
IMO not true. Decisions are made by people who run the new (or old) software. Miners, merchants or user (node operators).
Do you support RBF because you think its important to give people the option to “move to the front of the line” by paying more fees or is it more (or equal) to try and “protect” retailers from double spends?
Both:
I support RBF because I want wallets to be able to ‘unstuck’ transactions that have already been sent. This is a clear solution for a clear problem, but it is not all. There are also more advanced contracts/applications that require RBF.
I support opt-in RBF because it allows those parties which prefer the old status quo to still do their thing. It is clear that there is a group of people that want RBF for legitimate reasons, and as said, opt-in provides a compromise where both groups can co-exist peacefully.
But if you think the latter is a case for, then why do you think it is that no one is double spending?
I suspect that’s due to social factors. Maybe no one wants to screw you. Maybe the (perceived) cost of doing so is much higher than what is to be gained. Maybe bitcoin users, despite being universally portrayed as criminals in the media, aren’t that bad and just want this to work. Do I know?
In any case allowing opt-in RBF won’t change this. For transactions not opting in you can treat them as before, for transactions opting in you accept them after 1 confirm.
As noted by other people, it is fine if the feature is controversial because this is just rlay policy and not a consensus rule. But I really don’t understand how can opt-in RBF be possibly controversial. Maybe there is a lesson to learn here: full RBF has been implemented for years but never merged because it was “controversial”. After long, the more complex opt-in RBF was developed, with the goal to remove those “controversies”, but it turns out it is unexplicably “controversial anyway. Maybe we should have just deployed full RBF years ago…
That, plus changing defaults for configurable values is usually a waste of time that mostly just generates noise and long discussion threads like this one. Nobody is forced to use the default values. Anybody can make a parallel release (analogous to @petertodd’s RBF parallel release) with the “right defaults” to promote whatever relay policy they like more instead of bike-shedding defaults here.
NACK.
Maybe we should have just deployed full RBF years ago…
So when a dangerous policy change is faced with controversy, your solution is to force a more radical version down the throats of your users? I sincerely hope you are trolling
So when a dangerous policy change is faced with controversy, your solution is to force a more radical version down the throats of your users? I sincerely hope you are trolling
You’ve been fed a false history. Full RBF was the original proposal, which was too controversial to be widely adapted. Opt-in RBF was proposed as a compromise to make both RBF supporters and the status quo happy. If the compromise fails, both groups go back to their extremes. People that want to use RBF will do so, by the means available (the full RBF patch). In contrast to this compromise, that doesn’t need to be widely adapted (or “forced down the throats of users”, who’s trolling?) to be useful. But it is much more “dangerous” as it contains no flagging of transactions that can be replaced.
ACK
All rules don’t fall under block chain enforced consensus. Some things depend on honest nodes and altruism. Relaying transactions is one such thing. The context here is that irreversibility is a feature. Double spending is the problem and the block chain is that solution.
What is the block chain confirming? The first payment of the spender. Hence, it solving the double spend problem.
Satoshi was clear on the first-seen-safe policy as a risk reducer. The context of a violation of that rule is that the minor confirming a double spent transaction either did not see the first one OR the minor is dishonest. Those are the only two options. Discovery of dishonesty is a deterrent. In an ideal mining context there are thousands of nodes creating blocks and their operators run honest code. In today’s mining context with so few nodes creating blocks we can identify the dishonest nodes who are accepting a bribe to assist in theft. Bitcoin is designed to prevent double spends anyone participating in undermining that is a dishonest actor (by definition).
Can we close this? I have seen a bunch of complaints from people who have never contributed to Bitcoin in any significant way and no complaints from any wallets, anywhere. On the other side, I’ve seen several wallets desperately asking for this feature. This issue is not going anywhere.
Worse, the submitter cant even be bothered to fix the tests. Not sure if this was meant to be political bullshit or a serious suggestion, but it has turned into political bullshit.
I agree with @TheBlueMatt, this discussion isn’t going anywhere. Many in support of this change are simply against RBF, and this PR isn’t about whether RBF will stay in core. Nobody has addressed exactly what benefits this change will have (regardless if this changes goes in, wallets and merchants will be at roughly the same risk for 0-conf), we seem to only downsides.
There’s always opportunity to discuss the merits of opt-in RBF somewhere else.