465 sats \ 4 replies \ @Scroogey 13 Nov 2022 \ on: A bit confused around Full RBF bitcoin
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.
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.
reply
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.
reply
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.
reply
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.
reply