A bit confused around Full RBF \ stacker news ~bitcoin

542 sats \ 53 comments \ @fanis 13 Nov 2022 bitcoin

I'm quite confused about Full-RBF. None of the reasons advocating for Full-RBF really convinced me so far, and even the original DoS-protection use case by Antoine Riard doesn't seem so compelling now.

I get that policies are per node, but what Core enables matters. I also get that 0-conf isn't safe, but at least BIP0125 allowed for some risk management, which seems way more "opaque" with Full-RBF. I also get that eventually all miners will apply Full-RBF to maximize revenue when rewards shrink, but does it justify pushing this hard for v24.0?

If you don't mind, please throw me your best arguments in favor or against Full-RBF. I've been doing my homework but it feels like I'm missing something.

(Note: this is duplicate from Twitter. Resposted here because I know that's where the best people are :)

view all related items

1447 sats \ 16 replies \ @based 13 Nov 2022

Having to opt into being able to solve a simple mistake in advance is not a good user experience. It's asking users to plan their mistake and know to do so.

If always enabled privacy is somewhat better, because it leaks less information about the user wallet software and user habits.

Bitcoin settles on-chain. Settling in the mempool is not by design.

Bitcoin must be scaled up in layer and the current solution to small fast payments is Lightning.

171 sats \ 0 replies \ @petertodd 13 Nov 2022

If always enabled privacy is somewhat better, because it leaks less information about the user wallet software and user habits.

Notice how this tradeoff is fundamentally a political conflict between different classes of users: the tiny minority of centralized businesses(1) trying to accept zeroconf, and the much larger group of Bitcoin users who are harmed by the privacy leak of the opt-in flag. So it's entirely appropriate to treat this as a political decision, to be made by the wider community.

Of course, since zeroconf is so insecure, it'll only take a small minority of users/miners to render it useless with full-rbf... Kinda says something about how dumb this way of using Bitcoin is.

1) just two spoke up in favor of keeping zeroconf indefinitely on the bitcoin-dev mailing list.

26 sats \ 7 replies \ @felix 13 Nov 2022

Having to opt into being able to solve a simple mistake in advance is not a good user experience.

Absolute mischaracterization. Literally every wallet can add RBF. In fact, Green Wallet has RBF set to be always on.

Enforcing RBF on every transaction implies that you're taking away a way to use Bitcoin: mempoolfullrbf is literally only taking away functionality, while adding nothing.

I'm honestly kinda pissed about how this is portrayed by some...

105 sats \ 1 reply \ @petertodd 13 Nov 2022

You know, if your way of using Bitcoin is so insecure that a small minority of people choosing to use a particular features wrecks it... maybe consider not using Bitcoin that way.

0 sats \ 0 replies \ @felix 14 Nov 2022

How does this make sense? If a particular feature breaks another feature, then it's a fair discussion to have, isn't it?

25 sats \ 4 replies \ @ek 13 Nov 2022

while adding nothing.

Absolute mischaracterization. Literally everyone who uses 0-conf trusts that a double spend transaction won't be broadcasted and mined by a miner. This change shows the merchant that they are no longer "protected" by "default settings".

you're taking away a way to use Bitcoin

Yes, we're taking away a way to use Bitcoin in a way it wasn't meant to be used.

25 sats \ 3 replies \ @felix 14 Nov 2022

Literally everyone who uses 0-conf trusts that a double spend transaction won't be broadcasted and mined by a miner.

Yes, congratulations, you understood the risk businesses have to account for when enabling superior user experiences with 0-conf. 👏

Yes, we're taking away a way to use Bitcoin in a way it wasn't meant to be used.

The audacity... fucking unbelievable.

75 sats \ 2 replies \ @ek 14 Nov 2022

Please tell me, what is more important to you:

Superior UX for users of businesses relying on 0-conf since they don't have to wait for their tx to be included in a block

vs.

Superior UX for all users since they can bump their fee to have it included in the next block faster without having to enable or think about it in advance

25 sats \ 1 reply \ @felix 14 Nov 2022

Wrong.

If you use Blockstream green, you don't have to think about it. If you enable it in wallets where it's supported, you don't have to think about it. If your wallet doesn't support RBF, then change your wallet.

55 sats \ 0 replies \ @ek 14 Nov 2022

If you use Blockstream green, you don't have to think about it. If you enable it in wallets where it's supported, you don't have to think about it. If your wallet doesn't support RBF, then change your wallet.

Lots of if's for saying that

without having to enable or think about it in advance

is wrong, no?

Basically, your comment reads like this:

No, you are wrong. You don't have to think about it if you don't have to think about it.

