From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 19 Jul 2024 11:27:46 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sUsKY-0007i2-8s for bitcoindev@gnusha.org; Fri, 19 Jul 2024 11:27:46 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-25e8c18a7c8sf560963fac.3 for ; Fri, 19 Jul 2024 11:27:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1721413660; cv=pass; d=google.com; s=arc-20160816; b=u6u72PUgmiQjhlgd/RY56oLL4wOxz+TjQoXNXl3Kw0JM61eSDlibFenYlwzHJjinfo xawitIkca3v76T67RAIBZPiUGi4An8VLLxob3Ix/J6YTeT7RYHjbozum05ReRM5UOYVl Qg7ybcYBsHetURVATKK/ytQ2ieU/j7VvQF3HhNgl2vY+bRO6J+fYpZXULxx6B4IJCF70 V4UiMZS7mavo7TPPkeVYvAvhZrJd9cpDDHvJH2TxqzJYhDcuydopWFgQgNZZvrHugJuO wMQxUlX464x1BJPyNBlWgJGIvdFd9YxCGDji6YIyd8Tw0VJsjGEA/IdJ2GmviGw2B+6m bf3A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :feedback-id:sender:dkim-signature; bh=dEQOdNxFKIb38Y1y8/TZ4UzyMjXJWRI82Jp+t/tlbaw=; fh=Q/RUO+/KYoH/2XlPCrDAJkpldgMWWjLBgg8j29uoZxA=; b=uBUXYxriNqJIcX2C7lw+MzrqHV4IxwkTY/1a7f15ueLR2IX64ARDHqU4I+CFp3erTt T9WcRBpqP5gkXOIhqEmENEdubbsxjjjcNA4C2axTw8YnsbORlBzLDsZB6pcxiWVrddLQ 8a85tQm9EjznvpMu9EiLLSLWJ96pxkAUxsrTwxHe89rvrQB8faoV6UxP8VVq0NB6lyaM iRj0iCwPtrORNhejrxPQk6wny6Nh2bVbIGdcqeoiNb5zGfjWbt8GK2jN9/c9nKBZ8MhE kuHszR0yLbqg7T95By/uI0AjML3BB6KR9wZB+f8PMfHrR7OI/IN+DhesmtdoL8e7ud0O p+yQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=lmVOV3QX; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.148 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721413660; x=1722018460; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id:sender :from:to:cc:subject:date:message-id:reply-to; bh=dEQOdNxFKIb38Y1y8/TZ4UzyMjXJWRI82Jp+t/tlbaw=; b=jWtSicbidKPDFSGfc8+HCfKxjlfc4/pao84Mgz+eb5OaEs1QFNy5IjrI9D5hJj7qAq DDRrYU8XOo8JhWBq+ZU2JLVqwD71esgUoq/M3QFmuXkJLUMnhoVkFA6kb++kqDa/Usrk PpH4LklIRrGS5XcAm0KvPQ3BCx8UhAZ1XaHmBy0MqmfoaCEe7gfLABL6r9WcgYuLWOHQ kb0hHn+O5w8VxZwRxb0REIT2AFTUWva8OIrSXNS9o+XfeXBrTg+Bw4ZaCPVp4oZI2iq5 Uoel6Oy6RfL0UaIMY/3JX22VIV8O7aD6HElOFPkOOVKa5ZyOBPdBs1kNmB4CvhpfT16O QBKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721413660; x=1722018460; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:feedback-id :x-beenthere:x-gm-message-state:sender:from:to:cc:subject:date :message-id:reply-to; bh=dEQOdNxFKIb38Y1y8/TZ4UzyMjXJWRI82Jp+t/tlbaw=; b=GwER1ryEow7DNiQ3ro4Er+6lLqLDzB1cj+ZqElHMkornMd1KjsfQeKq+CzSPY/ccbZ F6aHe8ERyG4591nfi6lyo5Nvx3b4kRBiy+1Dwd2+g9D/oM2rmcTcEf1Sg9jWUt1xzOL5 07NxMW+o2QY1aTHAboejoSiHLTE0BpCEIjQVzRl1VtbOQKB2T23eUbQRcjNDuNcMCxAW gKwUATzFisHqozSN3NHE7d/ErAc59tDxoi/koTitnJsD6H+K2OjNCTr8ffX98pIDb9uj XorNQCos+tbZqQCi0ap3PelLJqLJqaCS571r6I5/UH2XnaiZw40YRYPw+6ThQPPsGqJO oWwA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUXYKaUOHBnEClHifuqXGauYDLcEUr6pvqIPxruIKkjMImHft56Ty+9hqf+bLHW544zNal5ctdegmfK6jHVIvrV+l7LGHA= X-Gm-Message-State: AOJu0YwWF/SYVnp+bzpLstOtas2RZcHCk0KLWfm1blL1VtVAwLasRHiZ ca/aIwdjEeCcu6vQruS+GHCxRI+skOx+ujTEs3jptUiaoxogl8fc X-Google-Smtp-Source: AGHT+IGk4hBx9wJj0/bSMQLiWzi5Rr3lzwFTXsC5aZZ7T0p0jQQae5b8692lggWLqMTsQAxyBNgfEA== X-Received: by 2002:a05:6358:89c:b0:1aa:c73d:5a97 with SMTP id e5c5f4694b2df-1acc5a7d6fdmr64013755d.1.1721413659908; Fri, 19 Jul 2024 11:27:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:5e82:b0:6b2:a690:c804 with SMTP id 6a1803df08f44-6b79b767c4bls36008826d6.1.-pod-prod-07-us; Fri, 19 Jul 2024 11:27:38 -0700 (PDT) X-Received: by 2002:ad4:4eee:0:b0:6b5:466a:f445 with SMTP id 6a1803df08f44-6b940161393mr343436d6.3.1721413658646; Fri, 19 Jul 2024 11:27:38 -0700 (PDT) Received: by 2002:a05:620a:8d09:b0:79f:13a0:3096 with SMTP id af79cd13be357-7a196cd351dms85a; Fri, 19 Jul 2024 07:38:21 -0700 (PDT) X-Received: by 2002:a05:6122:32c4:b0:4ef:6d02:f4a with SMTP id 71dfb90a1353d-4f4df8dd009mr10641070e0c.13.1721399900567; Fri, 19 Jul 2024 07:38:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1721399900; cv=none; d=google.com; s=arc-20160816; b=eJOF5l6vyHbPr6pWx1+5bfhAM53Zm+10/nvD8O1+U+FT6RIe33hVDTyAftVMzQg7ay O77iS0hMVjT1mJRq6R6brMFypc9n5FZqLYfDYmqpj5Xmjh8/BcxV88tI0+wLmxyLluWZ IsDsi9btk2IO8/K1dVJG5+HGGnP0xu1HVIEcAj9WXkiYgGuaErsbF3WbAn4k8jvf+KvK a/c8744rs+MM9Aj2mWLs6ptNqeFDXv3sOr9iDWJTecIkuu+vmkkN26WwtL/EEuS3PLiR E9t++zpKaGFxJ49BY5GKqa5Eg16n08dJCrhPVcYavIZeHL7AsebkxGk1iBvbVZuP+o1g 2Tdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:dkim-signature; bh=h0xqjkwFjCzsfJrhpwvrb1xRVUyr0Ot8GRA9uF4TR6o=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=TElK/iY6atR/sBSEgoCcPFbjYwP0t+IIuBmEbt9l9nT6SBmkIE67/6r946WZRS43Mw 5JyzjSUSIXx3XUjIYuUy5P2z4OMNRMi69OoPOEBcSoKv00CllTFzDw2xAfGKSg6a4VqI FeyxLMxMOm3BR2i1VzPklZkg7NJ/cPmYigKVjmfHvnwAcFlYapR7GJtk03CTROd6ypTB 92Lg9X31Jyb/1POGYeiNmVN+BAUP36mnfNb1N4aMnAgiTMl1RzrY7ykxeuhvGTit7Qzg g3fdp/gmQuo7FUgvwuo2W5b49hqIj+2ZfrA4RutPAFFsdGHKmjAL4faO+n0J6O1kdjP+ gfvQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=lmVOV3QX; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.148 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fout5-smtp.messagingengine.com (fout5-smtp.messagingengine.com. [103.168.172.148]) by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-4f4fa08454bsi111889e0c.5.2024.07.19.07.38.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jul 2024 07:38:19 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.148 as permitted sender) client-ip=103.168.172.148; Received: from compute8.internal (compute8.nyi.internal [10.202.2.227]) by mailfout.nyi.internal (Postfix) with ESMTP id 7DDD5138041C; Fri, 19 Jul 2024 10:38:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute8.internal (MEProxy); Fri, 19 Jul 2024 10:38:18 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrhedugdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefhjedt necuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdho rhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 19 Jul 2024 10:38:16 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id A10875F83F; Fri, 19 Jul 2024 14:38:11 +0000 (UTC) Date: Fri, 19 Jul 2024 14:38:11 +0000 From: Peter Todd To: Antoine Riard Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Message-ID: References: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m+e0e7tR4hJ4xyE+" Content-Disposition: inline In-Reply-To: X-Original-Sender: pete@petertodd.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=lmVOV3QX; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.148 as permitted sender) smtp.mailfrom=pete@petertodd.org 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.8 (/) --m+e0e7tR4hJ4xyE+ Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote: > Hi Peter, > > > I think you need to re-read the attack carefully before we discuss this > > 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 is > an > > essentially linear function of % of full-rbf miners. > > This is not the % of hash power mining _full-rbf_ I was pointing to, just > the indistinct > total % of hash power mining. > > In my understanding, this is the scenario: > - Alice broadcasts small size, low-feerate transaction opt-in disabled 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-versa 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 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 fact 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; this is an attack primarily against nodes that have full-RBF disabled (though those 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, 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 fee-rate only slightly higher than A that is still 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 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 attack > vector you're describing. You're not far off. But I believe you are still misunderstanding details, 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 large 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 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 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 timeframe isn't very relevant. This is not actually a new class of attack; the whole point of my disclosure is to show that Core does 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. 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 that 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 (glozow recommended that I open a new full-RBF pull-req). So I published this on 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 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 enable full-RBF by default, a trivial change that has had lots of ACKs from technical reviewers, which ~100% of hash power has adopted. No-one reasonable would have questioned merging that pull-req. They chose not to do so, proving my point 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 almost 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). Failing to respond at all is very unusual. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zpp6U00Mp7Z/bOej%40petertodd.org. --m+e0e7tR4hJ4xyE+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaaek0ACgkQLly11TVR LzfTqA//QccTqKqsRHGBfmGCn2l++KqUCXyHKXcF3E03bmLIZJaH3XY+PO9hJLRY qvHVHm7sPjlI6qgikB3rnisJhPHT6xr5NsCMhfQoJJENNaSzWN0hMC/hObMq/41V z5v75dzfNMqhiK4bMld6I/Obe+RgrAykKJx4y/ptjkGm2pV6rzuERs1Ca1O8WK9L xdkNNmCuCkGc8nMba5llCqBS9v/uUCEatGS1BykcQ9I28toYNrXLnZllfCEgjKSx +q+AFDd2nNC7u23NXzNm6lctO0wAd+hjDtUgcrgEOXEgWa3KuZP89o9tt2n7Pl8p c+fJAA4/Cf7gVcoqqRuoWyuElQgoNyadZda8zWt/59UMU5w0wSytJMyCKi89Me0F 48IwR40zh4whWoz4M+O6q+2rHKuFOJuHomdLjw8YBZ1j7t8u7RvfT4VdSQg57Hv4 jL08UrbL3N56Sisf9rAJrAi+6gQ3A9Hbt+NVXwwft3pxaUEikLqEVIfPOp5cw4sB ioencZwBmYxAZiUHmO8JS86xVqHoMcvNsu8vk3S2sMAWG9ot6ez4h1eC5O6psQjL U4W9NB/lYFqYf25X6qJpuONuWDH4EIZ4B0yVWKVVJPvFl9XhNK6CRllYikwrO7up GDhhB99vEpfVtIPS6MFsiuR0V29rNpl8hWTn+jSbGXZbHb80HYs= =Ur0A -----END PGP SIGNATURE----- --m+e0e7tR4hJ4xyE+--