Delivery-date: Fri, 19 Jul 2024 17:01:22 -0700 Received: from mail-yw1-f191.google.com ([209.85.128.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUxXM-0004un-Mk for bitcoindev@gnusha.org; Fri, 19 Jul 2024 17:01:22 -0700 Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-664c185a606sf68160487b3.2 for ; Fri, 19 Jul 2024 17:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721433674; x=1722038474; 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=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=; b=XGoYnwTCRmv9/FVq9Nv7E7vtKfWbK+PCrdEPd1RYhV3DfOCVZAkhy2xBtj4y7KvSXk 6KG3vrYXbB7fx+ZAQFCg+kujGRM5NaWXvlkRFjIf/cCh7//Kh4gzDViD+dZHZu6ranVP v7sKRuXPM/TyS/N6lXNDoImYxvnJXLaSXztCIUDfEL8qIoE0o/cQOmsubCjVxo4e383v bwlKPfZGPqpZ2kgjA6xrpdbiQFU8mwYmlUSzx6lXgsKWVpz1uRx2gtT3zZj9ACMW8s6J cGAiipYN36adWS8uOytglD8Zl1CTeA5YCXXrwXTuwEvxB+WYoreAIJgURasuC2C8fQY+ KX5w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721433674; x=1722038474; 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=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=; b=QYeNnRigRSb04AJduEvC1CC1bCyfeh1lW4hxIEzM6XLRPLCEGQbW7mX+fxmxwvkpjO vZLlQo74uPnXydAGkGuIJuAhU5UbFdpOYXDZhh/rdubap0MRZkcb2LQxUSuI1qC/D9nP Lifu+Ffd00SifX/ogEy0195/jJgma1ad8Dflf2H2nXldAjeUgiZab3A2iSXQuSLOwBwJ 5sts/NgE46ie/YOq/CfP4VPzH8yBJ+thHM3ERo6P7oxKuZR5Y0os/uL8521ihmY6Smx3 p2T5zlOEfUKQhpVzVNRkZyqbisYbZzpk+DkoUSaUIl1WdNOp0TjW3yoQCQjgxoCMgeRK jGeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721433674; x=1722038474; 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=LWjClRzUht5mQmXrU01zXFyKrfvgsBqOXQXvmrle/5k=; b=EfL9MvyIXGWK3bV8+tkG1IjI1icnYpEE8GwzrH3roWITqmwwJT46Uvx16xCPCVPgmC P90ru4x7p7OzzSNZegZfAfZumhHtQXReL1ymMlCD+zNvNywdTUKuXGcP9NSb58ysxm/n ndOcyn7AmKskgACHmY/VLNq9GMwfmQAIWuUNzexc9IFZYto/Xdum1ohU3x3qfLjkJGCL OKvkxD8NSaRzkBXrgBQJTS6NURuOy/COc3T+ljouJq5Uq+sEwJwmyehonHn/Di3K3zhN dT1Bp/nAA2f/kncJBFkYUmMFfBs1liQv3nQB1QtsmUfn6Gt51QOzj5Hzuoz5pCRd5/mr jk1w== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUf/wPLsVDmiJTw+0nAhXgnzK6ydtdTVjT3L9pU6UO92WnE1fAG0gMTgxz9jelFim1QkeI8JnhZRo55RbkaKFiaruhOHOE= X-Gm-Message-State: AOJu0YwKGCz2ucrkzf0TYbsU0Yvjd7M3yUu0zpeKwXZ3nQNRdlxrBOho Pz2NFQHguVS3HKsM+tO6EOCKjH5H1d80r0MViFI8P04cl5v5pGml X-Google-Smtp-Source: AGHT+IFCkAMvyLIpE8K44Jvpwt9d2HdlN85/9ikoQLek6Uc5JY1c4cWY9m1iWbbUy+Cv02lY0HyOow== X-Received: by 2002:a05:6902:2512:b0:e08:7600:4697 with SMTP id 3f1490d57ef6-e087b8e2962mr80056276.46.1721433674402; Fri, 19 Jul 2024 17:01:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:86d1:0:b0:dfa:77ba:dc1f with SMTP id 3f1490d57ef6-e05fdb9c58dls1009753276.2.-pod-prod-06-us; Fri, 19 Jul 2024 17:01:13 -0700 (PDT) X-Received: by 2002:a05:690c:7:b0:663:ddc1:eab8 with SMTP id 00721157ae682-66a68f74be3mr701637b3.4.1721433673085; Fri, 19 Jul 2024 17:01:13 -0700 (PDT) Received: by 2002:a05:690c:2d11:b0:66a:8967:a513 with SMTP id 00721157ae682-66a8967cff9ms7b3; Fri, 19 Jul 2024 16:58:03 -0700 (PDT) X-Received: by 2002:a05:690c:17:b0:64a:d9c2:42c1 with SMTP id 00721157ae682-66a65e64cf6mr838487b3.5.1721433482643; Fri, 19 Jul 2024 16:58:02 -0700 (PDT) Date: Fri, 19 Jul 2024 16:58:02 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <4d950527-4430-49f2-8e38-3755bc58e301n@googlegroups.com> In-Reply-To: References: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_571870_921966128.1721433482429" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_571870_921966128.1721433482429 Content-Type: multipart/alternative; boundary="----=_Part_571871_291956564.1721433482429" ------=_Part_571871_291956564.1721433482429 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, > A is a low fee-rate transaction with opt-in disabled. When it is=20 broadcast, it > reaches 100% of nodes. >=20 > A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all > nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fac= t > relay A2 to non-full-rbf nodes they're peered with. But those nodes=20 reject A2 > as it is a full-RBF replacement. > > We are *not* trying to limit A2 to a single miner, or do any kind of > simultaneous broadcast. We don't need to. Okay, I see. Effectively, the attack holds are you're describing as=20 transaction A2 will propagate along the `mempoolfullrbf=3D1` transaction-relay network=20 paths. I think the initial description could have been clearer with this additional=20 observation, as somehow I think there is the low-odd marginal situation where the attacker= =20 broadcasting full-node is randomly peered with only transaction-relay `mempoolfullrbf=3D= 0`=20 neighboring nodes, and as such the bandwidth waste denial-of-service negligeable. This is correct there is no concurrent broadcast necessarily involved. > The % of miners/nodes that accept B isn't particularly relevant; this is= =20 an > attack primarily against nodes that have full-RBF disabled (though those= =20 nodes > will waste the bandwidth of their full-RBF peers). Yes I agree with this observation. In a world where a supermajority of=20 miners is running full-rbf as policy settings, I'll let what the corrollorary means in terms= =20 of transaction-relay network decentralization to be fully explained by someone else. > Again, the attack does not depend on a single miner receiving A2. Indeed,= =20 it > works fine even if 100% of hash power is mining A2. >=20 > Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a=20 fee-rate > only slightly higher than A that is still below the minimum economic=20 fee-rate, > and then replaced later with an even higher fee-rate double-spend that is= =20 a > high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a > replacement if the fee-rate of the replacement is lower than the directly > replaced transaction. Yes, I think what you're pointing is what makes the attack quite=20 interesting as there is no strict attacker necessity for A2 to be mined at some point in time=20 for the attack effect to play out. Note, see bitcoin core issue #14895 were few years ago= =20 such mempool adaptive attacker were pondered about transaction pinnings affecting=20 lightning. > You're not far off. But I believe you are still misunderstanding details,= =20 as described above. See above. > Correct. Although it's probably simplest to just pick a B that is large= =20 enough to max out the mempool limits on its own. I believe this observation can be still game out more at the advantage of= =20 the attacker. > Again, A2 does not need to pay a high enough fee-rate to be economical to= =20 mine. > So there are no particular latency requirements between when A, B, and A2= =20 are > broadcast. >=20 > All that is necessary for this class of attack is there be at least one= =20 miner > willing to mine A2 (or a further double-spend), who rejects A. Yes, I see more what is interesting with this attack by playing out on=20 network mepool feerate segment asymmetries arising from transaction-relay policy=20 divergence. > This attack is simply a variant of attacks that were publicly disclosed= =20 months > ago, that Core has chosen not to respond to at all, so the exact timefram= e > isn't very relevant. This is not actually a new class of attack; the whol= e > point of my disclosure is to show that Core does not actually care about= =20 this > class of attack by showing they won't even bother to fix the simplest=20 possible > version, even when the fix is trivial. As I said few months ago, I don't think this is a new class of attacks in= =20 bitcoin dev circles conversations about network DoS. To point out more historical=20 conversation this class of attack was pointed out by gmaxwell years ago on the bitcoin core= =20 pr #16698 few years ago [0]. [0] https://github.com/bitcoin/bitcoin/pull/16698#issuecomment-571399346 I think rather to accuse people currently maintaining the bitcoin-core sec= =20 mailing list of malovencly, it's more constructive to question if this set of people=20 still have the competency and bitcoin security culture to diligently understand and=20 address this class of attacks (and with gmaxwell in its own recent words on another channel=20 being far far less active in bitcoin protocol dev it's not a purely rhetorical question). In general, there is no necessity to assign to malevolency what can be=20 assigned to genuine incompetence or willful laziness. > But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd=20 publish > if I couldn't get any response. I publicly verified that achow (and=20 others) had > received my email on Jul 10th, with achow promising a response. On Jul=20 12th > rather than replying, Core closed my full-RBF pull-req that fixes this=20 issue. > On Jul 15th I reached out again, and after someone else pointed out that > failing to reply to me was degrading the value of the security mailing=20 list, > and finally got achow and glozow to respond in a perfunctory fashion=20 (glozow > recommended that I open a new full-RBF pull-req). So I published this on= =20 Jul > 18th after my replies to achow and glozow didn't get any response. This= =20 whole > time no-one has asked me to not publish this attack; asking me to keep=20 this > fact about mempools a secret would be rather duplicitous given that a key > argument for TRUC/V3 relies on "free" relay attacks not being possible. >=20 > Core could have *easily* responded by simply merging my pull-req to enabl= e > full-RBF by default, a trivial change that has had lots of ACKs from=20 technical > reviewers, which ~100% of hash power has adopted. No-one reasonable would= =20 have > questioned merging that pull-req. They chose not to do so, proving my=20 point > that none of this has anything to do with a genuine technical concern. Okay, with more information I think both achow and glozow answers are=20 reasonable in matters of formal responsiveness. That they pointed out to carry with a public process to fix that category= =20 of attacks only give more ground at my hypothesis highlighted above that it can be a= =20 problem of security culture knowledge or lack of experience know-how in handling=20 "half" / full=20 covert fixes. Sadly, I must say this is matching my historical experience with the=20 bitcoin security mailing list (and I had far more seasoned interlocutors) or the ones of=20 other security issues reporters I'm aware off. > I was previously on the bitcoin-security mailing list for years, and=20 almost > every disclosed attack has gotten a response within 24 hours, with the=20 longest > about 72 hours (I just skimmed through my archives to double check).=20 Failing to > respond at all is very unusual. As said in one my previous email, I'm still curious about achow101=20 explaining publicly why you have been kicked-out of the bitcoin-security mailing list, when you= =20 were certainly more senior than achow101 in matters of base-layer security issues or even= =20 hard technical issues like consensus interactions (e.g bip65). I'll re-iterate my respect= =20 towards achow101 as a maintainer from years of collaboration, though this is a topic worthy= =20 of an answer. Without a public answer under 2 weeks, I'll remove achow101 from among the= =20 future security reports recipients I can make about the bitcoin core project, be it a=20 report that is codebase-only or any security issues related to the base layer and affecting all=20 full-nodes implementations or the mining stack. Under the information shared and from my perspective, achow101 argued=20 conduct of playing for unknown reasons with an adminstrative communication endpoint creates a= =20 moral hazard and this would be further unethical for me as a security researcher to=20 share sensitive security information with that bitcoin maintainer. Best, Antoine ots hash: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464 Le vendredi 19 juillet 2024 =C3=A0 19:27:40 UTC+1, Peter Todd a =C3=A9crit = : > On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote: > > Hi Peter, > >=20 > > > I think you need to re-read the attack carefully before we discuss th= is > > > further. The % of hash power mining full-rbf does not significantly > > change the > > > cost efficiency of the attack as long as the fee-rate of the B > > transaction(s) > > > is below the minimum economic fee-rate necessary for miners to mine a > > > transaction. Above the minimum economic fee-rate, the cost efficiency= =20 > is > > an > > > essentially linear function of % of full-rbf miners. > >=20 > > This is not the % of hash power mining _full-rbf_ I was pointing to, ju= st > > the indistinct > > total % of hash power mining. > >=20 > > In my understanding, this is the scenario: > > - Alice broadcasts small size, low-feerate transaction opt-in disabled = A=20 > to > > 99% of the miners+network nodes mempools > > - Alice broadcasts a double-spend of A, a high-feerate transaction A2 t= o > > Mark, a single miner > > - Network nodes does not relay transaction A to Mark and vice-versa Mar= k > > does not relay transaction A2 to network nodes > > Here I think you've misunderstood the attack. > > A is a low fee-rate transaction with opt-in disabled. When it is=20 > broadcast, it > reaches 100% of nodes. > > A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all > nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fac= t > relay A2 to non-full-rbf nodes they're peered with. But those nodes rejec= t=20 > A2 > as it is a full-RBF replacement. > > We are *not* trying to limit A2 to a single miner, or do any kind of > simultaneous broadcast. We don't need to. > > > - Alice broadcasts a child B of transaction A to 99% of the=20 > miners+network > > nodes mempools > > The % of miners/nodes that accept B isn't particularly relevant; this is = an > attack primarily against nodes that have full-RBF disabled (though those= =20 > nodes > will waste the bandwidth of their full-RBF peers). > > > - Mark, the single miner confirms in a block A2, rendering as a waste A= +B > > network bandwidth > > Again, the attack does not depend on a single miner receiving A2. Indeed,= =20 > it > works fine even if 100% of hash power is mining A2. > > Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a=20 > fee-rate > only slightly higher than A that is still below the minimum economic=20 > fee-rate, > and then replaced later with an even higher fee-rate double-spend that is= a > high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a > replacement if the fee-rate of the replacement is lower than the directly > replaced transaction. > > > Correct if I'm wrong with this scenario and if it does not match the=20 > attack > > vector you're describing. > > You're not far off. But I believe you are still misunderstanding details,= =20 > as > described above. > > > The child B can be extended with a full chain of useless children withi= n > > max mempool limits. > > Correct. Although it's probably simplest to just pick a B that is large= =20 > enough > to max out the mempool limits on its own. > > > The attack efficiency (i.e the total vB of bandwidth network waste) is > > dependent on the delay > > by which transaction A2 is included in Mark's block template and > > subsequently mined. Back to > > my observation, higher are Mark hashrate ressources, less there is=20 > latency > > to let transaction B > > spontaneously propagate on the network, or for Alice to (re)-broadcast = in > > cycle. > > Again, A2 does not need to pay a high enough fee-rate to be economical to= =20 > mine. > So there are no particular latency requirements between when A, B, and A2= =20 > are > broadcast. > > All that is necessary for this class of attack is there be at least one= =20 > miner > willing to mine A2 (or a further double-spend), who rejects A. > > > All that said, I think my open question to you at the beginning of my > > answer is still there, > > i.e how much time has been left between the private report of this issu= e=20 > to > > the sec mailing > > list and the public disclosure of your email. > > This attack is simply a variant of attacks that were publicly disclosed= =20 > months > ago, that Core has chosen not to respond to at all, so the exact timefram= e > isn't very relevant. This is not actually a new class of attack; the whol= e > point of my disclosure is to show that Core does not actually care about= =20 > this > class of attack by showing they won't even bother to fix the simplest=20 > possible > version, even when the fix is trivial. > > But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd=20 > publish > if I couldn't get any response. I publicly verified that achow (and=20 > others) had > received my email on Jul 10th, with achow promising a response. On Jul 12= th > rather than replying, Core closed my full-RBF pull-req that fixes this=20 > issue. > On Jul 15th I reached out again, and after someone else pointed out that > failing to reply to me was degrading the value of the security mailing=20 > list, > and finally got achow and glozow to respond in a perfunctory fashion=20 > (glozow > recommended that I open a new full-RBF pull-req). So I published this on= =20 > Jul > 18th after my replies to achow and glozow didn't get any response. This= =20 > whole > time no-one has asked me to not publish this attack; asking me to keep th= is > fact about mempools a secret would be rather duplicitous given that a key > argument for TRUC/V3 relies on "free" relay attacks not being possible. > > Core could have *easily* responded by simply merging my pull-req to enabl= e > full-RBF by default, a trivial change that has had lots of ACKs from=20 > technical > reviewers, which ~100% of hash power has adopted. No-one reasonable would= =20 > have > questioned merging that pull-req. They chose not to do so, proving my poi= nt > that none of this has anything to do with a genuine technical concern. > > I was previously on the bitcoin-security mailing list for years, and almo= st > every disclosed attack has gotten a response within 24 hours, with the=20 > longest > about 72 hours (I just skimmed through my archives to double check).=20 > Failing to > respond at all is very unusual. > > --=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/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com. ------=_Part_571871_291956564.1721433482429 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter,

> A is a low fee-rate transaction with opt-in disab= led. When it is broadcast, it
> reaches 100% of nodes.
> > A2 is a full-RBF double-spend of A. When it is broadcast, it reach= es all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF = nodes do in fact
> relay A2 to non-full-rbf nodes they're peered wi= th. But those nodes reject A2
> as it is a full-RBF replacement.>
> We are *not* trying to limit A2 to a single miner, or do = any kind of
> simultaneous broadcast. We don't need to.

= Okay, I see. Effectively, the attack holds are you're describing as transac= tion A2
will propagate along the `mempoolfullrbf=3D1` transaction-rela= y network paths. I think
the initial description could have been clear= er with this additional observation, as
somehow I think there is the l= ow-odd marginal situation where the attacker broadcasting
full-node is= randomly peered with only transaction-relay `mempoolfullrbf=3D0` neighbori= ng
nodes, and as such the bandwidth waste denial-of-service negligeabl= e.

This is correct there is no concurrent broadcast necessarily = involved.

> The % of miners/nodes that accept B isn't particu= larly relevant; this is an
> attack primarily against nodes that ha= ve full-RBF disabled (though those nodes
> will waste the bandwidth= of their full-RBF peers).

Yes I agree with this observation. In= a world where a supermajority of miners is running
full-rbf as policy= settings, I'll let what the corrollorary means in terms of transaction-rel= ay
network decentralization to be fully explained by someone else.

> Again, the attack does not depend on a single miner receiving = A2. Indeed, it
> works fine even if 100% of hash power is mining A2= .
>
> Also, A2 isn't necessarily what gets mined. A2 can b= e broadcast with a fee-rate
> only slightly higher than A that is s= till below the minimum economic fee-rate,
> and then replaced later= with an even higher fee-rate double-spend that is a
> high enough = fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> repl= acement if the fee-rate of the replacement is lower than the directly
= > replaced transaction.

Yes, I think what you're pointing is = what makes the attack quite interesting as there
is no strict attacker= necessity for A2 to be mined at some point in time for the attack
eff= ect to play out. Note, see bitcoin core issue #14895 were few years ago suc= h mempool
adaptive attacker were pondered about transaction pinnings a= ffecting lightning.

> You're not far off. But I believe you a= re still misunderstanding details, as
described above.

See = above.

> Correct. Although it's probably simplest to just pic= k a B that is large enough
to max out the mempool limits on its own.
I believe this observation can be still game out more at the adva= ntage of the attacker.

> Again, A2 does not need to pay a hig= h enough fee-rate to be economical to mine.
> So there are no parti= cular latency requirements between when A, B, and A2 are
> broadcas= t.
>
> All that is necessary for this class of attack is t= here be at least one miner
> willing to mine A2 (or a further doubl= e-spend), who rejects A.

Yes, I see more what is interesting wit= h this attack by playing out on network
mepool feerate segment asymmet= ries arising from transaction-relay policy divergence.

> This= attack is simply a variant of attacks that were publicly disclosed months<= br />> ago, that Core has chosen not to respond to at all, so the exact = timeframe
> isn't very relevant. This is not actually a new class o= f attack; the whole
> point of my disclosure is to show that Core d= oes not actually care about this
> class of attack by showing they = won't even bother to fix the simplest possible
> version, even when= the fix is trivial.

As I said few months ago, I don't think thi= s is a new class of attacks in bitcoin dev
circles conversations about= network DoS. To point out more historical conversation this
class of = attack was pointed out by gmaxwell years ago on the bitcoin core pr #16698 = few
years ago [0].

[0] https://github.com/bitcoin/bitcoin/p= ull/16698#issuecomment-571399346

I think rather to accuse people= currently maintaining the bitcoin-core sec mailing list
of malovencly= , it's more constructive to question if this set of people still have thecompetency and bitcoin security culture to diligently understand and ad= dress this class
of attacks (and with gmaxwell in its own recent words= on another channel being far far less
active in bitcoin protocol dev = it's not a purely rhetorical question).

In general, there is no = necessity to assign to malevolency what can be assigned to
genuine inc= ompetence or willful laziness.

> But anyway, I disclosed on J= ul 7th giving a 7 day deadline before I'd publish
> if I couldn't g= et any response. I publicly verified that achow (and others) had
> = received my email on Jul 10th, with achow promising a response. On Jul 12th=
> rather than replying, Core closed my full-RBF pull-req that fixe= s this issue.
> On Jul 15th I reached out again, and after someone = else pointed out that
> failing to reply to me was degrading the va= lue of the security mailing list,
> and finally got achow and glozo= w to respond in a perfunctory fashion (glozow
> recommended that I = open a new full-RBF pull-req). So I published this on Jul
> 18th af= ter my replies to achow and glozow didn't get any response. This whole
> time no-one has asked me to not publish this attack; asking me to kee= p this
> fact about mempools a secret would be rather duplicitous g= iven that a key
> argument for TRUC/V3 relies on "free" relay attac= ks not being possible.
>
> Core could have *easily* respon= ded by simply merging my pull-req to enable
> full-RBF by default, = a trivial change that has had lots of ACKs from technical
> reviewe= rs, which ~100% of hash power has adopted. No-one reasonable would have
> questioned merging that pull-req. They chose not to do so, proving m= y point
> that none of this has anything to do with a genuine techn= ical concern.

Okay, with more information I think both achow and= glozow answers are reasonable
in matters of formal responsiveness.
That they pointed out to carry with a public process to fix that c= ategory of attacks
only give more ground at my hypothesis highlighted = above that it can be a problem of
security culture knowledge or lack o= f experience know-how in handling "half" / full
covert fixes.
Sadly, I must say this is matching my historical experience with the bi= tcoin security
mailing list (and I had far more seasoned interlocutors= ) or the ones of other security
issues reporters I'm aware off.
<= br />> I was previously on the bitcoin-security mailing list for years, = and almost
> every disclosed attack has gotten a response within 24= hours, with the longest
> about 72 hours (I just skimmed through m= y archives to double check). Failing to
> respond at all is very un= usual.

As said in one my previous email, I'm still curious about= achow101 explaining publicly
why you have been kicked-out of the bitc= oin-security mailing list, when you were certainly
more senior than ac= how101 in matters of base-layer security issues or even hard technical
issues like consensus interactions (e.g bip65). I'll re-iterate my respect= towards achow101
as a maintainer from years of collaboration, though = this is a topic worthy of an answer.

Without a public answer und= er 2 weeks, I'll remove achow101 from among the future security
report= s recipients I can make about the bitcoin core project, be it a report that= is codebase-only
or any security issues related to the base layer and= affecting all full-nodes implementations
or the mining stack.
Under the information shared and from my perspective, achow101 argued c= onduct of playing
for unknown reasons with an adminstrative communicat= ion endpoint creates a moral hazard
and this would be further unethica= l for me as a security researcher to share sensitive security
informat= ion with that bitcoin maintainer.

Best,
Antoine
ots ha= sh: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464
<= br />
Le v= endredi 19 juillet 2024 =C3=A0 19:27:40 UTC+1, Peter Todd a =C3=A9crit=C2= =A0:
On Fri, = Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> Hi Peter,
>=20
> > I think you need to re-read the attack carefully before we di= scuss this
> > further. The % of hash power mining full-rbf does not signifi= cantly
> change the
> > cost efficiency of the attack as long as the fee-rate of the = B
> transaction(s)
> > is below the minimum economic fee-rate necessary for miners t= o mine a
> > transaction. Above the minimum economic fee-rate, the cost ef= ficiency is
> an
> > essentially linear function of % of full-rbf miners.
>=20
> This is not the % of hash power mining _full-rbf_ I was pointing t= o, just
> the indistinct
> total % of hash power mining.
>=20
> In my understanding, this is the scenario:
> - Alice broadcasts small size, low-feerate transaction opt-in disa= bled A to
> 99% of the miners+network nodes mempools
> - Alice broadcasts a double-spend of A, a high-feerate transaction= A2 to
> Mark, a single miner
> - Network nodes does not relay transaction A to Mark and vice-vers= a Mark
> does not relay transaction A2 to network nodes

Here I think you've misunderstood the attack.

A is a low fee-rate transaction with opt-in disabled. When it is broadc= ast, it
reaches 100% of nodes.

A2 is a full-RBF double-spend of A. When it is broadcast, it reaches al= l
nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in f= act
relay A2 to non-full-rbf nodes they're peered with. But those nodes= reject A2
as it is a full-RBF replacement.

We are *not* trying to limit A2 to a single miner, or do any kind of
simultaneous broadcast. We don't need to.

> - Alice broadcasts a child B of transaction A to 99% of the miners= +network
> nodes mempools

The % of miners/nodes that accept B isn't particularly relevant; th= is is an
attack primarily against nodes that have full-RBF disabled (though thos= e nodes
will waste the bandwidth of their full-RBF peers).

> - Mark, the single miner confirms in a block A2, rendering as a wa= ste A+B
> network bandwidth

Again, the attack does not depend on a single miner receiving A2. Indee= d, it
works fine even if 100% of hash power is mining A2.

Also, A2 isn't necessarily what gets mined. A2 can be broadcast wit= h a fee-rate
only slightly higher than A that is still below the minimum economic fe= e-rate,
and then replaced later with an even higher fee-rate double-spend that = is a
high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits = a
replacement if the fee-rate of the replacement is lower than the direct= ly
replaced transaction.

> Correct if I'm wrong with this scenario and if it does not mat= ch the attack
> vector you're describing.

You're not far off. But I believe you are still misunderstanding de= tails, as
described above.

> The child B can be extended with a full chain of useless children = within
> max mempool limits.

Correct. Although it's probably simplest to just pick a B that is l= arge enough
to max out the mempool limits on its own.

> The attack efficiency (i.e the total vB of bandwidth network waste= ) is
> dependent on the delay
> by which transaction A2 is included in Mark's block template a= nd
> subsequently mined. Back to
> my observation, higher are Mark hashrate ressources, less there is= latency
> to let transaction B
> spontaneously propagate on the network, or for Alice to (re)-broad= cast in
> cycle.

Again, A2 does not need to pay a high enough fee-rate to be economical = to mine.
So there are no particular latency requirements between when A, B, and = A2 are
broadcast.

All that is necessary for this class of attack is there be at least one= miner
willing to mine A2 (or a further double-spend), who rejects A.

> All that said, I think my open question to you at the beginning of= my
> answer is still there,
> i.e how much time has been left between the private report of this= issue to
> the sec mailing
> list and the public disclosure of your email.

This attack is simply a variant of attacks that were publicly disclosed= months
ago, that Core has chosen not to respond to at all, so the exact timefr= ame
isn't very relevant. This is not actually a new class of attack; th= e whole
point of my disclosure is to show that Core does not actually care abou= t this
class of attack by showing they won't even bother to fix the simple= st possible
version, even when the fix is trivial.

But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'= ;d publish
if I couldn't get any response. I publicly verified that achow (and= others) had
received my email on Jul 10th, with achow promising a response. On Jul = 12th
rather than replying, Core closed my full-RBF pull-req that fixes this = issue.
On Jul 15th I reached out again, and after someone else pointed out tha= t
failing to reply to me was degrading the value of the security mailing = list,
and finally got achow and glozow to respond in a perfunctory fashion (g= lozow
recommended that I open a new full-RBF pull-req). So I published this o= n Jul
18th after my replies to achow and glozow didn't get any response. = This whole
time no-one has asked me to not publish this attack; asking me to keep = this
fact about mempools a secret would be rather duplicitous given that a k= ey
argument for TRUC/V3 relies on "free" relay attacks not being= possible.

Core could have *easily* responded by simply merging my pull-req to ena= ble
full-RBF by default, a trivial change that has had lots of ACKs from te= chnical
reviewers, which ~100% of hash power has adopted. No-one reasonable wou= ld have
questioned merging that pull-req. They chose not to do so, proving my p= oint
that none of this has anything to do with a genuine technical concern.

I was previously on the bitcoin-security mailing list for years, and al= most
every disclosed attack has gotten a response within 24 hours, with the = longest
about 72 hours (I just skimmed through my archives to double check). Fa= iling to
respond at all is very unusual.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com.=
------=_Part_571871_291956564.1721433482429-- ------=_Part_571870_921966128.1721433482429--