summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohn Carvalho <john@synonym.to>2022-12-05 15:19:20 +0000
committerbitcoindev <bitcoindev@gnusha.org>2022-12-05 15:19:35 +0000
commitdb0135ade40ef4362fea40db033675d7c5148a95 (patch)
treef3a28878f0123eacd4ae1e727cc80008370266b6
parentdbca51707e51b4de9c1f9f6bf2bbee32aadf5ef2 (diff)
downloadpi-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/86c6f226dd80bc7d210bd3d84c8fb207142101454
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&#39;m not convinced that that is the case.</b=
+lockquote><div dir=3D"ltr"><br></div><div>If this &quot;perception&quot; we=
+re not true, RBF &amp; 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&#39;s always been the risk of getting double-spent out of hundreds =
+or thousands of bitcoins that&#39;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&#3=
+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&#39;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 &#39;what to do about it&#39; 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&#39;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&#39;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 &lt;<a href=3D"mailto:angus@toaster.cc" target=3D"_blank">angus=
+@toaster.cc</a>&gt;<br>
+To: Daniel Lipshitz &lt;<a href=3D"mailto:daniel@gap600.com" target=3D"_bla=
+nk">daniel@gap600.com</a>&gt;, Bitcoin Protocol Discussion<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<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 &lt;-C_sX7ApYy_2MgXfl7e1ONddIi9gtET5jV4MTl_F_Cs=
+tCvTuV0vTFfazF7tKBd53o6QbZ1xygayPIaCVjDyV-9yklnfk_t0IH23rw2LtqKQ=3D@toaster=
+.cc&gt;<br>
+<br>
+Content-Type: text/plain; charset=3D&quot;utf-8&quot;<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&#39;s literally in the name - this transaction has zero conf=
+irmations and no guarantee it&#39;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&#39;m not convinced that that is the =
+case - someone wanting to double-spend attack you isn&#39;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&#39;t the big=
+gest deal.<br>
+<br>
+It&#39;s always been the risk of getting double-spent out of hundreds or th=
+ousands of bitcoins that&#39;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&#39;s no-one to mediate=
+ a dispute. On-chain is final.<br>
+<br>
+But what doesn&#39;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&#39;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&#39;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 &#39;what to do about it&#39; 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&#39;re not exposed to uncoverable losses if you do get dou=
+ble-spend attacked)<br><br>
+Angus<br>
+</blockquote></div></div>
+
+--000000000000cecdf305ef16367e--
+