From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 21 Jul 2024 13:48:53 -0700 Received: from mail-qv1-f64.google.com ([209.85.219.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVdUC-00050d-Cl for bitcoindev@gnusha.org; Sun, 21 Jul 2024 13:48:53 -0700 Received: by mail-qv1-f64.google.com with SMTP id 6a1803df08f44-6b7a5ab3971sf60617856d6.2 for ; Sun, 21 Jul 2024 13:48:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1721594926; cv=pass; d=google.com; s=arc-20160816; b=qufPktHWXx6haSsHhCW2At/nWxVtXF+6ixYX6myNcfD9C9j+l+ZEUNOSn5ayRsKsqD D1OhMGaubPvvAUS0t+JtFY45xUZqzta6fmtEL1R4UnFVrB01flNeiCJJG1vWNbDnOLoU oiJUpxjWwybTUAwENlCPvKVLStf0abVYiC/04A1oBFC7c1sPR4vL76AZPkdiFRra6tla teTQ/LpkQRqzpVyZnGWrGekLfP3rtJpIACZk6VEcfbiTHBAMOE7t1llrUTT+jV89tnNe k9o/C8j9ZdQCGAeyamtUrLJ1vN8OjFmL0xQDIX5nRhy6ekl9RnF5NDb8rvoydEK2O2Sr cxEA== 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=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=; fh=tovN7fdLXOEAEmCZuUj/39FNP9lIUdXaIeiX8lMVY5E=; b=BJohUBDlXa1tTGckVIPgzDcKz3ZCgBWNo4riLAviE4UnycPIxxvbL/lGxitK11YasY i8qCRAGMFlPKhIkh2+KovAB4QNJQMWs4Pay75URMW88A5ZjPNCG0ch/KMl3uM6xFN0T7 M/lUJhtyRGbo0F+2YVPwWBLf0j5y5UsITsd7NPmnynatedI79M0keU9QwWqDi2WhRrUA DORL5D5Sf61iDcYn6GiQw/K814YlhUubRPMxko0Yy/7MjuhEqgittYnnajWUcL8d9Ylr JnjObTW3ikn2lZOOUXXNiDXKZ/eil6GBzIt2ehCeJRdnwrOMJF79ykySMZtHIrO2TlL5 ypLg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=P8+xYI3l; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721594926; x=1722199726; 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=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=; b=AutRycvfFE2IDXJsj3lJ/HM5IaIhh5bCI6gP2vinkOz68Bkhh3Yf8GJPhkeQ+qSObt vwUDhLvZanYDLpfKysgeMnVEfZetNYXqzkmWR3sbh7WQZGlQi2msV7f0sCDm89yRJ9Ge NJufotpovXt3v37j5PrRv+8tO/xXrfxUE1pp6HeNw16Hg21Fx5DDis/JyArJm/xCXzvN dN49TYYFr9I/g7qdsxoW4+3HFgNoCBAxEYzWg7NzN54VyMq8YmTG3DIkIcN91Ftm6MWx geIBzezkIGqdhosBQGdsphMgbj/lNb/cwFY9QE/H7Z0qexD1RdDuUkRiKAlCL39u6fOM DdvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721594926; x=1722199726; 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=L7LVNr8us0rPoxnzrOpnxSp3WfE6uBkH0axRvl0juGI=; b=Rx36Mx1CPsJFGV1ieTdRF+1LEvY2+j7PEhQM9rdmWzU/OWS+5nFu4Trw9mSq6sN6ce UqAicybW2N7bhYS/JyVgSCe44o2+82+oZLY791/Rm/aRAMJ8jj+UkaR1ZK0B4rgscVbi XBpX20HjZLvvc/wuy3HXsKTo2ZvA9CkcR9BM50N/N5nauDalRfqW1wpz+Q21ljs0fOzA 2CrXfv2KqnG3Apuailga1Q0r4NoRQOdXd8s+jUUeKIbcpB3+gfZFKT0AeDJbO7zK3Wo4 q5pFW4Gh9YimpCUznYjnOdPZCI8YlkUehu2qh1+P+PHK/kWHYWM1QSbygjnoqZOhHRcp 3O5g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVC38UcKsIXJNi5GLTf+czm8+XI+E2OBooy2IetwI6VpcBWWJLCJACbhKtgrBDq1s+PE77zix42P5YJtoy/8l9cI+nlqHQ= X-Gm-Message-State: AOJu0Yz8R9XWoLoNlRM59jiCkvMcJAQXebZ265RMFlr9MeFFnRQec19J +e0tIHElePkzoqYnshUhSz9JT6br4hr/72ZWa1WxT5k/caqwBaCw X-Google-Smtp-Source: AGHT+IG/pfY1FhMB9sf0SkzXLwud3X5MIjjV62iZnmZ3Dib1mg1iWz9ILg3i964Ji0/DSza2+Nnsfg== X-Received: by 2002:a05:6214:20e2:b0:6b9:60ad:a9e2 with SMTP id 6a1803df08f44-6b9610d4385mr73291726d6.11.1721594925686; Sun, 21 Jul 2024 13:48:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6820:447:b0:5b2:73ec:2f15 with SMTP id 006d021491bc7-5d51a2447bbls3648342eaf.0.-pod-prod-09-us; Sun, 21 Jul 2024 13:48:43 -0700 (PDT) X-Received: by 2002:a05:6808:23c9:b0:3d9:21d0:dda9 with SMTP id 5614622812f47-3dae614185amr124260b6e.5.1721594923833; Sun, 21 Jul 2024 13:48:43 -0700 (PDT) Received: by 2002:a05:6808:984:b0:3d9:302f:bb85 with SMTP id 5614622812f47-3dadf171cc4msb6e; Sun, 21 Jul 2024 13:25:35 -0700 (PDT) X-Received: by 2002:a17:90b:1b01:b0:2c9:79d3:a15d with SMTP id 98e67ed59e1d1-2cd274a9f7dmr3700969a91.29.1721593534198; Sun, 21 Jul 2024 13:25:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1721593534; cv=none; d=google.com; s=arc-20160816; b=CuTLpdF32s9zBVI5DCHyL05lQJookC+0f8QvTR0cioqfus/WphnzZGezxTPARDAIgH pM1ekjEcF5xBqxIuiDKa+klZcU46UGtOJefVJb9qd2c3e3yOcxxSl8LB7AaVmxYJ82a3 +N9JzZpEELVBfHejoUgC6nNQ+6YIwTIRBQoChQTxgPgIUnIJXlyOSyHPt8iZeo9VFnH4 re7W4qHgp913cHvfrXXp0eHHqoB7RMRZkqseBRW92oUGBcFdvX8sjOXdzIgKRw3BJJFL sf2XQ9mb/uTpWVOeGbO73lSKLJI6EoOEemnGgbv1W5qv4emXaT2J3seCH3C2tTqV4ay+ UOhA== 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=M2NSwNjrJLjVaBnWZJozdLz9acGXRNk6L28B78eoHSs=; fh=qAkUFgesXJOBZlEhHhc6qjOrC9x9vwcQK9K5cSmyNz0=; b=koG7nyylvIaTUDyhTLmTxFO+h4FI2PLvk/hIyy0HxSE7eXeGvZmBuikn7JQrZAyiMT ct8ilT2HxdlerNnDZRvntOQ2Z3BiQyI13Oz+ba0B/v2IqiH+gj2/+10JUfCr5EdrK3dc vKQs5poayhxBCpinoGO1Q2FbqzSYP3E0LC64jFxEhPZlwAffu+Br6UNBWDrPbMV2BkPx fUR+rve8WgMYJNKpnmBQT/7sIa7Kf1JINy+1G8g/xu2Uo9ogTcEej4jE9ddgguBUjYix Q/akheMLXCfs5qVxYEXgtx1CRb7vRyGA3J6UQ24GO9Un8mmLz35ZeAWotNz9kk4e8hxW 80EA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=P8+xYI3l; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fout7-smtp.messagingengine.com (fout7-smtp.messagingengine.com. [103.168.172.150]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-2cb76a64e4asi374667a91.0.2024.07.21.13.25.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jul 2024 13:25:34 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 as permitted sender) client-ip=103.168.172.150; Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailfout.nyi.internal (Postfix) with ESMTP id 7F6D8138009E; Sun, 21 Jul 2024 16:25:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 21 Jul 2024 16:25:32 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheehgddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd erredttdejnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepfffggfdtgeevjefhteffieduledugf egtdetgeehjeeuueeuueeiuedtueduueegnecuffhomhgrihhnpehpvghtvghrthhouggu rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 21 Jul 2024 16:25:31 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id C95B65F83F; Sun, 21 Jul 2024 20:25:25 +0000 (UTC) Date: Sun, 21 Jul 2024 20:25:25 +0000 From: Peter Todd To: "David A. Harding" Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="f6QbCljwwUF5QVIU" 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=P8+xYI3l; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.150 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 (/) --f6QbCljwwUF5QVIU Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote: > On 2024-07-20 05:03, Peter Todd wrote: > > What other "free" relay attacks can you think of that were fixed? >=20 > The two you mention were the two I had in mind. Right. So in the entire history of Core, we have two quite ridiculous free relay attacks that got fixed, and we *added* a significant free-relay vulnerability by adding mempool expiration. We also added a free-relay vulnerability, and a fill-and-dump vulnerability, with the mempool size lim= it. That's not evidence that Core actually cares much about "free" relay. > > Did you actually read my One-Shot RBFR proposal? >=20 > Yes. It didn't provide any examples of RBFr free relay and I wanted to > see whether a basic RBFr free relay attack would use significantly more, > significantly less, or about the same amount of bandwidth per dollar > spent as other free relay attacks. My conclusion is that it's about the > same. Good. So you basically agree with me that RBFR does _not_ significantly cha= nge the status quo. I'll respond to the specifics of your RBFR analysis separately; it does *no= t* apply to one-shot RBFR. > > Weak blocks are not a solution to any of the "free" relay attacks I've > > disclosed and your source does not claim that they are a "free" relay > > solution. >=20 > It does not explicitly say that, but it does say: "bonus use-cases: > =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-c= ompatible but > violate anti-DoS rules". >=20 > For example, in some of the scenarios you describe, the attacker sends > an appealing transaction to miners and then sends less appealing > versions of that transaction to relay nodes. If the appealing > transaction enters the top mempool and gets included in a weak block, > relay nodes will stop relaying less appealing variations minutes to > hours before they otherwise would. Yes, "minutes to hours". Transactions relay on the order of seconds to tens= of seconds. Weak blocks simply aren't relevant. Also, the attacks I've described are ones that can be pulled off by having = a tiny minority of hash power mine a double spend. Weak blocks don't help you there, as that tiny minority isn't likely to even find a weak block. > Weak blocks also provide a decentralized DoS-resistant mechanism for > voluntarily communicating all sorts of information from miners to other > miners and relay nodes. That makes them an excellent tool for resolving > any attack that depends on miners and relay nodes having a divergent set > of transactions. For weak blocks to be a solution, you at minimum need to take away the abil= ity of miners to choose what transactions they mine. For example, consider the scenario where you do a "free" relay attack by broadcasting transactions th= at OCEAN rejects, and then double-spending them via OCEAN _after_ the transact= ions have been broadcast. Equally, you'd need to take away the ability of RBFR miners to do the revenue maximizing thing: mining RBFR replacements. I'll also second Antoine Riard's objections to this class of idea in genera= l: you're really proposing a secondary pseudo-consensus mechanism to solve the problems in your first pseud-consensus mechanism. > > 1) Have you've read my One Shot RBFR proposal? In particular, my > > analysis of DoS attacks *including* existing DoS attacks like > > simultaneous broadcast. > >=20 > > 2) Do you agree or disagree with me that these existing DoS attacks > > are real? >=20 > Yes, I've read your proposal, and I agree those attacks are plausible. > In my mind, the major difference between those free relay attacks > and RBFR free relay attacks is how solvable they are. >=20 > I think it's easy to sketch a significant mitigation to all free relay > attacks (including RBFR): >=20 > - Reduce the maximum size of both relayable transactions and in-mempool > packages, e.g. from 100,000 vbytes to 1,000 vbytes. >=20 > - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB. >=20 > - Increase the default mempool feerate floor, e.g. from e.g. from 1 > sat/vb to 100 sat/vb. >=20 > That would break relay of many existing presigned transactions, > potentially leading to money loss, and would break other existing > usecases, not to mention introduce other problems. However, I think > it's sufficient to prove that a mitigation to free relay is possible > without rendering the network unusable. The irony here is you've almost described a _good_ mitigation to "free" rel= ay attacks: just reduce the size of the default mempool. A big reason why we h= ave "free" relay attacks right now is because we allow transactions to be broad= cast that are uneconomical to mine; if you limit transaction broadcast to transactions that are economical to mine in the near future, relay is more expensive. For miners, you can make a decent argument that they want to have on-hand a= big backlog of transactions in case mempools empty out; in my conversations wit= h miners almost all of them claim they run with much larger than default memp= ools (eg >1GB). I've even discussed mempool emptying attacks and RBFR in this context with miners: they didn't think they were an issue as replacing thei= r mempools was absurdly expensive. Fee estimation of course can make use of knowing what backlog of transactio= ns exist. But I'm sure only a small minority of nodes do fee estimation. A variant of this solution would be to just pick the minimum relay fee to b= e some number N blocks worth of transactions "back" from the highest fee-rate= tip of the mempool. Obviously, this will be easier to implement with a cluster mempool, and requires package relay for the CPFP case. > Of course, an ideal solution wouldn't require placing any additional > constraints on mempool policy. For the case of free relay due to > divergent mempool policies, maybe it's something that could be done with > transaction set reconciliation (~erlay), functions for allowing Erlay (and transaction set reconciliation in general) does not help you reconcile conflicting transactions. It simply lets you efficiently learn ab= out the total set of known transactions. Notice how the Erlay is based on WTXID= s, and the BIP doesn't even talk about dealing with conflicts. > independent nodes to come to consistent conclusions about the best > revenue set of transactions (~cluster mempool), That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of situations. That's one reason why in my discussions with miners/pools, they= 're interested in implementing it (mining pools have very low profit margins, s= o every cent counts, and RBFR replacements are reasonably common already). Mi= ning pools implemented full-RBF against the wishes of Core for the same reason: full-RBF earns you more revenue, and I made it easy to implement. Implementing one-shot RBFR is probably going to be quite a bit cleaner with cluster mempools, as it'll provide a nice way to rapidly determine what the minimum economic fee-rate is to get into the next (N) blocks. (though you c= an do this in a less clean way by just periodically assembling a trial block a= nd recording the value, or using the fee estimation code) Finally, why are clusters even relevant to "free" relay? Most "free" relay attacks don't even need transaction packages. The really boring and unsolva= ble "free" relay attack of simply broadcasting large transactions that conflict with small ones is done with single transaction packages. > P2P relay of non-obvious > cluster linearizations[1], and miners voluntarily committing to their > mempool contents in candidate blocks and P2P relaying those commitments > in weak blocks. As I explained above, weak blocks is not a "free" relay solution. > Innovations like that don't work for RBFR. If mempool policy is kept > the same, free relay attacks with RBFR remain equally effective no > matter what mechanisms we implement to improve preconsensus consistency. I could also argue that magic ponies will solve "free" relay. We have to we= ight that hope with the likelyhood it will happen; none of the technical advancements you have mentioned even come close. Anyway, I'll reply to the rest of your other email separately. --=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/Zp1utYduhnWf4oA4%40petertodd.org. --f6QbCljwwUF5QVIU Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmadbqwACgkQLly11TVR LzfEuA//Vua35mgw1JMzh3drOYzEdP/59EpLDMGmcAsfNBoYfM+oEKsCpgtbv71K u1XF1C83DonGutMHnPVzRbQiQ7fx6MBI8gaY+5hU4XY9hyBBsWhSnXW3c+UVvEj6 pvhsvU+ceB5DCsNnGVNHssxKw8XIGMI3+RZIqC+l9NsjXn6xe7296DUgE1p0tcR/ SS0krPd+hoFVFBiEjQMopDEjHhmFOznIJlkNmYnfMT8nhVCgGmZBsVEi5+c1b0LL WbZpaoWqXdKbr0mZ3Wsr0nGnkXhvQme5bBe1nOBhSMexcpIEC1686Y0MIcXMWzsJ S2U3KuUHn9i56RFGJ79OIxn5vrbXOBmxFcB3gDxgn7hnnGX3j+es2ZKoHinwTl97 yLanngdwQc8P+uU70K9ZgAoDh9Iu3BNbvAD0Rs3qFaHG+kAOZQBfnHRUXizfwGCn EvasTpTPNQvtz5jnKe1dI9Z8fyxN5YKUjC7fagyzXrXtfOfLQOb6lCiVTTdyn1h8 5S/eN6v5X3TZ7aTdflOYcMIy8p2vlLjb6urW/afsX6e2Sv65AoRX81EdXTj6AHXf wbfOZikjgshWediIHVNufZdlW438RAhnJIgpzg5XCqzWZmQgRIlWpreinNHyobDr oQ/UrXSJNbFOKgoCwKmYfPFb9TUGz6sOvCosBrjXzBN7xUcXwm0= =V5E8 -----END PGP SIGNATURE----- --f6QbCljwwUF5QVIU--