26 sats \ 6 replies \ @fanis OP 13 Nov 2022

Thank you for your answer! Regarding your user experience point, we already have Opt-in RBF for that. To fix UX, lobbying wallets to implement Opt-in RBF and present a clear UX to the user, so that they can understand whether to enable RBF or not, seems a more healthy approach to me than pushing a new option in Bitcoin Core, especially after realizing that there is no real consensus regarding this issue.

I read the privacy point a lot too, but I quite don't get it. Most wallets I use allow me to enable or disable RBF at will. And it seems to me that lobbying other wallets to implement Opt-in RBF would fix this privacy concern as well.

I get that enabling Full-RBF would basically achieve the same result as broad support for Opt-In RBF in wallets and clear UX, but what worries me is that we then lose the signalling feature that is so useful to zero-conf services, including some Lightning wallets.

That's also why I don't find the on-chain/L2+ dichotomy convincing: some very good non custodiual Lightning wallets rely on 0-conf to provide a user experience that is as good as custodial ones (and I'm not talking about Muun, which I prefer to set apart, but Phoenix or Breez for example).

75 sats \ 5 replies \ @based 13 Nov 2022

Frankly you missed the point.

55 sats \ 4 replies \ @fanis OP 13 Nov 2022

One point in particular (UX, privacy, ...) or the overall picture?

I'm really trying to understand. I agree nothing is settled in the mempool. But some services and businesses decide to accept such transaction and rely on the fact that what's in Core defines the most largely adopted policy, and hence what will probably be relayed to miners.

I also like using Lightning better than 0-conf, but it appears a lot of people don't. Bitrefill is a great example of that, as it offers the two options.

Would you mind developing what I missed? It's ok if you don't, really appreciate you took the time to answer in the first place. Thanks!

65 sats \ 2 replies \ @based 13 Nov 2022

I'm saying opt in RBF is not a good user experience. Your answer is that opt in RBF fixes this.

95 sats \ 1 reply \ @fanis OP 13 Nov 2022

Gotcha. What I don't understand is why the UX is so bad. In all the wallets I use, RBF is enabled by default, I don't have to think about it, ever. If I wanted to use a service that would like me to disable RBF for a transaction, I could decide to do it if I see fit. There's definitely room for improvement, but the UX of a wallet where Opt-in is on by default seems the same to me as one with Full-RBF, with the added benefit of signalling intent to (potentially) replace the transaction.

You don't have to "plan your mistake", just leave Opt-in RBF enabled and you don't need to think about it.

So I'm guessing your point is that today users kind of need to understand what RBF is to be able to pick a wallet that allows them to benefit from the comfort of RBF most of the time (thanks to Opt-In RBF being enabled by default) while still signalling and being able to switch the feature on and of. As I've said in another comment, this could be made largely easier by communicating that RBF should be disabled for a specific transaction throught a BIP0021 QR code, letting the wallet automatically disable it just for this transaction and automatically reenable it after, keeping RBF the default.

35 sats \ 0 replies \ @based 13 Nov 2022

If wallets of today have turned it around to make RBF effectively opt out instead then I agree it's less of a point.

25 sats \ 0 replies \ @clownworld 13 Nov 2022

You're right.

Lightning is just not a solution sometimes. This is because the amount may be fairly large, or simply because the merchant doesn't accept lightning.

In such cases, many merchants simply don't accept RBF transactions, obviously because they can easily be replaced. This is why I want the option not to use RBF - it doesn't work for a number of use cases.

Some extreme people will say it's dumb to try to reduce the risk of double spends for 0 conf cases. This does not make logical sense though - just because something isn't perfect doesn't mean that we should make it even worse.

As far as I'm concerned, the entire problem could simply be solved by kicking transactions out of the mempool more quickly just based on their time pending. IMHO no transaction needs to be pending more than a day. If it gets rejected, just resend it. But they instituted this dumb policy of keeping transactions that could be stuck around for weeks...

But why not at least try to make 0 conf transactions as reliable as reasonably possible? Even if it's not perfect, it's better than no reliability. BCH and XEC (a recent BCH fork) have taken some steps to make 0 conf even more reliable and I don't see anything wrong with that idea. As I said, the easiest solution to stuck transactions is rejecting them from the mempool more quickly - you could even do it in hours. Two weeks is ridiculous.

271 sats \ 0 replies \ @theinstagibbs 14 Nov 2022 freebie

Full RBF enables people to defraud services who let you walk away with goods and services without a confirmation, which is incentive compatible with miners wanting more fees.

The other case is that some wallet users accidentally don't opt into RBF then get their funds stuck for weeks on end.

207 sats \ 5 replies \ @petertodd 13 Nov 2022

Other people have made good points. But one thing I think hasn't been discussed is incentives to attack Bitcoin: because zeroconf transactions rely on the P2P network, both merchants trying to rely on them, and attackers trying to double spend, have incentives to attack the P2P network.

The latter is more obvious: if you sybil attack the network, DoS miner's nodes, etc. you can break the very weak consensus that zeroconf is relying on. We don't want people to have a profit motive to attack Bitcoin nodes, so full-rbf is desirable by taking away that profit motive.

The latter is less obvious: merchants trying to do "risk management" of zeroconf transactions inevitably find they have to try to measure propagation of transactions. But because Bitcoin has decent privacy protections, the only way to do that is for the merchants to perform sybil attacks against the P2P network! While this is a mild attack per merchant, it adds up: eventually the whole network will run out of connection slots. Again, we don't want this incentive to exist. And of course, since only a small number of merchants can successfully do this, it's very centralized.

Finally, in the past we've seen merchants try to make deals with miners to make zeroconf more reliable. This is really ugly at the end stage, because the only really effective way to guarantee zeroconf txs get mined is to get miners to do 51% attacks on miners who don't mine the "right" transactions that "came first". Due to the P2P attacks, and the general lack of consensus in the mempool, it is impossible for smaller, non-anonymous, miners to always mine the "right" txs.

So yeah, when v24.0 is released, please set mempoolfullrbf=1 on your home nodes, and mining nodes. It's better for everyone if we get rid of this opt-in-rbf/zeroconf nonsense.

99 sats \ 0 replies \ @jk_14 14 Nov 2022

It's better for everyone if we get rid of this opt-in-rbf/zeroconf nonsense.

This.

25 sats \ 3 replies \ @felix 14 Nov 2022

Please don't activate mempoolfullrbf, if you're not 100% confident you understand what you're doing here.

26 sats \ 0 replies \ @petertodd 14 Nov 2022

It's a node setting. If people choosing to relay replacements makes that big of a difference to people relying on unconfirmed transactions... that says a lot about how utterly broken relying on unconfirmed transactions is!

25 sats \ 1 reply \ @ek 14 Nov 2022

What are the drawbacks? Why shouldn't I activate it?

25 sats \ 0 replies \ @felix 14 Nov 2022

It removes functionality.

465 sats \ 4 replies \ @Scroogey 13 Nov 2022

The feature as it is now seems weird: when I create a transaction, I must decide if I want to enable the option or forfeit my option to RBF later on. I should enable it, in case I make a mistake or want to increase fees later on, but I should disable it when sending to a 0-conf service, because they will perceive it as a threat?

For me, it would make the experience simpler and better if it was just always enabled. Less potential for regretting a wrong decision.

41 sats \ 0 replies \ @fanis OP 13 Nov 2022

Thank you for your answer!

Imo the UX issues you describe shouldn't be addressed by Core, but by wallet developers making things more seemless. For example auto-enabling/disabling RBF depending on mempool congestion (enable RBF if disabled when there's some congestion) and hopefully counterparty preferences (there's some discussions around upgrading BIP0021 QR codes to also convey things such as preferred fee and whether the recipient wants the transaction to be RBF-enabled or not).

It's okay to not like a zero-conf service asking you to disable RBF (or waiting for 1+ confirmation if RBF is enabled, but I think it's okay as well for such services to have their preferences and voice them. Trade is always a bargain.

31 sats \ 2 replies \ @felix 13 Nov 2022

Regarding 0-conf services, we could implement a UX where you wouldn't even notice that it switched back to 0-conf for a particular merchant. All automatically. Just need to build it.

26 sats \ 1 reply \ @ek 13 Nov 2022

Unnecessary added complexity for people who rely on trust in a system meant to minimize trust instead of just using Lightning if they want fast payments.

26 sats \ 0 replies \ @felix 14 Nov 2022

What are you talking about? it literally reduces complexity for users, while improving UX.

Apart from the fact that on- and offboarding to LN is not a "solved issue", it's incredibly ignorant to assume that it's "lightning-or-bust".

Flexibility on the base layer increases flexibility on Layer 2, independent of what types of L2s will exist in 5-10 years.

412 sats \ 2 replies \ @DarthCoin 13 Nov 2022

115 sats \ 1 reply \ @fanis OP 13 Nov 2022

Lmao, you should've wait for tomorrow's meme contest, would've been a clear win!

25 sats \ 0 replies \ @DarthCoin 13 Nov 2022

I already won the contest, because you like it :)

