diff options
author | John Carvalho <john@synonym.to> | 2022-12-05 15:19:20 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-12-05 15:19:35 +0000 |
commit | db0135ade40ef4362fea40db033675d7c5148a95 (patch) | |
tree | f3a28878f0123eacd4ae1e727cc80008370266b6 | |
parent | dbca51707e51b4de9c1f9f6bf2bbee32aadf5ef2 (diff) | |
download | pi-bitcoindev-db0135ade40ef4362fea40db033675d7c5148a95.tar.gz pi-bitcoindev-db0135ade40ef4362fea40db033675d7c5148a95.zip |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus)
-rw-r--r-- | 3a/86c6f226dd80bc7d210bd3d84c8fb207142101 | 454 |
1 files changed, 454 insertions, 0 deletions
diff --git a/3a/86c6f226dd80bc7d210bd3d84c8fb207142101 b/3a/86c6f226dd80bc7d210bd3d84c8fb207142101 new file mode 100644 index 000000000..2f93fd01c --- /dev/null +++ b/3a/86c6f226dd80bc7d210bd3d84c8fb207142101 @@ -0,0 +1,454 @@ +Return-Path: <john@synonym.to> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 0209DC002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Dec 2022 15:19:35 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id D0ADE4010E + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Dec 2022 15:19:34 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D0ADE4010E +Authentication-Results: smtp2.osuosl.org; + dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com + header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256 + header.s=20210112 header.b=RDQ5xS4A +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -1.887 +X-Spam-Level: +X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_NONE=0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id AzXJu3vZ9LKh + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Dec 2022 15:19:33 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org DA9264010C +Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com + [IPv6:2607:f8b0:4864:20::d32]) + by smtp2.osuosl.org (Postfix) with ESMTPS id DA9264010C + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Dec 2022 15:19:32 +0000 (UTC) +Received: by mail-io1-xd32.google.com with SMTP id i83so1336906ioa.11 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 05 Dec 2022 07:19:32 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=synonym-to.20210112.gappssmtp.com; s=20210112; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :from:to:cc:subject:date:message-id:reply-to; + bh=fgeYNNCEyuYIySpWhFPzKVdCKcv8dKZ7VE6mT77JTws=; + b=RDQ5xS4AoxG5vGPtigQLpT2zNV5AHYrK4b9/68B8mX4fTxlP1RbxFYKaXWDvn2YvEN + AcSdVDwaXyTgzftRa2QJQKywlPPpE876G46jyL9JpgUmltSuac2jqIOFG5FeVML7frsM + 5m6IgTPlsCP2COeeI3i5TQJbeOQK1AwKKhQeab6RasAYI5sDXT6mQgcZHMGffPwqSSkP + c10xZRVlVYfuOutlGVF1SdIgzpW8Zc6sGkK6ABUPF8kKgLXNKbrsq6DGo2mxCCC6PBdS + wSaVhoZaYIQlZIRmm8GtavAEf4guYwlzKJPwnQ0NvcmoPMq2POhY8vlBBO9Wyp/UTSu2 + StLA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=to:subject:message-id:date:from:in-reply-to:references:mime-version + :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; + bh=fgeYNNCEyuYIySpWhFPzKVdCKcv8dKZ7VE6mT77JTws=; + b=itPHMC2m3jM+bSsOCC+TEMlEJ4zqbrDLPYDPKEg9NolY5Lp6NyAaeNMCQWyqOuz+2c + Wq5CaGD5dkzDebjdO7cGEB4Rizqzg9DqvbP1T6lM+tLvYXUHyELTmjIOe8LNF7qBPVEp + MDFzkIhG2hLQKuO1EZiM2dulkspzUbzqCPfoOoCJs20uHbdVvm920Q+UgIy0NPPPjSnW + KB31f1Q/610y8X13nY1694FrOpIWIZmmcR3ou0qIlbAd9ZPea+pex45s62VPFDK8Oaca + qIT99rFpIzP2z6TVsR8OWs0v23kCIEIrljLIqMAFY+Dqy4osCFpP2ZNpHG5yTO8HMjwE + RMfg== +X-Gm-Message-State: ANoB5pkUvymXcByQi38CJq5CR2K4UR4cVSfO+DncQRQuXGpWSQVdS2VL + hv/5u2J6Jn9atMrDn6F0ra8b1iUteRjTY9e1MLi5dFvRXk0DaiAS +X-Google-Smtp-Source: AA0mqf4szAwaIJ9K1d+7eMaTH6+VxZw4778NQKG07WL86eOt/ekkuOcVE81MctSRe4z+/kzmIaIb3hotMLias1mj1HI= +X-Received: by 2002:a05:6638:f11:b0:38a:e47:3098 with SMTP id + h17-20020a0566380f1100b0038a0e473098mr9634845jas.190.1670253571388; Mon, 05 + Dec 2022 07:19:31 -0800 (PST) +MIME-Version: 1.0 +References: <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <mailman.48662.1670246787.956.bitcoin-dev@lists.linuxfoundation.org> +From: John Carvalho <john@synonym.to> +Date: Mon, 5 Dec 2022 15:19:20 +0000 +Message-ID: <CAHTn92wri-edhivrtqZCoEzAPEmwZFap12mM4yzxgp77O-+JYA@mail.gmail.com> +To: Bitcoin-Dev <bitcoin-dev@lists.linuxfoundation.org>, angus@toaster.cc +Content-Type: multipart/alternative; boundary="000000000000cecdf305ef16367e" +X-Mailman-Approved-At: Mon, 05 Dec 2022 18:57:59 +0000 +Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate + danger (angus) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 05 Dec 2022 15:19:35 -0000 + +--000000000000cecdf305ef16367e +Content-Type: text/plain; charset="UTF-8" + +> +> The perception seems to be that Core adding the full RBF option is +> increasing the risk to zero-conf users, but I'm not convinced that that is +> the case. + + +If this "perception" were not true, RBF & full-RBF would not be necessary +at all. Think about it. + +It's always been the risk of getting double-spent out of hundreds or +> thousands of bitcoins that's worth seriously worrying about, which is much +> more the kind of attack a determined attacker is able to carry out. + + +The risk exposure to merchants providing zero-conf acceptance as a service +is finite, capped by their risk-tolerance, and capped by the current block +exposure. Merchants cap their exposure to be an amount worth less than the +value of this service. + +It is highly inefficient and difficult for a miner to pull off an +industry-wide attack across diverse merchants to capture the current +maximum exposure in any given block, not to mention the enormous surface +area of legal risk across jurisdictions... + +I don't think zero-conf opponents properly grasp that the risk exposure is +exact and perfectly, trustlessly manageable. I would like the opportunity +to spec the methods Bitrefill, Synonym, and most such merchants, use to +make it standard practice, as it is cheaper for merchants and more +convenient to Bitcoin consumers when merchants behave this way. + +As has been pointed out by may others before, full RBF is aligned with +> miner (and user) economic incentives + + +This is a theory, not a fact. I can refute this theory by pointing out +several aspects: + +1. RBF is actually a fee-minimization feature that allows users to game +the system to spend the *least* amount in fees that correlates to their +time-preference. Miners earn less when fees can be minimized (obviously). +This feature also comes at an expense (albeit small) to nodes providing +replacement service and propagation. + +2. Miners care about max fees per block, not slightly increased fees on a +minority % of incidentally replaced txns when they happen to need it. They +want the most txns for the highest price per *block*. In order to qualify +for zero-conf acceptance, merchants require that the fee rate match or +exceed an amount that makes the txn likely to be included in the very next +block. This creates a priority competition from users with high +time-preference. This creates not only more fees for miners, but more txns +from more people using the chain for commerce. This is evidenced by stats +provided recently to this mailing list, but here are more numbers from +Bitrefill: +https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1332823282 + +3. Miners ultimately want what users want, as more users = more txns = more +fees = higher BTC price. For all of Bitcoin's history, more users have +wanted zero-conf than replacements. This is evidenced by first-seen policy +thriving for years without disruption (until engineers actively disrupted +it, using fallible theories as justification). This is also evidenced by +the UASF battle where miners capitulated to providing the type of blocks +that users demanded, to avoid uncertainty. + +4. A replaceable mempool is inherently less valuable than a first-seen +policy mempool in that Bitcoin is ultimately a ledger for a *payments* +system where people are trying to pay and be paid with certainty. A +full-RBF system would result in more real-world doublespends to existing +merchants and p2p commerce, as it is impossible to fully teach all aspects +of Bitcoin dynamics to users, particularly when they have enjoyed many +years of first-seen behavior as status quo. + +Zero-conf and first-seen policies are clearly more +incentive-compatible than RBF outright for these reasons. + +The long-term 'what to do about it' is to use Lightning if you want fast +> payments with risk-free instant settlement + + +Many zero-conf proponents work on the bleeding edge of supporting +Lightning, including myself. Lightning is not risk-free and the base layer +should not be assuming it as a primary dependency for commercial payments. +The UX and complexity of supporting Lightning is still considerable, +adoption is still very low, and there are many unsolved attack vectors and +risks that remain untested due to Lightning's low prevalence. + +Further, zero-conf is also useful as a tool in improving Lightning +onboarding, rebalancing, splicing, and UX overall. Bitcoin second-layers +are only as good as the base layer, everything else is a tradeoff. + +Bitcoin core 24 with the full RBF option is already out in the wild at +> around 5%+ of running nodes and growing, so it's too late to kill it. + + +This is pure speculation. If Bitcoin Core publishes an update without the +mistakenly-rushed feature, the mempoolfullrbf movement is likely to die on +the vine as users opt into the latest versions more and more, as evidenced +by all older versions decreasing in usage over time. The incentive to run +old versions, just to be able to force non-RBF txns to be treated as RBF, +is lower than the incentive and likelihood of updating. Frankly, such an +incentive is mostly obscure, vindictive, and perverse, IMO. + +We should remove the mempoolfullrbf feature immediately from Bitcoin Core +distributions, as requested here: +https://github.com/bitcoin/bitcoin/pull/26525 + +This mistake demands correction, and no one has provided a +rational beneficial argument so far for breaking the user space and +disrupting mempool harmony. + +If you would like further arguments and refutations of full-RBF, please +read all of the posts in my PR thread: +https://github.com/bitcoin/bitcoin/pull/26525 + +Thank you, + +-- +John Carvalho +CEO, Synonym.to <http://synonym.to/> + + + +Date: Mon, 05 Dec 2022 12:21:44 +0000 +> From: angus <angus@toaster.cc> +> To: Daniel Lipshitz <daniel@gap600.com>, Bitcoin Protocol Discussion +> <bitcoin-dev@lists.linuxfoundation.org> +> Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate +> danger +> Message-ID: +> +> <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_CstCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=@toaster.cc> +> +> Content-Type: text/plain; charset="utf-8" +> +> Core adding full RBF is a change of node policy that may be highly +> inconvenient for zero-conf users, but there has always been and will always +> be a risk of a double-spend for anyone that treats zero-confirmation +> transactions as settled. It's literally in the name - this transaction has +> zero confirmations and no guarantee it'll make it into a block, and so has +> not yet settled. +> +> The perception seems to be that Core adding the full RBF option is +> increasing the risk to zero-conf users, but I'm not convinced that that is +> the case - someone wanting to double-spend attack you isn't going to be +> bothered to do so over a few thousand sats (unless they can do it thousands +> of times), and losing a few thousand sats to a double-spend isn't the +> biggest deal. +> +> It's always been the risk of getting double-spent out of hundreds or +> thousands of bitcoins that's worth seriously worrying about, which is much +> more the kind of attack a determined attacker is able to carry out. Such a +> determined attacker is much more likely to attempt and succeed at a sybil +> attack, or directly colluding with a miner. So your zero-conf risk +> increases non-linearly as the amount of bitcoin being transacted grows. +> (caveat: this paragraph is opinion). +> +> There does, however, seem to be a legitimate business for providing +> insurance/risk management for people that are willing to accept the +> zero-conf risk - it is pretty similar to accepting credit cards with a +> chargeback risk or any payment card with a capture risk, though there's +> no-one to mediate a dispute. On-chain is final. +> +> But what doesn't make any sense is trying to avoid Bitcoin Core and nodes +> from adopting a full RBF policy to try to protect this use case. As has +> been pointed out by may others before, full RBF is aligned with miner (and +> user) economic incentives and is a node policy, not consensus, so you can't +> even tell which nodes are doing it nor can you prevent them from doing so. +> Second, Bitcoin core 24 with the full RBF option is already out in the wild +> at around 5%+ of running nodes and growing, so it's too late to kill it. +> +> So my point is that relying on node policy as part of your protection for +> zero-conf transaction acceptance is fragile, and should not be relied upon. +> The protocol rules have always tacitly allowed double-spending before a +> confirmation, and it has always been clear that there's no consensus on +> which transactions have occurred until they have in a block and have +> at-least one confirmation. +> +> The long-term 'what to do about it' is to use Lightning if you want fast +> payments with risk-free instant settlement, or as above, accept the +> zero-conf risk and cover yourself with an insurance premium (e.g. a margin +> on transactions that goes into an insurance fund, and limiting max +> transaction amount so you're not exposed to uncoverable losses if you do +> get double-spend attacked) +> +> Angus +> + +--000000000000cecdf305ef16367e +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = +0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The perc= +eption seems to be that Core adding the full RBF option is increasing the r= +isk to zero-conf users, but I'm not convinced that that is the case.</b= +lockquote><div dir=3D"ltr"><br></div><div>If this "perception" we= +re not true, RBF & full-RBF would not be necessary at all. Think about = +it.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= +1ex">It's always been the risk of getting double-spent out of hundreds = +or thousands of bitcoins that's worth seriously worrying about, which i= +s much more the kind of attack a determined attacker is able to carry out.= +=C2=A0</blockquote><div><br></div><div>The risk exposure to merchants provi= +ding zero-conf acceptance as a service is finite, capped by their risk-tole= +rance, and capped by the current block exposure. Merchants cap their exposu= +re to be an amount worth less than the value of this service.</div><div><br= +></div><div>It is highly inefficient and difficult for a miner to pull off = +an industry-wide attack across diverse merchants to capture the current max= +imum exposure in any given block, not to mention the enormous surface area = +of legal risk across jurisdictions...<br></div><div><br></div><div>I don= +9;t think zero-conf opponents properly grasp that the risk exposure is exac= +t and perfectly, trustlessly manageable. I would like the opportunity to sp= +ec the methods Bitrefill, Synonym, and most such merchants, use to make it = +standard practice, as it is cheaper for merchants and more convenient to Bi= +tcoin consumers when merchants behave this way.=C2=A0</div><div><br></div><= +blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= +eft:1px solid rgb(204,204,204);padding-left:1ex">As has been pointed out by= + may others before, full RBF is aligned with miner (and user) economic ince= +ntives</blockquote><div><br></div><div>This is a theory, not a fact. I can = +refute this theory by pointing out several aspects:<br><br></div><div>1.=C2= +=A0 RBF is actually a fee-minimization feature that allows users to game th= +e system to spend the *least* amount in fees that correlates to their time-= +preference. Miners earn less when fees can be minimized (obviously). This f= +eature also comes at an expense (albeit small) to nodes providing replaceme= +nt service and propagation.<br><br></div><div>2. Miners care about max fees= + per block, not slightly=C2=A0increased fees on a minority % of incidentall= +y replaced txns when they happen to need it. They want the most txns for th= +e highest price per *block*. In order to qualify for zero-conf acceptance, = +merchants require that the fee rate match or exceed an amount that makes th= +e txn likely to be included in the very next block. This creates a priority= + competition from users with high time-preference. This creates not only mo= +re fees for miners, but more txns from more people using the chain for comm= +erce. This is evidenced by stats provided recently to this mailing list, bu= +t here are more numbers from Bitrefill:=C2=A0<a href=3D"https://github.com/= +bitcoin/bitcoin/pull/26525#issuecomment-1332823282">https://github.com/bitc= +oin/bitcoin/pull/26525#issuecomment-1332823282</a><br><br></div><div>3. Min= +ers ultimately want what users want, as more users=C2=A0=3D more txns =3D m= +ore fees =3D higher BTC price. For all of Bitcoin's history, more users= + have wanted zero-conf than replacements. This is evidenced by first-seen p= +olicy thriving for years without disruption (until engineers actively disru= +pted it, using fallible theories as justification). This is also evidenced = +by the UASF battle where miners capitulated to providing the type of blocks= + that users demanded, to avoid uncertainty.</div><div><br></div><div>4. A r= +eplaceable=C2=A0mempool is inherently less valuable than a first-seen polic= +y mempool in that Bitcoin is ultimately a ledger for a *payments* system wh= +ere people are trying to pay and be paid with certainty. A full-RBF system = +would result in more real-world doublespends to existing merchants and p2p = +commerce, as it is impossible to fully teach all aspects of Bitcoin dynamic= +s to users, particularly when they have enjoyed many years of first-seen be= +havior as status quo.</div><div><br></div><div>Zero-conf and first-seen pol= +icies are clearly more incentive-compatible=C2=A0than RBF outright for thes= +e reasons.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= +g-left:1ex">The long-term 'what to do about it' is to use Lightning= + if you want fast payments with risk-free instant settlement</blockquote><d= +iv><br></div><div>Many zero-conf proponents work on the bleeding edge of su= +pporting Lightning, including myself. Lightning is not risk-free and the ba= +se layer should not be assuming it as a primary dependency for commercial p= +ayments. The UX and complexity of supporting Lightning is still considerabl= +e, adoption=C2=A0is still very low, and there are many unsolved attack vect= +ors and risks that remain untested due to Lightning's low prevalence.= +=C2=A0</div><div><br></div><div>Further, zero-conf is also useful as a tool= + in improving Lightning onboarding, rebalancing, splicing, and UX overall. = +Bitcoin second-layers are only as good as the base layer, everything else i= +s a tradeoff.</div><div><br></div><blockquote class=3D"gmail_quote" style= +=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= +-left:1ex">Bitcoin core 24 with the full RBF option is already out in the w= +ild at around 5%+ of running nodes and growing, so it's too late to kil= +l it.</blockquote><div><br></div><div>This is pure speculation. If Bitcoin = +Core publishes an update without the mistakenly-rushed feature, the mempool= +fullrbf=C2=A0movement is likely to die on the vine as users opt into the la= +test versions more and more,=C2=A0as evidenced by all older=C2=A0versions d= +ecreasing in usage over time. The incentive to run old versions, just to be= + able to force non-RBF txns to be treated as RBF, is lower than the incenti= +ve and likelihood of updating. Frankly, such an incentive is mostly obscure= +, vindictive, and perverse, IMO.</div><div><br></div><div>We should remove = +the mempoolfullrbf feature immediately from Bitcoin Core distributions, as = +requested here:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/265= +25">https://github.com/bitcoin/bitcoin/pull/26525</a><br></div><div><br></d= +iv><div>This mistake demands correction, and no one has provided a rational= +=C2=A0beneficial argument so far for breaking the user space and disrupting= + mempool harmony.</div><div><br></div><div>If you would like further argume= +nts and refutations of full-RBF, please read all of the posts in my PR thre= +ad:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/26525">https://= +github.com/bitcoin/bitcoin/pull/26525</a></div><div><br></div><div>Thank yo= +u,</div><div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"g= +mail_signature"><div dir=3D"ltr"><span style=3D"color:rgb(34,34,34)">--</sp= +an><br style=3D"color:rgb(34,34,34)"><div dir=3D"ltr" style=3D"color:rgb(34= +,34,34)"><div dir=3D"ltr">John Carvalho</div><div dir=3D"ltr">CEO,=C2=A0<a = +href=3D"http://synonym.to/" style=3D"color:rgb(17,85,204)" target=3D"_blank= +">Synonym.to</a><br><div><br></div></div></div></div></div></div><br></div>= +<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= +argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left= +:1ex">Date: Mon, 05 Dec 2022 12:21:44 +0000<br> +From: angus <<a href=3D"mailto:angus@toaster.cc" target=3D"_blank">angus= +@toaster.cc</a>><br> +To: Daniel Lipshitz <<a href=3D"mailto:daniel@gap600.com" target=3D"_bla= +nk">daniel@gap600.com</a>>, Bitcoin Protocol Discussion<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo= +undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g= +t;<br> +Subject: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 danger<br> +Message-ID:<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 <-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_Cs= +tCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=3D@toaster= +.cc><br> +<br> +Content-Type: text/plain; charset=3D"utf-8"<br> +<br> +Core adding full RBF is a change of node policy that may be highly inconven= +ient for zero-conf users, but there has always been and will always be a ri= +sk of a double-spend for anyone that treats zero-confirmation transactions = +as settled. It's literally in the name - this transaction has zero conf= +irmations and no guarantee it'll make it into a block, and so has not y= +et settled.<br><br> +The perception seems to be that Core adding the full RBF option is increasi= +ng the risk to zero-conf users, but I'm not convinced that that is the = +case - someone wanting to double-spend attack you isn't going to be bot= +hered to do so over a few thousand sats (unless they can do it thousands of= + times), and losing a few thousand sats to a double-spend isn't the big= +gest deal.<br> +<br> +It's always been the risk of getting double-spent out of hundreds or th= +ousands of bitcoins that's worth seriously worrying about, which is muc= +h more the kind of attack a determined attacker is able to carry out. Such = +a determined attacker is much more likely to attempt and succeed at a sybil= + attack, or directly colluding with a miner. So your zero-conf risk increas= +es non-linearly as the amount of bitcoin being transacted grows. (caveat: t= +his paragraph is opinion).<br> +<br> +There does, however, seem to be a legitimate business for providing insuran= +ce/risk management for people that are willing to accept the zero-conf risk= + - it is pretty similar to accepting credit cards with a chargeback risk or= + any payment card with a capture risk, though there's no-one to mediate= + a dispute. On-chain is final.<br> +<br> +But what doesn't make any sense is trying to avoid Bitcoin Core and nod= +es from adopting a full RBF policy to try to protect this use case. As has = +been pointed out by may others before, full RBF is aligned with miner (and = +user) economic incentives and is a node policy, not consensus, so you can&#= +39;t even tell which nodes are doing it nor can you prevent them from doing= + so. Second, Bitcoin core 24 with the full RBF option is already out in the= + wild at around 5%+ of running nodes and growing, so it's too late to k= +ill it.<br><br> +So my point is that relying on node policy as part of your protection for z= +ero-conf transaction acceptance is fragile, and should not be relied upon. = +The protocol rules have always tacitly allowed double-spending before a con= +firmation, and it has always been clear that there's no consensus on wh= +ich transactions have occurred until they have in a block and have at-least= + one confirmation.<br> +<br> +The long-term 'what to do about it' is to use Lightning if you want= + fast payments with risk-free instant settlement, or as above, accept the z= +ero-conf risk and cover yourself with an insurance premium (e.g. a margin o= +n transactions that goes into an insurance fund, and limiting max transacti= +on amount so you're not exposed to uncoverable losses if you do get dou= +ble-spend attacked)<br><br> +Angus<br> +</blockquote></div></div> + +--000000000000cecdf305ef16367e-- + |