diff options
author | Antoine Riard <antoine.riard@gmail.com> | 2024-03-29 13:48:26 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@googlegroups.com> | 2024-03-29 14:14:29 -0700 |
commit | 522a0d3a2e59113e0c1eac9fc26d883cc7176eff (patch) | |
tree | 5700df68540c6d1233370e650ec9962a14d70f65 | |
parent | d2692b2f85ff4365aa5e0392e820a68fe3bd8a96 (diff) | |
download | pi-bitcoindev-522a0d3a2e59113e0c1eac9fc26d883cc7176eff.tar.gz pi-bitcoindev-522a0d3a2e59113e0c1eac9fc26d883cc7176eff.zip |
Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6
-rw-r--r-- | 71/9c9a78a11bf5ae2cc84cc62645b6729c97ef43 | 511 |
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>> I do not consider CVE-2017-12842 to be serious. Indeed,= + I'm skeptical that we<br />> should even fix it with a fork. SPV valida= +tion is very sketchy, and the amount<br />> of work and money required t= +o trigger CVE-2017-12842 is probably as or more<br />> expensive than si= +mply creating fake blocks.<br /><br />> Sergio's RSK Bridge contract bei= +ng vulnerable to it just indicates it was a<br />> 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>> To be clear, in this particular case I had specific, = +insider, knowledge that<br />> the relevant people had in fact seen my r= +eport and had already decided to<br />> dismiss it. This isn't a typical= + case where you're emailing some random company<br />> and don't have an= +y contacts. I personally knew prior to publication that the<br />> relev= +ant people had been given a fair chance to comment, had chosen not to, and<= +br />> 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>> I'm not going to say anything further on how I knew this, because I'= +m not about<br />> to put up people who have been co-operating with me t= +o the risk of harassment<br />> from people like Harding and others; I'm= + not very popular right now with many<br />> 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>> Anyway, I think the lesson learned here is it= +'s probably not worth bothering<br />> with a disclosure process at all = +for this type of issue. It just created a<br />> bunch of distracting po= +litical drama when simply publishing this exploit<br />> 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>> If, for example, all Bitcoin node= +s were somehow peered in a perfect ring, with<br />> each node having ex= +actly two peers, the sum total bandwidth of using 2<br />> conflicting p= +roof-of-UTXOs (aka spending the UTXO), would be almost identical<br />> = +to the sum total bandwidth of just using 1. The only additional bandwidth w= +ould<br />> be the three to four nodes at the "edges" of the ring who sa= +w the two different<br />> conflicting versions.<br /><br />> With hi= +gher #'s of peers, the total maximum extra bandwidth used broadcasting<br /= +>> 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>> > Modulo economic irrationalities with differently sized txs li= +ke the Rule +<br>> #6 +<br>> > attack, the proof-of-UTXO is almost economically paid even wh= +en mempools +<br>> are +<br>> > partitioned because the bandwidth used by a given form of a t= +ransaction is +<br>> > limited to the % of peers that relay it. Eg if I broadcast Tx= +A to 50% of +<br>> nodes, +<br>> > and TxB to the other 50%, both spending the same txout, the t= +otal cost/KB +<br>> used +<br>> > in total would exactly the same... except that nodes have mor= +e than one +<br>> peer. +<br>> > This acts as an amplification fator to attacks depending on t= +he exact +<br>> topology +<br>> > as bandwidth is wasted in proportion to the # of peers txs ne= +ed to be +<br>> broadcast +<br>> > too. Basically, a fan-out factor. +<br>>=20 +<br>> > If the # of peers is reduced, the impact of this type of atta= +ck is also +<br>> > reduced. Of course, a balance has to be maintained. +<br>>=20 +<br>> Sure, proof-of-UTXO is imperfectly economically charged, however I= + think +<br>> you can +<br>> re-use the same proof-of-UTXO for each subset of Sybilled transact= +ion-relay +<br>> peers. +<br> +<br>Of course you can. That's the whole point of my scenario above: you= + can re-use +<br>the proof-of-UTXO. But since nodes' 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 "edges" of the ring who saw= + the two different +<br>conflicting versions. +<br> +<br>With higher #'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&q=3Dhttps://pe= +tertodd.org&source=3Dgmail&ust=3D1711830543925000&usg=3DAOvVaw2= +t6YOtPhZYJ42gICoxho60">https://petertodd.org</a> 'peter'[:-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&q=3Dhttp://petertodd.org= +&source=3Dgmail&ust=3D1711830543925000&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" 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-- + |