1447 sats \ 16 replies \ @based 13 Nov 2022 \ on: A bit confused around Full RBF bitcoin
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.
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.
reply
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...
reply
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.
reply
How does this make sense? If a particular feature breaks another feature, then it's a fair discussion to have, isn't it?
reply
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.
reply
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.
reply
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
reply
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.
reply
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.
reply
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).
reply
Frankly you missed the point.
reply
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!
reply
I'm saying opt in RBF is not a good user experience. Your answer is that opt in RBF fixes this.
reply
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.
reply
If wallets of today have turned it around to make RBF effectively opt out instead then I agree it's less of a point.
reply
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.
reply