{"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-20\n📝 Original message:\u003e There is a long list of countermeasures that can be built to reduce these\n\u003e attacks, but to be frank we've only implemented a small subset of these\nand\n\u003e not had any issues, so even a lower level of security is more than fine\n\u003e today to have basically zero abuse. If issues arise we could implement\nmore\n\u003e of the countermeasures as appropriate to the abuse that has happened in\nthe\n\u003e wild.\n\n\u003eFrom reading one of your other mail, apparently 60% of Bitrefill payments\nare non-rbfable on-chain transactions and as such fine for zeroconf. What\nI'm wondering is, in case of a wide majority of the full-nodes supporting\nfull-rbf, if any incoming transaction traffic could be risk-managed\nwell-enough thanks to some additional countermeasures to be\nzeroconf-acceptable ?\n\nWe can be technically creative here. One could think of some overlay\nmonitoring between zeroconf merchants, where mempooldiffs are exchanged to\nobserve if any acceptance candidate is double-spent inside some other\nparticipant's mempool. Of course, the reconciliation rate would need to be\npretty high to still ensure an \"instant payment\" UX, though the bandwidth\noverhead should be okay as we assume full-node enterprise hosts. I don't\nthink such functionality would be used by any full-node, it might leverage\np2p extensions but it would be some differentiated services on top of the\nusual messages. This is just an idea, and the concrete 0conf acceptance\nflow problem needs to be better specified.\n\n\u003e Fundamentally, my view is that all the UX problems related to RBF alone\nare\n\u003e sufficient of an issue to hold off on rolling out these upgrades for the\n\u003e foreseeable future and think of other ways of solving the pinning issue\nand\n\u003e other issues w the current policy. Might be that it's just a fundamental\n\u003e goal conflict that different people want different behavior but I remain\n\u003e optimistic for creative solutions from both sides. UX issues are soft as\n\u003e opposed to theoretical attack vectors which are hard and binary, we need\n\u003e find a way to weigh \"even though it doesn't happen it can theoretically be\n\u003e hacked\" against \"many users find it confusing and stressful\" which is not\na\n\u003e trivial assessment to do.\n\nSeriously, solving the pinning issues for contracting protocols already\nbusy few of the most brilliant bitcoin developers almost full-time. If we\nhad straightforward and backward compatible with all classes of current\nBitcoin applications, we would go for it. Of course, it doesn't mean we\nshould close the problem of space exploration, and if someone can come up\nwith solutions offering equivalent trade-offs, I'm all to listen. This is\nstill an open question if we would have to allow a subset of transactions\nto be full-rbf, to fully achieve the semantics of v3 transactions, or at\nleast if we would like to protect currently open Lightning channels. Hard\nproblems here.\n\nWhile I'm hearing the uncertainty of an easy assessment weighting between\nfavoring UX issues or solving hard theoretical attacks, those latter\nconcerns I've been serious enough among the Lightning development community\nto take it as one of the top engineering issues among all those last years.\n\u003eFrom my experience, pentesting in a \"black-box\" fashion of some subset of\nLN vulnerabilities, they turn out as really practical after a few days of\nhacking if you know where to hit. Moreover, it should be underscored that\nthe attacker incentive model between targeting a 0conf merchant like\nBitrefill and a sizable Lightning infrastructure is a bit different. On one\nside, you will pocket free gift cards that are likely traceable to\nreal-world identities, or cancellable by calling out the issuers. On the\nother side, you get a stack of free satoshis, easily fungible among all\nother coins. As such, we might foresee far more exploitations against LN,\nonce the network has caught up in terms of volume and stakes to compare\nwith the most advanced Defi smart contract platforms in the wider\ncryptocurrencies ecosystem, attracting today sophisticated attackers. Or at\nleast, I'm worried by such an outcome playing out for LN if we're too slow\non rolling out mitigations...\n\nAll that said, from my perspective upgrading mempool policy doesn't seem\nincompatible with a parallel effort to improve the UX problems of RBF, by\nautomatic fee-bumping logic in a transparent way for the end-users. Like\nyou said, we should be all optimistic on creative solutions, and\ncommunicate better between merchants and devs on the problem space.\n\nLooking forward to having more interactions on these topics in the future!\n\nBest,\nAntoine\n\nLe jeu. 20 oct. 2022 à 10:12, Sergej Kotliar \u003csergej at bitrefill.com\u003e a\nécrit :\n\n\u003e\n\u003e\n\u003e On Thu, 20 Oct 2022 at 03:37, Antoine Riard \u003cantoine.riard at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Hi Sergej,\n\u003e\u003e\n\u003e\u003e Thanks for the insightful posting, especially highlighting the FX risk\n\u003e\u003e which was far from being evident on my side!\n\u003e\u003e\n\u003e\u003e I don't know in details the security architecture of Bitrefill zeroconf\n\u003e\u003e acceptance system, though from what I suppose there is at least a set of\n\u003e\u003e full-nodes well-connected across the p2p network, on top of which some\n\u003e\u003e mempools reconciliation is exercised\n\u003e\u003e and zeroconf candidate sanitize against. While I believe this is a\n\u003e\u003e far-more robust deployment against double-spend attempts, there is still\n\u003e\u003e the ability for a sophisticated attacker to \"taint\" miner mempools, and\n\u003e\u003e from then partition judiciously the transaction-relay network to game such\n\u003e\u003e distributed mempool monitoring system. There is also the possibility of an\n\u003e\u003e attacker using some \"divide-and-conquer\" transaction broadcast algorithm to\n\u003e\u003e map Bitrefill monitoring point, though as far as I'm aware such algorithm\n\u003e\u003e has not been discussed. I agree with all of that, easier said than done.\n\u003e\u003e\n\u003e\n\u003e There is a long list of countermeasures that can be built to reduce these\n\u003e attacks, but to be frank we've only implemented a small subset of these and\n\u003e not had any issues, so even a lower level of security is more than fine\n\u003e today to have basically zero abuse. If issues arise we could implement more\n\u003e of the countermeasures as appropriate to the abuse that has happened in the\n\u003e wild.\n\u003e\n\u003e\n\u003e\u003e On the efficacy of RBF, I understand the current approach of assuming\n\u003e\u003e \"manual\" RBFing by power users ill UX thinking. I hope in the future to\n\u003e\u003e have automatic fee-bumping implemented by user wallets, where a fee-bumping\n\u003e\u003e budget and a confirmation preference are pre-defined for all payments, and\n\u003e\u003e the fee-bumping logic \"simply\" enforcing the user policy, ideally based on\n\u003e\u003e historical mempool data. True fact: we don't have such logic in consumer\n\u003e\u003e wallets today.\n\u003e\u003e\n\u003e\n\u003e In deed. And the vast majority of bitcoin users don't even have access to\n\u003e any RBF functionality today, so we're not even seeing gradual development\n\u003e of these things yet. I think this fact needs to be taken into account when\n\u003e designing breaking changes to bitcoin policy. Had these things been in\n\u003e place and widely used the conversation would have been much easier.\n\u003e\n\u003e Fundamentally, my view is that all the UX problems related to RBF alone\n\u003e are sufficient of an issue to hold off on rolling out these upgrades for\n\u003e the foreseeable future and think of other ways of solving the pinning issue\n\u003e and other issues w the current policy. Might be that it's just a\n\u003e fundamental goal conflict that different people want different behavior but\n\u003e I remain optimistic for creative solutions from both sides. UX issues are\n\u003e soft as opposed to theoretical attack vectors which are hard and binary, we\n\u003e need find a way to weigh \"even though it doesn't happen it can\n\u003e theoretically be hacked\" against \"many users find it confusing and\n\u003e stressful\" which is not a trivial assessment to do.\n\u003e\n\u003e All that said, I learn to converge that as a community we would be better\n\u003e\u003e off to weigh deeper the risks/costs between 0confs applications and\n\u003e\u003e contracting protocols in light of full-rbf.\n\u003e\u003e\n\u003e\n\u003e In deed. And as you wrote in a different message, I agree that it's\n\u003e unfortunate that there isn't more interaction between the mailing list and\n\u003e services and companies using this stuff day-to-day. Not that it's anyone's\n\u003e fault in particular, let's try from all sides to find more ways to create\n\u003e more interaction on these topics. I've pinged a few colleagues that work on\n\u003e payments in the space and hope they will chime in more in this forum!\n\u003e\n\u003e All the best,\n\u003e Sergej\n\u003e\n\u003e\n\u003e\u003e Le mer. 19 oct. 2022 à 10:33, Sergej Kotliar via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e\u003e\n\u003e\u003e\u003e Hi all,\n\u003e\u003e\u003e\n\u003e\u003e\u003e Chiming in on this thread as I feel like the real dangers of RBF as\n\u003e\u003e\u003e default policy aren't sufficiently elaborated here. It's not only about the\n\u003e\u003e\u003e zero-conf (I'll get to that) but there is an even bigger danger called the\n\u003e\u003e\u003e american call option, which risks endangering the entirety of BIP21 \"Scan\n\u003e\u003e\u003e this QR code with your wallet to buy this product\" model that I believe\n\u003e\u003e\u003e we've all come to appreciate. Specifically, in a scenario with high\n\u003e\u003e\u003e volatility and many transactions in the mempools (which is where RBF would\n\u003e\u003e\u003e come in handy), a user can make a low-fee transaction and then wait for\n\u003e\u003e\u003e hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves\n\u003e\u003e\u003e up, user can cancel his transaction and make a new - cheaper one. The\n\u003e\u003e\u003e biggest risk in accepting bitcoin payments is in fact not zeroconf risk\n\u003e\u003e\u003e (it's actually quite easily managed), it's FX risk as the merchant must\n\u003e\u003e\u003e commit to a certain BTCUSD rate ahead of time for a purchase. Over time\n\u003e\u003e\u003e some transactions lose money to FX and others earn money - that evens out\n\u003e\u003e\u003e in the end. But if there is an _easily accessible in the wallet_ feature to\n\u003e\u003e\u003e \"cancel transaction\" that means it will eventually get systematically\n\u003e\u003e\u003e abused. A risk of X% loss on many payments that's easy to systematically\n\u003e\u003e\u003e abuse is more scary than a rare risk of losing 100% of one occasional\n\u003e\u003e\u003e payment. It's already possible to execute this form of abuse with opt-in\n\u003e\u003e\u003e RBF, which may lead to us at some point refusing those payments (even with\n\u003e\u003e\u003e confirmation) or cumbersome UX to work around it, such as crediting the\n\u003e\u003e\u003e bitcoin to a custodial account.\n\u003e\u003e\u003e\n\u003e\u003e\u003e To compare zeroconf risk with FX risk: I think we've had one incident in\n\u003e\u003e\u003e 8 years of operation where a user successfully fooled our server to accept\n\u003e\u003e\u003e a payment that in the end didn't confirm. To successfully fool (non-RBF)\n\u003e\u003e\u003e zeroconf one needs to have access to mining infrastructure and probability\n\u003e\u003e\u003e of success is the % of hash rate controlled. This is simply due to the fact\n\u003e\u003e\u003e that the network currently won't propagage the replacement transaction to\n\u003e\u003e\u003e the miner, which is what's being discussed here. American call option risk\n\u003e\u003e\u003e would however be available to 100% of all users, needs nothing beyond the\n\u003e\u003e\u003e wallet app, and has no cost to the user - only upside.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Bitrefill currently processes 1500-2000 onchain payments every day. For\n\u003e\u003e\u003e us, a world where bitcoin becomes de facto RBF by default, means that we\n\u003e\u003e\u003e would likely turn off the BIP21 model for onchain payments, instruct\n\u003e\u003e\u003e Bitcoin users to use Lightning or deposit onchain BTC to a custodial\n\u003e\u003e\u003e account that we have.\n\u003e\u003e\u003e This option is however not available for your typical\n\u003e\u003e\u003e BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear\n\u003e\u003e\u003e from other merchants or payment providers how they see this new behavior\n\u003e\u003e\u003e and how they would counteract it.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Currently Lightning is somewhere around 15% of our total bitcoin\n\u003e\u003e\u003e payments. This is very much not nothing, and all of us here want Lightning\n\u003e\u003e\u003e to grow, but I think it warrants a serious discussion on whether we want\n\u003e\u003e\u003e Lightning adoption to go to 100% by means of disabling on-chain commerce.\n\u003e\u003e\u003e For me personally it would be an easier discussion to have when Lightning\n\u003e\u003e\u003e is at 80%+ of all bitcoin transactions. Currently far too many bitcoin\n\u003e\u003e\u003e users simply don't have access to Lightning, and of those that do and hold\n\u003e\u003e\u003e their own keys Muun is the biggest wallet per our data, not least due to\n\u003e\u003e\u003e their ease-of-use which is under threat per the OP. It's hard to assess how\n\u003e\u003e\u003e many users would switch to Lightning in such a scenario, the communication\n\u003e\u003e\u003e around it would be hard. My intuition says that the majority of the current\n\u003e\u003e\u003e 85% of bitcoin users that pay onchain would just not use bitcoin anymore,\n\u003e\u003e\u003e probably shift to an alt. The benefits of Lightning are many and obvious,\n\u003e\u003e\u003e we don't need to limit onchain to make Lightning more appealing. As an\n\u003e\u003e\u003e anecdote, we did experiment with defaulting to bech32 addresses some years\n\u003e\u003e\u003e back. The result was that simply users of the wallets that weren't able to\n\u003e\u003e\u003e pay to bech32 didn't complete the purchase, no support ticket or anything,\n\u003e\u003e\u003e just \"it didn't work 🤷‍♂️\" and user moved on. We rolled it back, and later\n\u003e\u003e\u003e implemented a wallet selector to allow modern wallets to pay to bech32\n\u003e\u003e\u003e while other wallets can pay to P2SH. This type of thing  is clunky, and\n\u003e\u003e\u003e requires a certain level of scale to be able to do, we certainly wouldn't\n\u003e\u003e\u003e have had the manpower for that when we were starting out. This why I'm\n\u003e\u003e\u003e cautious about introducing more such clunkiness vectors as they are\n\u003e\u003e\u003e centralizing factors.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I'm well aware of the reason for this policy being suggested and the\n\u003e\u003e\u003e potential pinning attack vector for LN and other smart contracts, but I\n\u003e\u003e\u003e think these two risks/costs need to be weighed against eachother first and\n\u003e\u003e\u003e thoroughly discussed because the costs are non-trivial on both sides.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sidenote: On the efficacy of RBF to \"unstuck\" stuck transactions\n\u003e\u003e\u003e After interacting with users during high-fee periods I've come to not\n\u003e\u003e\u003e appreciate RBF as a solution to that issue. Most users (80% or so) simply\n\u003e\u003e\u003e don't have access to that functionality, because their wallet doesn't\n\u003e\u003e\u003e support it, or they use a custodial (exchange) wallet etc. Of those that\n\u003e\u003e\u003e have the feature - only the power users understand how RBF works, and\n\u003e\u003e\u003e explaining how to do RBF to a non-power-user is just too complex, for the\n\u003e\u003e\u003e same reason why it's complex for wallets to make sensible non-power-user UI\n\u003e\u003e\u003e around it. Current equilibrium is that mostly only power users have access\n\u003e\u003e\u003e to RBF and they know how to handle it, so things are somewhat working. But\n\u003e\u003e\u003e rolling this out to the broad market is something else and would likely\n\u003e\u003e\u003e cause more confusion.\n\u003e\u003e\u003e CPFP is somewhat more viable but also not perfect as it would require\n\u003e\u003e\u003e lots of edge case code to handle abuse vectors: What if users abuse a\n\u003e\u003e\u003e generous CPFP policy to unstuck past transactions or consolidate large\n\u003e\u003e\u003e wallets. Best is for CPFP to be done on the wallet side, not the merchant\n\u003e\u003e\u003e side, but there too are the same UX issues as with RBF.\n\u003e\u003e\u003e In the end a risk-based approach to decide on which payments are\n\u003e\u003e\u003e non-trivial to reverse is the easiest, taking account user experience and\n\u003e\u003e\u003e such. Remember that in the fiat world card payments have up to 5%\n\u003e\u003e\u003e chargebacks, whereas we in zero-conf bitcoin land we deal with \"fewer than\n\u003e\u003e\u003e 1 in a million\" accepted transactions successfully reversed. These days we\n\u003e\u003e\u003e have very few support issues related to bitcoin payments. The few that do\n\u003e\u003e\u003e come in are due to accidental RBF users venting frustration about waiting\n\u003e\u003e\u003e for their tx to confirm.\n\u003e\u003e\u003e \"In theory, theory and practice are the same. In practice, they are not\"\n\u003e\u003e\u003e\n\u003e\u003e\u003e All the best,\n\u003e\u003e\u003e Sergej Kotliar\n\u003e\u003e\u003e CEO Bitrefill.com\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sergej Kotliar\n\u003e\u003e\u003e\n\u003e\u003e\u003e CEO\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Twitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e www.bitrefill.com\n\u003e\u003e\u003e\n\u003e\u003e\u003e Twitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003e\u003e\u003e \u003chttps://www.bitrefill.com/blog/\u003e | Angellist\n\u003e\u003e\u003e \u003chttps://angel.co/bitrefill\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e\n\u003e\u003e\u003e Sergej Kotliar\n\u003e\u003e\u003e\n\u003e\u003e\u003e CEO\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Twitter: @ziggamon \u003chttps://twitter.com/ziggamon\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e www.bitrefill.com\n\u003e\u003e\u003e\n\u003e\u003e\u003e Twitter \u003chttps://www.twitter.com/bitrefill\u003e | Blog\n\u003e\u003e\u003e \u003chttps://www.bitrefill.com/blog/\u003e | Angellist\n\u003e\u003e\u003e \u003chttps://angel.co/bitrefill\u003e\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e\n\u003e\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221020/70f554fa/attachment-0001.html\u003e"}