Author: Antoine Riard 2022-10-20 01:37:25
Published on: 2022-10-20T01:37:25+00:00
In a post to the bitcoin-dev mailing list, Sergej Kotliar, CEO of Bitrefill, warned that the real dangers of RBF as default policy aren't sufficiently elaborated. He said that there is an even bigger danger called the american call option, which risks endangering the entirety of BIP21 "Scan this QR code with your wallet to buy this product" model that we've all come to appreciate. Specifically, in a scenario with high volatility and many transactions in the mempools (which is where RBF would come in handy), a user can make a low-fee transaction and then wait for hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves up, user can cancel his transaction and make a new - cheaper one. The biggest risk in accepting bitcoin payments is in fact not zeroconf risk (it's actually quite easily managed), it's FX risk as the merchant must commit to a certain BTCUSD rate ahead of time for a purchase. Over time some transactions lose money to FX and others earn money - that evens out in the end. But if there is an _easily accessible in the wallet_ feature to "cancel transaction" that means it will eventually get systematically abused. A risk of X% loss on many payments that's easy to systematically abuse is more scary than a rare risk of losing 100% of one occasional payment. Bitrefill currently processes 1500-2000 onchain payments every day. For us, a world where bitcoin becomes de facto RBF by default, means that we would likely turn off the BIP21 model for onchain payments, instruct Bitcoin users to use Lightning or deposit onchain BTC to a custodial account that we have. This option is however not available for your typical BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear from other merchants or payment providers how they see this new behavior and how they would counteract it.On the efficacy of RBF, he said that current approach of assuming "manual" RBFing by power users ill UX thinking. He hopes in the future to have automatic fee-bumping implemented by user wallets, where a fee-bumping budget and a confirmation preference are pre-defined for all payments, and the fee-bumping logic "simply" enforcing the user policy, ideally based on historical mempool data. True fact: we don't have such logic in consumer wallets today. About the FX risk itself, this is far from being isolated from 0conf, as Lightning payments themselves might still have a time lapse between the issuance of invoices and the settlement of the HTLC at the payee endpoint. In fact this volatility concern is endured by anyone using Bitcoin regularly in interface with the fiats worlds, i.e everyone excepted the long-term store of wealth crowd. From a merchant perspective, effectively, the options to cover themselves against this risk are simple. One could take positions directly in traditional financial derivatives, like doing participants in international trades, though it would require an educated manpower on the merchant side. Or leveraging some stablecoins derivatives system, coming with its own technical complexity and social trust hazards. Another direction would be to clearly define the responsibility between merchants or users, on whom is the FX risk. If it's on users, they should be the one RBFing/CPFPing to increase the merchant address output, beyond the fact "dynamic pricing" would be a weird UX, it would require liveliness from the wallets until block confirmation (introducing here many requirements of a LN wallet). If it's on the merchants, they could be the ones CPFPing thanks to package relay, though it would come again with some engineering complexity and overhead blockspace cost (and the first version of package relay likely won't enable CPFP batching for concerns of potential bandwidth/CPU DoS).In the end, he said that a risk-based approach to decide on which payments are non-trivial to reverse is the easiest, taking account user experience and such. In the fiat world card payments have up to 5% chargebacks, whereas we in zero-conf bitcoin land we deal with "fewer than 1 in a million" accepted transactions successfully reversed. These days we have very few support issues related to bitcoin payments. The few that do come in are due to accidental RBF users venting frustration about waiting for their tx to confirm.
Updated on: 2023-06-16T00:48:08.555827+00:00