{"type":"rich","version":"1.0","author_name":"npub1d3yzrjfu44rf7wehmqcyantnssqc54hknanqh3df9yfj3qycvg7q9wv3vk","author_url":"https://nostr.ae/npub1d3yzrjfu44rf7wehmqcyantnssqc54hknanqh3df9yfj3qycvg7q9wv3vk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-19\n📝 Original message:Hi all,\n\nChiming in on this thread as I feel like the real dangers of RBF as default\npolicy aren't sufficiently elaborated here. It's not only about the\nzero-conf (I'll get to that) but there is an even bigger danger called the\namerican call option, which risks endangering the entirety of BIP21 \"Scan\nthis QR code with your wallet to buy this product\" model that I believe\nwe've all come to appreciate. Specifically, in a scenario with high\nvolatility and many transactions in the mempools (which is where RBF would\ncome in handy), a user can make a low-fee transaction and then wait for\nhours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves\nup, user can cancel his transaction and make a new - cheaper one. The\nbiggest risk in accepting bitcoin payments is in fact not zeroconf risk\n(it's actually quite easily managed), it's FX risk as the merchant must\ncommit to a certain BTCUSD rate ahead of time for a purchase. Over time\nsome transactions lose money to FX and others earn money - that evens out\nin the end. But if there is an _easily accessible in the wallet_ feature to\n\"cancel transaction\" that means it will eventually get systematically\nabused. A risk of X% loss on many payments that's easy to systematically\nabuse is more scary than a rare risk of losing 100% of one occasional\npayment. It's already possible to execute this form of abuse with opt-in\nRBF, which may lead to us at some point refusing those payments (even with\nconfirmation) or cumbersome UX to work around it, such as crediting the\nbitcoin to a custodial account.\n\nTo compare zeroconf risk with FX risk: I think we've had one incident in 8\nyears of operation where a user successfully fooled our server to accept a\npayment that in the end didn't confirm. To successfully fool (non-RBF)\nzeroconf one needs to have access to mining infrastructure and probability\nof success is the % of hash rate controlled. This is simply due to the fact\nthat the network currently won't propagage the replacement transaction to\nthe miner, which is what's being discussed here. American call option risk\nwould however be available to 100% of all users, needs nothing beyond the\nwallet app, and has no cost to the user - only upside.\n\nBitrefill currently processes 1500-2000 onchain payments every day. For us,\na world where bitcoin becomes de facto RBF by default, means that we would\nlikely turn off the BIP21 model for onchain payments, instruct Bitcoin\nusers to use Lightning or deposit onchain BTC to a custodial account that\nwe have.\nThis option is however not available for your typical\nBTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear\nfrom other merchants or payment providers how they see this new behavior\nand how they would counteract it.\n\nCurrently Lightning is somewhere around 15% of our total bitcoin payments.\nThis is very much not nothing, and all of us here want Lightning to grow,\nbut I think it warrants a serious discussion on whether we want Lightning\nadoption to go to 100% by means of disabling on-chain commerce. For me\npersonally it would be an easier discussion to have when Lightning is at\n80%+ of all bitcoin transactions. Currently far too many bitcoin users\nsimply don't have access to Lightning, and of those that do and hold their\nown keys Muun is the biggest wallet per our data, not least due to their\nease-of-use which is under threat per the OP. It's hard to assess how many\nusers would switch to Lightning in such a scenario, the communication\naround it would be hard. My intuition says that the majority of the current\n85% of bitcoin users that pay onchain would just not use bitcoin anymore,\nprobably shift to an alt. The benefits of Lightning are many and obvious,\nwe don't need to limit onchain to make Lightning more appealing. As an\nanecdote, we did experiment with defaulting to bech32 addresses some years\nback. The result was that simply users of the wallets that weren't able to\npay to bech32 didn't complete the purchase, no support ticket or anything,\njust \"it didn't work 🤷‍♂️\" and user moved on. We rolled it back, and later\nimplemented a wallet selector to allow modern wallets to pay to bech32\nwhile other wallets can pay to P2SH. This type of thing  is clunky, and\nrequires a certain level of scale to be able to do, we certainly wouldn't\nhave had the manpower for that when we were starting out. This why I'm\ncautious about introducing more such clunkiness vectors as they are\ncentralizing factors.\n\nI'm well aware of the reason for this policy being suggested and the\npotential pinning attack vector for LN and other smart contracts, but I\nthink these two risks/costs need to be weighed against eachother first and\nthoroughly discussed because the costs are non-trivial on both sides.\n\nSidenote: On the efficacy of RBF to \"unstuck\" stuck transactions\nAfter interacting with users during high-fee periods I've come to not\nappreciate RBF as a solution to that issue. Most users (80% or so) simply\ndon't have access to that functionality, because their wallet doesn't\nsupport it, or they use a custodial (exchange) wallet etc. Of those that\nhave the feature - only the power users understand how RBF works, and\nexplaining how to do RBF to a non-power-user is just too complex, for the\nsame reason why it's complex for wallets to make sensible non-power-user UI\naround it. Current equilibrium is that mostly only power users have access\nto RBF and they know how to handle it, so things are somewhat working. But\nrolling this out to the broad market is something else and would likely\ncause more confusion.\nCPFP is somewhat more viable but also not perfect as it would require lots\nof edge case code to handle abuse vectors: What if users abuse a generous\nCPFP policy to unstuck past transactions or consolidate large wallets. Best\nis for CPFP to be done on the wallet side, not the merchant side, but there\ntoo are the same UX issues as with RBF.\nIn the end a risk-based approach to decide on which payments are\nnon-trivial to reverse is the easiest, taking account user experience and\nsuch. Remember that in the fiat world card payments have up to 5%\nchargebacks, whereas we in zero-conf bitcoin land we deal with \"fewer than\n1 in a million\" accepted transactions successfully reversed. These days we\nhave very few support issues related to bitcoin payments. The few that do\ncome in are due to accidental RBF users venting frustration about waiting\nfor their tx to confirm.\n\"In theory, theory and practice are the same. In practice, they are not\"\n\nAll the best,\nSergej Kotliar\nCEO Bitrefill.com\n\n\n-- \n\nSergej Kotliar\n\nCEO\n\n\nTwitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\n\nwww.bitrefill.com\n\nTwitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003chttps://www.bitrefill.com/blog/\u003e | Angellist \u003chttps://angel.co/bitrefill\u003e\n\n\n-- \n\nSergej Kotliar\n\nCEO\n\n\nTwitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\n\nwww.bitrefill.com\n\nTwitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003chttps://www.bitrefill.com/blog/\u003e | Angellist \u003chttps://angel.co/bitrefill\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/cda936ac/attachment.html\u003e"}