path: root/3a/86c6f226dd80bc7d210bd3d84c8fb207142101

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--