{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-19\n📝 Original message:Hi Sergej,\n\nThanks for the insightful posting, especially highlighting the FX risk\nwhich was far from being evident on my side!\n\nI don't know in details the security architecture of Bitrefill zeroconf\nacceptance system, though from what I suppose there is at least a set of\nfull-nodes well-connected across the p2p network, on top of which some\nmempools reconciliation is exercised\nand zeroconf candidate sanitize against. While I believe this is a far-more\nrobust deployment against double-spend attempts, there is still the ability\nfor a sophisticated attacker to \"taint\" miner mempools, and from then\npartition judiciously the transaction-relay network to game such\ndistributed mempool monitoring system. There is also the possibility of an\nattacker using some \"divide-and-conquer\" transaction broadcast algorithm to\nmap Bitrefill monitoring point, though as far as I'm aware such algorithm\nhas not been discussed. I agree with all of that, easier said than done.\n\n(Which let me think that such distributed mempool monitoring system should\nbe provide some enhanced security even in a full-rbf world, that they would\nrequire far more resources than the average node from the p2p network as a\nwhole might be a counter-argument for their social acceptance, however I'm\nalso thinking that a robust Lightning infrastructure of the future might\nrequire multiple mempool/transaction-relay endpoints, at least to reduce\ncross-layer mapping links, though conversation for another day...).\n\nAbout the FX risk itself, this is far from being isolated from 0conf, as\nLightning payments themselves might still have a time lapse between the\nissuance of invoices and the settlement of the HTLC at the payee endpoint.\nIn fact this volatility concern is endured by anyone using Bitcoin\nregularly in interface with the fiats worlds, i.e everyone excepted the\nlong-term store of wealth crowd. From a merchant perspective, effectively,\nthe options to cover themselves against this risk are simple. One could\ntake positions directly in traditional financial derivatives, like doing\nparticipants in international trades, though it would require an educated\nmanpower on the merchant side. Or leveraging some stablecoins derivatives\nsystem, coming with its own technical complexity and social trust hazards.\nAnother direction would be to clearly define the responsibility between\nmerchants or users, on whom is the FX risk. If it's on users, they should\nbe the one RBFing/CPFPing to increase the merchant address output, beyond\nthe fact \"dynamic pricing\" would be a weird UX, it would require liveliness\nfrom the wallets until block confirmation (introducing here many\nrequirements of a LN wallet). If it's on the merchants, they could be the\nones CPFPing thanks to package relay, though it would come again with some\nengineering complexity and overhead blockspace cost (and the first version\nof package relay likely won't enable CPFP batching for concerns of\npotential bandwidth/CPU DoS).\n\nOn the efficacy of RBF, I understand the current approach of assuming\n\"manual\" RBFing by power users ill UX thinking. I hope in the future to\nhave automatic fee-bumping implemented by user wallets, where a fee-bumping\nbudget and a confirmation preference are pre-defined for all payments, and\nthe fee-bumping logic \"simply\" enforcing the user policy, ideally based on\nhistorical mempool data. True fact: we don't have such logic in consumer\nwallets today. Or at least only rudimentary in the backend of LN\nimplementations, and only for time-sensitive on-chain claims for now (or at\nleast speaking for LDK). If we take the history of browsers as a\ncomparison, while we might be out of the Lynx-style phase of wallets, we\nmight still be more in the late Netscape kind of thing than something like\nChrome today. In other words, there are many directions for improvements\nfor users' wallets.\n\nAll that said, I learn to converge that as a community we would be better\noff to weigh deeper the risks/costs between 0confs applications and\ncontracting protocols in light of full-rbf.\n\nBest,\nAntoine\n\nLe mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Hi all,\n\u003e\n\u003e Chiming in on this thread as I feel like the real dangers of RBF as\n\u003e default policy aren't sufficiently elaborated here. It's not only about the\n\u003e zero-conf (I'll get to that) but there is an even bigger danger called the\n\u003e american call option, which risks endangering the entirety of BIP21 \"Scan\n\u003e this QR code with your wallet to buy this product\" model that I believe\n\u003e we've all come to appreciate. Specifically, in a scenario with high\n\u003e volatility and many transactions in the mempools (which is where RBF would\n\u003e come in handy), a user can make a low-fee transaction and then wait for\n\u003e hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves\n\u003e up, user can cancel his transaction and make a new - cheaper one. The\n\u003e biggest risk in accepting bitcoin payments is in fact not zeroconf risk\n\u003e (it's actually quite easily managed), it's FX risk as the merchant must\n\u003e commit to a certain BTCUSD rate ahead of time for a purchase. Over time\n\u003e some transactions lose money to FX and others earn money - that evens out\n\u003e in the end. But if there is an _easily accessible in the wallet_ feature to\n\u003e \"cancel transaction\" that means it will eventually get systematically\n\u003e abused. A risk of X% loss on many payments that's easy to systematically\n\u003e abuse is more scary than a rare risk of losing 100% of one occasional\n\u003e payment. It's already possible to execute this form of abuse with opt-in\n\u003e RBF, which may lead to us at some point refusing those payments (even with\n\u003e confirmation) or cumbersome UX to work around it, such as crediting the\n\u003e bitcoin to a custodial account.\n\u003e\n\u003e To compare zeroconf risk with FX risk: I think we've had one incident in 8\n\u003e years of operation where a user successfully fooled our server to accept a\n\u003e payment that in the end didn't confirm. To successfully fool (non-RBF)\n\u003e zeroconf one needs to have access to mining infrastructure and probability\n\u003e of success is the % of hash rate controlled. This is simply due to the fact\n\u003e that the network currently won't propagage the replacement transaction to\n\u003e the miner, which is what's being discussed here. American call option risk\n\u003e would however be available to 100% of all users, needs nothing beyond the\n\u003e wallet app, and has no cost to the user - only upside.\n\u003e\n\u003e Bitrefill currently processes 1500-2000 onchain payments every day. For\n\u003e us, a world where bitcoin becomes de facto RBF by default, means that we\n\u003e would likely turn off the BIP21 model for onchain payments, instruct\n\u003e Bitcoin users to use Lightning or deposit onchain BTC to a custodial\n\u003e account that we have.\n\u003e This option is however not available for your typical\n\u003e BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear\n\u003e from other merchants or payment providers how they see this new behavior\n\u003e and how they would counteract it.\n\u003e\n\u003e Currently Lightning is somewhere around 15% of our total bitcoin payments.\n\u003e This is very much not nothing, and all of us here want Lightning to grow,\n\u003e but I think it warrants a serious discussion on whether we want Lightning\n\u003e adoption to go to 100% by means of disabling on-chain commerce. For me\n\u003e personally it would be an easier discussion to have when Lightning is at\n\u003e 80%+ of all bitcoin transactions. Currently far too many bitcoin users\n\u003e simply don't have access to Lightning, and of those that do and hold their\n\u003e own keys Muun is the biggest wallet per our data, not least due to their\n\u003e ease-of-use which is under threat per the OP. It's hard to assess how many\n\u003e users would switch to Lightning in such a scenario, the communication\n\u003e around it would be hard. My intuition says that the majority of the current\n\u003e 85% of bitcoin users that pay onchain would just not use bitcoin anymore,\n\u003e probably shift to an alt. The benefits of Lightning are many and obvious,\n\u003e we don't need to limit onchain to make Lightning more appealing. As an\n\u003e anecdote, we did experiment with defaulting to bech32 addresses some years\n\u003e back. The result was that simply users of the wallets that weren't able to\n\u003e pay to bech32 didn't complete the purchase, no support ticket or anything,\n\u003e just \"it didn't work 🤷‍♂️\" and user moved on. We rolled it back, and later\n\u003e implemented a wallet selector to allow modern wallets to pay to bech32\n\u003e while other wallets can pay to P2SH. This type of thing  is clunky, and\n\u003e requires a certain level of scale to be able to do, we certainly wouldn't\n\u003e have had the manpower for that when we were starting out. This why I'm\n\u003e cautious about introducing more such clunkiness vectors as they are\n\u003e centralizing factors.\n\u003e\n\u003e I'm well aware of the reason for this policy being suggested and the\n\u003e potential pinning attack vector for LN and other smart contracts, but I\n\u003e think these two risks/costs need to be weighed against eachother first and\n\u003e thoroughly discussed because the costs are non-trivial on both sides.\n\u003e\n\u003e Sidenote: On the efficacy of RBF to \"unstuck\" stuck transactions\n\u003e After interacting with users during high-fee periods I've come to not\n\u003e appreciate RBF as a solution to that issue. Most users (80% or so) simply\n\u003e don't have access to that functionality, because their wallet doesn't\n\u003e support it, or they use a custodial (exchange) wallet etc. Of those that\n\u003e have the feature - only the power users understand how RBF works, and\n\u003e explaining how to do RBF to a non-power-user is just too complex, for the\n\u003e same reason why it's complex for wallets to make sensible non-power-user UI\n\u003e around it. Current equilibrium is that mostly only power users have access\n\u003e to RBF and they know how to handle it, so things are somewhat working. But\n\u003e rolling this out to the broad market is something else and would likely\n\u003e cause more confusion.\n\u003e CPFP is somewhat more viable but also not perfect as it would require lots\n\u003e of edge case code to handle abuse vectors: What if users abuse a generous\n\u003e CPFP policy to unstuck past transactions or consolidate large wallets. Best\n\u003e is for CPFP to be done on the wallet side, not the merchant side, but there\n\u003e too are the same UX issues as with RBF.\n\u003e In the end a risk-based approach to decide on which payments are\n\u003e non-trivial to reverse is the easiest, taking account user experience and\n\u003e such. Remember that in the fiat world card payments have up to 5%\n\u003e chargebacks, whereas we in zero-conf bitcoin land we deal with \"fewer than\n\u003e 1 in a million\" accepted transactions successfully reversed. These days we\n\u003e have very few support issues related to bitcoin payments. The few that do\n\u003e come in are due to accidental RBF users venting frustration about waiting\n\u003e for their tx to confirm.\n\u003e \"In theory, theory and practice are the same. In practice, they are not\"\n\u003e\n\u003e All the best,\n\u003e Sergej Kotliar\n\u003e CEO Bitrefill.com\n\u003e\n\u003e\n\u003e --\n\u003e\n\u003e Sergej Kotliar\n\u003e\n\u003e CEO\n\u003e\n\u003e\n\u003e Twitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\u003e\n\u003e\n\u003e www.bitrefill.com\n\u003e\n\u003e Twitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003e \u003chttps://www.bitrefill.com/blog/\u003e | Angellist \u003chttps://angel.co/bitrefill\u003e\n\u003e\n\u003e\n\u003e --\n\u003e\n\u003e Sergej Kotliar\n\u003e\n\u003e CEO\n\u003e\n\u003e\n\u003e Twitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\u003e\n\u003e\n\u003e www.bitrefill.com\n\u003e\n\u003e Twitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003e \u003chttps://www.bitrefill.com/blog/\u003e | Angellist \u003chttps://angel.co/bitrefill\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221019/5d40738b/attachment-0001.html\u003e"}