{"type":"rich","version":"1.0","author_name":"npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","author_url":"https://nostr.ae/npub1qg5r4lja0e34twn6psh49qlrzj0k28dtxxw0k4fag6sarqprfm2s7nqm4r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-12-05\n📝 Original message:\u003e\n\u003e The perception seems to be that Core adding the full RBF option is\n\u003e increasing the risk to zero-conf users, but I'm not convinced that that is\n\u003e the case.\n\n\nIf this \"perception\" were not true, RBF \u0026 full-RBF would not be necessary\nat all. Think about it.\n\nIt's always been the risk of getting double-spent out of hundreds or\n\u003e thousands of bitcoins that's worth seriously worrying about, which is much\n\u003e more the kind of attack a determined attacker is able to carry out.\n\n\nThe risk exposure to merchants providing zero-conf acceptance as a service\nis finite, capped by their risk-tolerance, and capped by the current block\nexposure. Merchants cap their exposure to be an amount worth less than the\nvalue of this service.\n\nIt is highly inefficient and difficult for a miner to pull off an\nindustry-wide attack across diverse merchants to capture the current\nmaximum exposure in any given block, not to mention the enormous surface\narea of legal risk across jurisdictions...\n\nI don't think zero-conf opponents properly grasp that the risk exposure is\nexact and perfectly, trustlessly manageable. I would like the opportunity\nto spec the methods Bitrefill, Synonym, and most such merchants, use to\nmake it standard practice, as it is cheaper for merchants and more\nconvenient to Bitcoin consumers when merchants behave this way.\n\nAs has been pointed out by may others before, full RBF is aligned with\n\u003e miner (and user) economic incentives\n\n\nThis is a theory, not a fact. I can refute this theory by pointing out\nseveral aspects:\n\n1.  RBF is actually a fee-minimization feature that allows users to game\nthe system to spend the *least* amount in fees that correlates to their\ntime-preference. Miners earn less when fees can be minimized (obviously).\nThis feature also comes at an expense (albeit small) to nodes providing\nreplacement service and propagation.\n\n2. Miners care about max fees per block, not slightly increased fees on a\nminority % of incidentally replaced txns when they happen to need it. They\nwant the most txns for the highest price per *block*. In order to qualify\nfor zero-conf acceptance, merchants require that the fee rate match or\nexceed an amount that makes the txn likely to be included in the very next\nblock. This creates a priority competition from users with high\ntime-preference. This creates not only more fees for miners, but more txns\nfrom more people using the chain for commerce. This is evidenced by stats\nprovided recently to this mailing list, but here are more numbers from\nBitrefill:\nhttps://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282\n\n3. Miners ultimately want what users want, as more users = more txns = more\nfees = higher BTC price. For all of Bitcoin's history, more users have\nwanted zero-conf than replacements. This is evidenced by first-seen policy\nthriving for years without disruption (until engineers actively disrupted\nit, using fallible theories as justification). This is also evidenced by\nthe UASF battle where miners capitulated to providing the type of blocks\nthat users demanded, to avoid uncertainty.\n\n4. A replaceable mempool is inherently less valuable than a first-seen\npolicy mempool in that Bitcoin is ultimately a ledger for a *payments*\nsystem where people are trying to pay and be paid with certainty. A\nfull-RBF system would result in more real-world doublespends to existing\nmerchants and p2p commerce, as it is impossible to fully teach all aspects\nof Bitcoin dynamics to users, particularly when they have enjoyed many\nyears of first-seen behavior as status quo.\n\nZero-conf and first-seen policies are clearly more\nincentive-compatible than RBF outright for these reasons.\n\nThe long-term 'what to do about it' is to use Lightning if you want fast\n\u003e payments with risk-free instant settlement\n\n\nMany zero-conf proponents work on the bleeding edge of supporting\nLightning, including myself. Lightning is not risk-free and the base layer\nshould not be assuming it as a primary dependency for commercial payments.\nThe UX and complexity of supporting Lightning is still considerable,\nadoption is still very low, and there are many unsolved attack vectors and\nrisks that remain untested due to Lightning's low prevalence.\n\nFurther, zero-conf is also useful as a tool in improving Lightning\nonboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers\nare only as good as the base layer, everything else is a tradeoff.\n\nBitcoin core 24 with the full RBF option is already out in the wild at\n\u003e around 5%+ of running nodes and growing, so it's too late to kill it.\n\n\nThis is pure speculation. If Bitcoin Core publishes an update without the\nmistakenly-rushed feature, the mempoolfullrbf movement is likely to die on\nthe vine as users opt into the latest versions more and more, as evidenced\nby all older versions decreasing in usage over time. The incentive to run\nold versions, just to be able to force non-RBF txns to be treated as RBF,\nis lower than the incentive and likelihood of updating. Frankly, such an\nincentive is mostly obscure, vindictive, and perverse, IMO.\n\nWe should remove the mempoolfullrbf feature immediately from Bitcoin Core\ndistributions, as requested here:\nhttps://github.com/bitcoin/bitcoin/pull/26525\n\nThis mistake demands correction, and no one has provided a\nrational beneficial argument so far for breaking the user space and\ndisrupting mempool harmony.\n\nIf you would like further arguments and refutations of full-RBF, please\nread all of the posts in my PR thread:\nhttps://github.com/bitcoin/bitcoin/pull/26525\n\nThank you,\n\n--\nJohn Carvalho\nCEO, Synonym.to \u003chttp://synonym.to/\u003e\n\n\n\nDate: Mon, 05 Dec 2022 12:21:44 +0000\n\u003e From: angus \u003cangus at toaster.cc\u003e\n\u003e To: Daniel Lipshitz \u003cdaniel at gap600.com\u003e, Bitcoin Protocol Discussion\n\u003e         \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate\n\u003e         danger\n\u003e Message-ID:\n\u003e\n\u003e \u003c-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc\u003e\n\u003e\n\u003e Content-Type: text/plain; charset=\"utf-8\"\n\u003e\n\u003e Core adding full RBF is a change of node policy that may be highly\n\u003e inconvenient for zero-conf users, but there has always been and will always\n\u003e be a risk of a double-spend for anyone that treats zero-confirmation\n\u003e transactions as settled. It's literally in the name - this transaction has\n\u003e zero confirmations and no guarantee it'll make it into a block, and so has\n\u003e not yet settled.\n\u003e\n\u003e The perception seems to be that Core adding the full RBF option is\n\u003e increasing the risk to zero-conf users, but I'm not convinced that that is\n\u003e the case - someone wanting to double-spend attack you isn't going to be\n\u003e bothered to do so over a few thousand sats (unless they can do it thousands\n\u003e of times), and losing a few thousand sats to a double-spend isn't the\n\u003e biggest deal.\n\u003e\n\u003e It's always been the risk of getting double-spent out of hundreds or\n\u003e thousands of bitcoins that's worth seriously worrying about, which is much\n\u003e more the kind of attack a determined attacker is able to carry out. Such a\n\u003e determined attacker is much more likely to attempt and succeed at a sybil\n\u003e attack, or directly colluding with a miner. So your zero-conf risk\n\u003e increases non-linearly as the amount of bitcoin being transacted grows.\n\u003e (caveat: this paragraph is opinion).\n\u003e\n\u003e There does, however, seem to be a legitimate business for providing\n\u003e insurance/risk management for people that are willing to accept the\n\u003e zero-conf risk - it is pretty similar to accepting credit cards with a\n\u003e chargeback risk or any payment card with a capture risk, though there's\n\u003e no-one to mediate a dispute. On-chain is final.\n\u003e\n\u003e But what doesn't make any sense is trying to avoid Bitcoin Core and nodes\n\u003e from adopting a full RBF policy to try to protect this use case. As has\n\u003e been pointed out by may others before, full RBF is aligned with miner (and\n\u003e user) economic incentives and is a node policy, not consensus, so you can't\n\u003e even tell which nodes are doing it nor can you prevent them from doing so.\n\u003e Second, Bitcoin core 24 with the full RBF option is already out in the wild\n\u003e at around 5%+ of running nodes and growing, so it's too late to kill it.\n\u003e\n\u003e So my point is that relying on node policy as part of your protection for\n\u003e zero-conf transaction acceptance is fragile, and should not be relied upon.\n\u003e The protocol rules have always tacitly allowed double-spending before a\n\u003e confirmation, and it has always been clear that there's no consensus on\n\u003e which transactions have occurred until they have in a block and have\n\u003e at-least one confirmation.\n\u003e\n\u003e The long-term 'what to do about it' is to use Lightning if you want fast\n\u003e payments with risk-free instant settlement, or as above, accept the\n\u003e zero-conf risk and cover yourself with an insurance premium (e.g. a margin\n\u003e on transactions that goes into an insurance fund, and limiting max\n\u003e transaction amount so you're not exposed to uncoverable losses if you do\n\u003e get double-spend attacked)\n\u003e\n\u003e Angus\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/f3d67ada/attachment-0001.html\u003e"}