340 sats \ 9 replies \ @cointastical 13 Nov 2022

Let me ask this question.

If every wallet and service were to already have enabled opt-in RBF and set it as the default, would there be anyone left arguing against simply going the final step and applying Full-RBF into Bitcoin Core?

Anyway, my feeling towards this is that there is today an advantage given a miner or pool over me with regards to replacement transactions. They can cause a transaction to confirm (even one that would be considered by the zeroconf merchant to be a "double spend") that I cannot. All Full FBF does is give me essentially the same power that a miner or pool already has as far getting a replacement transaction confirmed.

26 sats \ 1 reply \ @fanis OP 13 Nov 2022

Thank you for your answer!

If everyone had opt-in-RBF enabled by default, 0-conf services can still see for each transaction whether it will (probably) be able to be replaced or not. We all agree the service has no certainty, but they can do risk management by evaluating how much funds they have sitting in unconfirmed transactions not signalling for replacement, the same amount sitting in unconfirmed transactions actively signalling for replacement, and set global thresolds (ex: no more than 1 BTC in the mempool in transactions not signalling replacement) and per-transaction theresold (ex: wait for N confirmations for amounts bigger than X).

Regarding miners having more power than you, I'm not sure I understand. If a miner is able to run software that considers all transactions in their mempool as replaceable, you certainly can too (for example, by running Bitcoin Knots instead of Bitcoin Core).

