pull down to refresh
75 sats \ 5 replies \ @based 13 Nov 2022 \ parent \ on: A bit confused around Full RBF bitcoin
Frankly you missed the point.
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