path: root/71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43

Delivery-date: Fri, 29 Mar 2024 14:14:29 -0700
Received: from mail-yb1-f189.google.com ([209.85.219.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBLG6TSYAMGQES3JAMHA@googlegroups.com>)
	id 1rqJYS-0004IE-4c
	for bitcoindev@gnusha.org; Fri, 29 Mar 2024 14:14:29 -0700
Received: by mail-yb1-f189.google.com with SMTP id 3f1490d57ef6-ddaf2f115f2sf3380142276.3
        for <bitcoindev@gnusha.org>; Fri, 29 Mar 2024 14:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1711746862; x=1712351662; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=IDOzUmdc0+haDbzfYmjXqHiS2My3jHZJuUmfpLwlzNU=;
        b=HkVXfNh/OmCT7R+WFhC+MR0wypkAFycON5wWbLDpxUNKNEmu4YIczcxHpZ+HunGEJ7
         ZlPHwV1eW8QK737WG3pgB8nT9fKcJ532jVHfKpkExWduxQpbnjK42T1y495gfv+CvzlH
         6V84GGpbUigBQ11PTO4/0EIMfcEjnKxIPBeMfDxfuNSsIoufJAGohiGs93Q/psilK7dm
         nameJFCV6nfx+/mwpLCAzCGKqb0eqdhK3YZi4RIVeqxWdGeq6xkLkipiGwz/15zs9K9S
         LTjlJMUbhK+44Y2j8XNl0w0SBAwKuH38xNH1x7jpdLVwzGtpuwq+wnaz+uOm0b0UIwGT
         TNxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711746862; x=1712351662; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=IDOzUmdc0+haDbzfYmjXqHiS2My3jHZJuUmfpLwlzNU=;
        b=lWanR5h5QZsdEJuY3YElymmZc05ig9JJGrel4BYkd1P2ebWkKno8v4fRw71M6qFqmK
         scLfKV9QenwO1LOOrFt2+B1Ib0KsWKz3RK+wnUz0bUKrzJ2fbUanQAkoOk5qSgK3Ja3U
         7QN7iyh2faAd2fRrD8CSSeQyywZzUZK/HhaIMu4v0SyADEkZvbOx3ewz+chz+FeDTxkU
         +hp09Go5OIcpPbXUKNvG1GtSLJagnZy8o0KJRb5sp/LF67QCpScujr3o+Mb48HJ/Kkmc
         wolpNcPamFpB5HZZ8F1ZS5wuUY6DISP3w8JhcVGJcfkEmSdS8tk99sCBZvMeA9V7d5pe
         Tz0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711746862; x=1712351662;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=IDOzUmdc0+haDbzfYmjXqHiS2My3jHZJuUmfpLwlzNU=;
        b=NpDXJIVD0uvi8Qjm5e3Bbp8yMg1X/mf2Mf1AUsUm/VSanI9HI4Ei2hPlkBNALae1m3
         syMOCYb5ltJPuuyW8kOAVfXgHh0w9SSkO58WhXxuODKM65zbJoA0DlAt34rK+shdgmFA
         HXBKIh3S+Kjx3cm1cKMnmImI69RqFBlOsoX8du49rWI1uidwFOGRznQ7Nf+2mBr4ruFQ
         Sc3K+05Nej8M2aUVu972kjfbgnz+S8siNrs7YxSbJcGpEJ9X4ViPDISo0FFSBPlujIIl
         r4vtFYtXx67/qkpq6WKYVC5sS2VnrMLkiGUUbShlyNNlGhcrea0rXT8lJ0VSLzTniX9+
         qDIw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCURZat7a3yAsjmxwT3WTAriRYrTNsoQRGEW/K8PeQUTsWoUJk33RqjvpR0ja39Zhz5AgYSJJBQ1qr3Ld2W4BH4koj6TWzc=
X-Gm-Message-State: AOJu0Yz76sjBWt9qqVypEOleukeD/mOfzM2Hwt+bWa3JJjCwHEfejtx2
	WqHSKHGKVP7i55/SmhSRMWkbA1jBoW/ciRDX5odfpV+xVmSG5Umh
X-Google-Smtp-Source: AGHT+IGqY3rK8a3cmXkLyJj4BV2llMwvt0TqouOedb/dfWfmUfVqQktQnyfMP4Avii1yJlcCMeQlHQ==
X-Received: by 2002:a25:7184:0:b0:dc7:497e:cddf with SMTP id m126-20020a257184000000b00dc7497ecddfmr3021167ybc.33.1711746861649;
        Fri, 29 Mar 2024 14:14:21 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:ceca:0:b0:dc7:4417:ec4e with SMTP id x193-20020a25ceca000000b00dc74417ec4els646334ybe.1.-pod-prod-04-us;
 Fri, 29 Mar 2024 14:14:20 -0700 (PDT)
X-Received: by 2002:a81:9852:0:b0:614:4bfe:ae8f with SMTP id p79-20020a819852000000b006144bfeae8fmr480318ywg.4.1711746860372;
        Fri, 29 Mar 2024 14:14:20 -0700 (PDT)
Received: by 2002:a05:690c:102:b0:611:2a20:d0cc with SMTP id 00721157ae682-614558bcb36ms7b3;
        Fri, 29 Mar 2024 13:48:28 -0700 (PDT)
X-Received: by 2002:a05:6902:2311:b0:dd1:390a:51e8 with SMTP id do17-20020a056902231100b00dd1390a51e8mr999999ybb.10.1711745306828;
        Fri, 29 Mar 2024 13:48:26 -0700 (PDT)
Date: Fri, 29 Mar 2024 13:48:26 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f1868012-8ad2-44ba-b83c-b53d5892b8e6n@googlegroups.com>
In-Reply-To: <ZgXJOxBsePn9VAKh@petertodd.org>
References: <Zfg/6IZyA/iInyMx@petertodd.org>
 <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com>
 <ZgQZUOCc/dSjKMoL@petertodd.org>
 <CALZpt+GOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ@mail.gmail.com>
 <ZgV+Rk0m4azlbRZP@petertodd.org>
 <CALZpt+H2B1pSbqNa9phxZMxHX+30AiDqX7TgiRjH4rtirLwb9g@mail.gmail.com>
 <ZgXJOxBsePn9VAKh@petertodd.org>
Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_185920_1609690552.1711745306409"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_185920_1609690552.1711745306409
Content-Type: multipart/alternative; 
	boundary="----=_Part_185921_1455644758.1711745306409"

------=_Part_185921_1455644758.1711745306409
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Answering your latest 2 emails.

> I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical=20
that we
> should even fix it with a fork. SPV validation is very sketchy, and the=
=20
amount
> of work and money required to trigger CVE-2017-12842 is probably as or=20
more
> expensive than simply creating fake blocks.

> Sergio's RSK Bridge contract being vulnerable to it just indicates it was=
=20
a
> reckless design.

I don't think we shall disregard SPV validation yet in a world where we hav=
e
not really solved the scaling of Bitcoin payments for large range of user=
=20
segments
running on low-cost android mobile with limited validation ressources. On=
=20
the cost
of the attack, yes I think it's probably in the order of creating fake=20
blocks at current
difficulty adjustment.

On appreciating if a design is reckless or not, it's always good to do it=
=20
with a full-
fledged cost-based threat model in a comparative analysis w.r.t other=20
alternative
design in my experience.

> To be clear, in this particular case I had specific, insider, knowledge=
=20
that
> the relevant people had in fact seen my report and had already decided to
> dismiss it. This isn't a typical case where you're emailing some random=
=20
company
> and don't have any contacts. I personally knew prior to publication that=
=20
the
> relevant people had been given a fair chance to comment, had chosen not=
=20
to, and
> I would likely receive no response at all.

Sure thing, it's not a disclosure configuration where the reporter has no=
=20
out-of-band
redundant communication channels available with the software group of=20
maintainers.
I can only suggest that Bitcoin Core's `SECURITY.md` to be modified in the=
=20
sense to
give an acknowledgement of reception to finding reports with technical=20
proofs under
~72 hours. I'll let external observers from the community make their own=20
appreciation
on what this disclosure episode can say on the state of Bitcoin security=20
problem handling.

> I'm not going to say anything further on how I knew this, because I'm not=
=20
about
> to put up people who have been co-operating with me to the risk of=20
harassment
> from people like Harding and others; I'm not very popular right now with=
=20
many
> of the Bitcoin Core people working on the mempool code.

I think it's up to the maintainers or vendors of any piece of software to=
=20
justify why
they're disregarding sound technical reports coming from a security=20
researcher with
a credible and proven track record, especially when it's apparently for=20
hidden social
reasons.

There is also the option to disclose under pseudonym which I personally=20
already done
sometimes in the past. I can understand ones does not wish to do so far for=
=20
professional
reputation reasons.

> Anyway, I think the lesson learned here is it's probably not worth=20
bothering
> with a disclosure process at all for this type of issue. It just created =
a
> bunch of distracting political drama when simply publishing this exploit
> variation immediately probably would not have.

I've checked my own archive, on the Lightning-side and from my memory,
I can remember two far more serious issues than free-relay attacks which=20
were
quickly disclosed without a formal process over the past years:
- time-dilation attacks by myself [0]
- RBF-pinning on second-stage HTLC by the TheBlueMatt [1]

Both were conducted on a less than 7-days timeframe between private report
to select developers parties and public full-disclosure. With more=20
experience on
handling security issues since TDA initial report in 2019, I still think=20
it's good to
give 2-weeks to any vendors if they wish to engage in a mitigation process=
=20
(unless
special or emergency considerations).

In matters of ethical infosec and responsible disclosure, the process and=
=20
timeframe
actually followed should matter far more than the "who" of the reporter,=20
and her / his
"popularity" score on the social graph be completely disregarded - imho.

> If, for example, all Bitcoin nodes were somehow peered in a perfect ring,=
=20
with
> each node having exactly two peers, the sum total bandwidth of using 2
> conflicting proof-of-UTXOs (aka spending the UTXO), would be almost=20
identical
> to the sum total bandwidth of just using 1. The only additional bandwidth=
=20
would
> be the three to four nodes at the "edges" of the ring who saw the two=20
different
> conflicting versions.

> With higher #'s of peers, the total maximum extra bandwidth used=20
broadcasting
> conflicts increases proportionally.

Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth=
=20
used
for broadcasting conflicts increase proportionally. I think you can=20
dissociate among
transaction-announcement bandwidth (e.g INV(wtxid)) and=20
transaction-fetching=20
bandwidth (e.g GETDATA(wtxid)), you can re-fine the adversarial scenario to=
=20
have
highest DoS impact for each unique proof-of-UTXO. Like what is=20
bandwidth-cost
carried on by announcer and bandwidth-cost encumbered by the receiver.

Best,
Antoine


Le jeudi 28 mars 2024 =C3=A0 20:19:19 UTC, Peter Todd a =C3=A9crit :

> On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote:
> > > Modulo economic irrationalities with differently sized txs like the=
=20
> Rule
> > #6
> > > attack, the proof-of-UTXO is almost economically paid even when=20
> mempools
> > are
> > > partitioned because the bandwidth used by a given form of a=20
> transaction is
> > > limited to the % of peers that relay it. Eg if I broadcast TxA to 50%=
=20
> of
> > nodes,
> > > and TxB to the other 50%, both spending the same txout, the total=20
> cost/KB
> > used
> > > in total would exactly the same... except that nodes have more than o=
ne
> > peer.
> > > This acts as an amplification fator to attacks depending on the exact
> > topology
> > > as bandwidth is wasted in proportion to the # of peers txs need to be
> > broadcast
> > > too. Basically, a fan-out factor.
> >=20
> > > If the # of peers is reduced, the impact of this type of attack is al=
so
> > > reduced. Of course, a balance has to be maintained.
> >=20
> > Sure, proof-of-UTXO is imperfectly economically charged, however I thin=
k
> > you can
> > re-use the same proof-of-UTXO for each subset of Sybilled=20
> transaction-relay
> > peers.
>
> Of course you can. That's the whole point of my scenario above: you can=
=20
> re-use
> the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending,=
=20
> the
> tradeoff is less total nodes seeing each individual conflicting uses.
>
> If, for example, all Bitcoin nodes were somehow peered in a perfect ring,=
=20
> with
> each node having exactly two peers, the sum total bandwidth of using 2
> conflicting proof-of-UTXOs (aka spending the UTXO), would be almost=20
> identical
> to the sum total bandwidth of just using 1. The only additional bandwidth=
=20
> would
> be the three to four nodes at the "edges" of the ring who saw the two=20
> different
> conflicting versions.
>
> With higher #'s of peers, the total maximum extra bandwidth used=20
> broadcasting
> conflicts increases proportionally.
>
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com.

------=_Part_185921_1455644758.1711745306409
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,<div><br /></div><div>Answering your latest 2 emails.</div><div><b=
r /></div><div>&gt; I do not consider CVE-2017-12842 to be serious. Indeed,=
 I'm skeptical that we<br />&gt; should even fix it with a fork. SPV valida=
tion is very sketchy, and the amount<br />&gt; of work and money required t=
o trigger CVE-2017-12842 is probably as or more<br />&gt; expensive than si=
mply creating fake blocks.<br /><br />&gt; Sergio's RSK Bridge contract bei=
ng vulnerable to it just indicates it was a<br />&gt; reckless design.<br /=
></div><div><br /></div><div>I don't think we shall disregard SPV validatio=
n yet in a world where we have</div><div>not really solved the scaling of B=
itcoin payments for large range of user segments</div><div>running on low-c=
ost android mobile with limited validation ressources. On the cost</div><di=
v>of the attack, yes I think it's probably in the order of creating fake bl=
ocks at current</div><div>difficulty adjustment.</div><div><br /></div><div=
>On appreciating if a design is reckless or not, it's always good to do it =
with a full-</div><div>fledged cost-based threat model in a comparative ana=
lysis w.r.t other alternative</div><div>design in my experience.</div><div>=
<br /></div><div>&gt; To be clear, in this particular case I had specific, =
insider, knowledge that<br />&gt; the relevant people had in fact seen my r=
eport and had already decided to<br />&gt; dismiss it. This isn't a typical=
 case where you're emailing some random company<br />&gt; and don't have an=
y contacts. I personally knew prior to publication that the<br />&gt; relev=
ant people had been given a fair chance to comment, had chosen not to, and<=
br />&gt; I would likely receive no response at all.<br /></div><div><br />=
</div><div>Sure thing, it's not a disclosure configuration where the report=
er has no out-of-band</div><div>redundant communication channels available =
with the software group of maintainers.</div><div>I can only suggest that B=
itcoin Core's `SECURITY.md` to be modified in the sense to</div><div>give a=
n acknowledgement of reception to finding reports with technical proofs und=
er</div><div>~72 hours. I'll let external observers from the community make=
 their own appreciation</div><div>on what this disclosure episode can say o=
n the state of Bitcoin security problem handling.</div><div><br /></div><di=
v>&gt; I'm not going to say anything further on how I knew this, because I'=
m not about<br />&gt; to put up people who have been co-operating with me t=
o the risk of harassment<br />&gt; from people like Harding and others; I'm=
 not very popular right now with many<br />&gt; of the Bitcoin Core people =
working on the mempool code.<br /></div><div><br /></div><div>I think it's =
up to the maintainers or vendors of any piece of software to justify why</d=
iv><div>they're disregarding sound technical reports coming from a security=
 researcher with</div><div>a credible and proven track record, especially w=
hen it's apparently for hidden social</div><div>reasons.</div><div><br /></=
div><div>There is also the option to disclose under pseudonym which I perso=
nally already done</div><div>sometimes in the past. I can understand ones d=
oes not wish to do so far for professional</div><div>reputation reasons.</d=
iv><div><br /></div><div>&gt; Anyway, I think the lesson learned here is it=
's probably not worth bothering<br />&gt; with a disclosure process at all =
for this type of issue. It just created a<br />&gt; bunch of distracting po=
litical drama when simply publishing this exploit<br />&gt; variation immed=
iately probably would not have.<br /></div><div><br /></div><div>I've check=
ed my own archive, on the Lightning-side and from my memory,</div><div>I ca=
n remember two far more serious issues than free-relay attacks which were</=
div><div>quickly disclosed without a formal process over the past years:</d=
iv><div>- time-dilation attacks by myself [0]</div><div>- RBF-pinning on se=
cond-stage HTLC by the TheBlueMatt [1]</div><div><br /></div><div>Both were=
 conducted on a less than 7-days timeframe between private report</div><div=
>to select developers parties and public full-disclosure. With more experie=
nce on</div><div>handling security issues since TDA initial report in 2019,=
 I still think it's good to</div><div>give 2-weeks to any vendors if they w=
ish to engage in a mitigation process (unless</div><div>special or emergenc=
y considerations).</div><div><br /></div><div>In matters of ethical infosec=
 and responsible disclosure, the process and timeframe</div><div>actually f=
ollowed should matter far more than the "who" of the reporter, and her / hi=
s</div><div>"popularity" score on the social graph be completely disregarde=
d - imho.</div><div><br /></div><div>&gt; If, for example, all Bitcoin node=
s were somehow peered in a perfect ring, with<br />&gt; each node having ex=
actly two peers, the sum total bandwidth of using 2<br />&gt; conflicting p=
roof-of-UTXOs (aka spending the UTXO), would be almost identical<br />&gt; =
to the sum total bandwidth of just using 1. The only additional bandwidth w=
ould<br />&gt; be the three to four nodes at the "edges" of the ring who sa=
w the two different<br />&gt; conflicting versions.<br /><br />&gt; With hi=
gher #'s of peers, the total maximum extra bandwidth used broadcasting<br /=
>&gt; conflicts increases proportionally.<br /></div><div><br /></div><div>=
Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth=
 used</div><div>for broadcasting conflicts increase proportionally. I think=
 you can dissociate among</div><div>transaction-announcement bandwidth (e.g=
 INV(wtxid)) and transaction-fetching=C2=A0</div><div>bandwidth (e.g GETDAT=
A(wtxid)), you can re-fine the adversarial scenario to have</div><div>highe=
st DoS impact for each unique proof-of-UTXO. Like what is bandwidth-cost</d=
iv><div>carried on by announcer and bandwidth-cost encumbered by the receiv=
er.</div><div><br /></div><div>Best,</div><div>Antoine</div><div><br /><br =
/></div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">L=
e jeudi 28 mars 2024 =C3=A0 20:19:19 UTC, Peter Todd a =C3=A9crit=C2=A0:<br=
/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Thu, Mar 28,=
 2024 at 07:13:38PM +0000, Antoine Riard wrote:
<br>&gt; &gt; Modulo economic irrationalities with differently sized txs li=
ke the Rule
<br>&gt; #6
<br>&gt; &gt; attack, the proof-of-UTXO is almost economically paid even wh=
en mempools
<br>&gt; are
<br>&gt; &gt; partitioned because the bandwidth used by a given form of a t=
ransaction is
<br>&gt; &gt; limited to the % of peers that relay it. Eg if I broadcast Tx=
A to 50% of
<br>&gt; nodes,
<br>&gt; &gt; and TxB to the other 50%, both spending the same txout, the t=
otal cost/KB
<br>&gt; used
<br>&gt; &gt; in total would exactly the same... except that nodes have mor=
e than one
<br>&gt; peer.
<br>&gt; &gt; This acts as an amplification fator to attacks depending on t=
he exact
<br>&gt; topology
<br>&gt; &gt; as bandwidth is wasted in proportion to the # of peers txs ne=
ed to be
<br>&gt; broadcast
<br>&gt; &gt; too. Basically, a fan-out factor.
<br>&gt;=20
<br>&gt; &gt; If the # of peers is reduced, the impact of this type of atta=
ck is also
<br>&gt; &gt; reduced. Of course, a balance has to be maintained.
<br>&gt;=20
<br>&gt; Sure, proof-of-UTXO is imperfectly economically charged, however I=
 think
<br>&gt; you can
<br>&gt; re-use the same proof-of-UTXO for each subset of Sybilled transact=
ion-relay
<br>&gt; peers.
<br>
<br>Of course you can. That&#39;s the whole point of my scenario above: you=
 can re-use
<br>the proof-of-UTXO. But since nodes&#39; mempools enforce anti-doublespe=
nding, the
<br>tradeoff is less total nodes seeing each individual conflicting uses.
<br>
<br>If, for example, all Bitcoin nodes were somehow peered in a perfect rin=
g, with
<br>each node having exactly two peers, the sum total bandwidth of using 2
<br>conflicting proof-of-UTXOs (aka spending the UTXO), would be almost ide=
ntical
<br>to the sum total bandwidth of just using 1. The only additional bandwid=
th would
<br>be the three to four nodes at the &quot;edges&quot; of the ring who saw=
 the two different
<br>conflicting versions.
<br>
<br>With higher #&#39;s of peers, the total maximum extra bandwidth used br=
oadcasting
<br>conflicts increases proportionally.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" target=3D"_blank" rel=3D"nofollow" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1711830543925000&amp;usg=3DAOvVaw2=
t6YOtPhZYJ42gICoxho60">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1711830543925000&amp;usg=3DAOvVaw0KdSQs5-jwYo=
8i5YvmgZ9b">petertodd.org</a>
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com</a>.=
<br />

------=_Part_185921_1455644758.1711745306409--

------=_Part_185920_1609690552.1711745306409--