25 sats \ 0 replies \ @cointastical 13 Nov 2022

but they can do risk management by evaluating how much funds they have sitting in unconfirmed transactions not signalling for replacement

Would anyone even expend the effort if effectively all of the transactions are signalling for replacement (once all wallets have opt-in RBF enabled by default)?

In other words, this could be forced through at the wallet app/edge device level, but that would take longer -- rather than this change to the relay policy that the bitcoin core client implements.

If a miner is able to run software that considers all transactions in their mempool as replaceable

I confirm no blocks, I have no power to include a transaction that other miners will not.

Today miners and pools (or cartel of miners and pools) can include any valid transaction in a block.

and set global thresolds (...) and per-transaction

That doesn't prevent attacks, it just makes the weakest and most obvious attacks to be less likely to be successful. Zeroconf is simply not safe and the sooner it is put to rest (i.e., communicate that it will be financial suicide for anyone that continues to implement it) the better, in my opinion.

26 sats \ 1 reply \ @iguano 13 Nov 2022

You have the option of using RBF if you want , not sure why you want to force others .

The miner power you are saying you want to have is just mental gymnastics to me.

Sorry if I’m being rude but it is what it is …

131 sats \ 0 replies \ @cointastical 13 Nov 2022

The miner power you are saying you want to have is just mental gymnastics to me.

Back when Satoshi Dice was paying out on zeroconf (2012), and again when some Bitcoin ATMs dispensed cash on zeroconf (2019) there was the expectation that there would be miners that would exploit the obvious risk that existed with zeroconf implementations. And indeed both of those ended with losses being taken due to their reliance on zeroconf.

About the only reason it didn't happen on day one is it took a while for some miners to realize there was the opportunity to profit from doing this, and weighed the reward was risk (being ID'd and labeled as a bad actor) versus the reward and eventually deeming the reward to be sufficient relative to the risk.

So miners have the opportunity to profit by exploiting zeroconf but I do not. It's not that I want to profit from this vulnerability, it's that zerconf is a flawed approach, and that flaw should be fully exposed as a flaw, which can be done by making it so that Core v24.0 and later will simply relay replacement transactions regardless of RBF signaling.

25 sats \ 4 replies \ @felix 13 Nov 2022

Good point!

But again; mempoolfullrbf is only removing funcitonality.

Since there's large businesses creating superior user experiences with 0-conf transactions (e.g. Bitrefill, 0-conf-channels), and everyone can use RBF TODAY without any issues, why do we need to enforce this?

I honestly don't understand it. Incredibly stupid...

25 sats \ 3 replies \ @ek 14 Nov 2022

Does this superior user experience go beyond not having to wait for 10 minutes to have the tx included in the next block?

25 sats \ 2 replies \ @felix 14 Nov 2022

Oh, so you're implying there's no need for instant payments?

Sorry to disappoint you, but there's a thing called Lightning Network that's quite popular I believe.

25 sats \ 1 reply \ @ek 14 Nov 2022

Exactly, people should use the Lightning Network for such cases.

25 sats \ 0 replies \ @felix 14 Nov 2022

You do realize that we need flexibility in onboarding funds onto lightning, right? Turbo channels are immense onboarding ux improvements.

