summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAntoine Riard <antoine.riard@gmail.com>2024-03-29 13:48:26 -0700
committerbitcoindev <bitcoindev@googlegroups.com>2024-03-29 14:14:29 -0700
commit522a0d3a2e59113e0c1eac9fc26d883cc7176eff (patch)
tree5700df68540c6d1233370e650ec9962a14d70f65
parentd2692b2f85ff4365aa5e0392e820a68fe3bd8a96 (diff)
downloadpi-bitcoindev-522a0d3a2e59113e0c1eac9fc26d883cc7176eff.tar.gz
pi-bitcoindev-522a0d3a2e59113e0c1eac9fc26d883cc7176eff.zip
Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
-rw-r--r--71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43511
1 files changed, 511 insertions, 0 deletions
diff --git a/71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43 b/71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43
new file mode 100644
index 000000000..98033a4c4
--- /dev/null
+++ b/71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43
@@ -0,0 +1,511 @@
+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--
+