251 sats \ 1 reply \ @DarthCoin 13 Nov 2022

https://medium.com/@nicolasdorier/properties-of-money-and-full-rbf-cf99de9f9b50

0 sats \ 0 replies \ @ek 14 Nov 2022

Would this impact the defensibility of Bitcoin? One could make the case that, because it is now easier to cancel a transaction before it is confirmed, then it is harder to defend your Bitcoin.

This argument doesn’t hold: Everybody will agree that unconfirmed Bitcoin aren’t your bitcoins to begin with, so there isn’t anything to defend. Only way to own Bitcoin is to get it mined into a block. The reason is that there is no consensus on what the list of unconfirmed transactions is.

Another case can be made: Does full RBF impact the portability of Bitcoin? John would maintain that it makes it harder for people to spend their Bitcoin and it makes it harder for the merchant to accept Bitcoin. This argument on the surface has some merits but fails to convince me. [...] If we were to accept John’s argument, almost anything could be considered as impacting portability and thus be unethical: For example with the Taproot soft fork, we got a new address type. Suddenly, some people sending Bitcoin with old wallets wouldn’t be able to send to some other people with Taproot wallets. Should those people assert that introducing a new address type is unethical because it makes sending bitcoin harder for them? Same test can be used: If 100% of people supported taproot addresses, or if 0% of people supported taproot addresses, in both case Bitcoin would still be a perfectly fine money! Thus, introducing a new address type is ethical.

30 sats \ 0 replies \ @faithandcredit 14 Nov 2022

As far as I understand it's not Full RBF in itself that being debated it's also whether or not Bitcoin Core should be used to nudge or influence whether it's on or off. The best thing that could happen imo is full rbf became a standard mempool policy without bitcoin core doing a "force majure" because that is more in line with the voluntary nature of bitcoin and Bitcoin Core so far. So would it be ok this one time, for Bitcoin Core to break some functionality that some people rely on in favor of full rbf which some argue would give a more consistent user experience in the long term?

73 sats \ 0 replies \ @kristapsk 13 Nov 2022

Note that there isn't plans to enable full-RBF by default for next release of Bitcoin Core. All discussion is about off by default option that allows node runners to enable full-RBF manually by changing default configuration.

106 sats \ 6 replies \ @iguano 13 Nov 2022

I never use RBF and after 6 years using bitcoin I never had an issue of one transaction getting stuck in the mem pool, there is enough mempool tools to check what fee is the right one , wallet are getting better and better giving you the information you need to get your transaction confirmed soon with the enough fee for your transaction.

Forcing everyone to get RBF enabled makes no sense to me, no wonder why we have so many conspiracy theories around bitcoin …

25 sats \ 5 replies \ @jk_14 13 Nov 2022

Not only a single time I have set the "right" fee using mempool tools - and I had an "luck" to stuck in the suddenly very long time block, with rising fees and then I needed to wait many hours. Or just use RBF, fortunately.

Long time ago there was a lot such too low fee transactions in mempool, waiting whole months. What doesn't look healthy.

55 sats \ 0 replies \ @felix 14 Nov 2022

Mempool management is not something to be decided on the protocol level. The less shit we enforce on the protocol level, the more flexibility wallet developers have in using bitcoin.

You're simply implying wallets have to improve, that's it.

mempoolfullrbf is purely taking away a way to use bitcoin, and telling businesses how they should use Bitcoin. Wasn't Bitcoin supposed to be freedom money? Wtf.

25 sats \ 0 replies \ @petertodd 13 Nov 2022

In fact, there's been long periods where fees were high enough that some mining pools weren't mining low fee txs at all, making it downright trivial to double spend. Eg this write-up was done entirely with full-rbf during one of those periods: https://petertodd.org/2016/are-wallets-ready-for-rbf

Worse, if somone wants to exploit zeroconf one way to do it is to attack the p2p network and miners, eg with sybil attacks. We really don't want to give people incentives to do this.

25 sats \ 2 replies \ @iguano 13 Nov 2022

So I guess we are fine then, you don't force others to use RBF and nobody force you to not use it :) choice is always good :)

25 sats \ 1 reply \ @jk_14 13 Nov 2022

it's the matter of what is default - choice to switch-off RBF is good, as well

especially for newbies, they may even don't know wtf is RBF - till their first transaction frozen in mempool "forever" (that was common case in 2017)

In case of default RBF - there wouldn't be such not easy to solve surprise

25 sats \ 0 replies \ @iguano 14 Nov 2022

you cannot switch-off RBF if is enforced on the node that will broadcast your transaction. you are taking away my choice of not using it.