Delivery-date: Thu, 28 Mar 2024 07:58:29 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rprD2-0004Au-QZ for bitcoindev@gnusha.org; Thu, 28 Mar 2024 07:58:29 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-229f4995573sf915588fac.1 for ; Thu, 28 Mar 2024 07:58:28 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1711637903; cv=pass; d=google.com; s=arc-20160816; b=q61o5NyRQseUapoOirRQ67WyOt+a6hToZvY+THOUI+fQ4RzGJzqxbCJdXMAibm6QKx ELvTk4OM3q5JvrbyhxSY8DcmwOKmCGdRmCLIg8B0KYeS91NqEn7LUCn2il3jGIai9A8A GIne+AasWal/Hmkpe/Pt9DvOUTKBXBR8oAEA023DayX2fTeNaP9LiqvW9Q+4eqv4Qjxn U/OsjX1wwj5XWtw04sko08Q2IG4jZOyq1emno/HfYYdykPnfUXc/QG1JkWboGIY40I3A psebmPyQLvwtQl8lszdb8iwSl/WuvTr84a9Ap+rn7TsG1ZoVhx4SdBPbTELxmiQa8ZXF TtGA== 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=9Fx8AAht2TORL/d2+41/Df9ZqP6TZujF0eEGKeSNpqc=; fh=x2YIrW7YkvaLK9irUrCMBW9qLnCqGySJyCPKvGwDTt4=; b=B+gfzadlGnvjbTgiqLuwdQtgltetdqUlTlql6THV4a+idx5nPz5lp7ujT6pbtD2sGD n75YDRpf8WhMAW1URFQNR80sfx9zYWhJEB9MgEFr3Vk+bIvq6777OQBSUD/K0pz6dNIu rXoD+rBZ7C6dEpnvMZOXjfIlbwfNpdzh6KJn0VdHCQXM6OwgswoIg317j7YtCUsywMBS qEY2BRh/dA+MUC70yVE3LInER/u0a+nWhyHq9+CNazq3xNsipr2nZJ/+W6fSTAEaeDvK AI4Ro5dK2SXTzd08wDoT7fFFbXTiLsQZSYrP/vU2NzlcTbOQYqhOAwvfArrinL6RMTx+ qqlA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=E0mYFOIq; spf=pass (google.com: domain of pete@petertodd.org designates 64.147.123.144 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1711637903; x=1712242703; 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=9Fx8AAht2TORL/d2+41/Df9ZqP6TZujF0eEGKeSNpqc=; b=DAJROnyhueZBbm3vd9su3tlPuIy2RAmuaWWzs+CApXECvlMwRbN50GKoAemPMyE1yd p/INyT46c6MVSajL2j0h9lVcPkvYViDtXXKfmgllImYvY5oLTWVtrWiCkvI7XczOEzUC NJtiJfoggvL19AncXF7cecThdINmmwspR45PXshUD+0nkr1oswYGsFpGkMn3Kz3b+edM BDSkMs5R/X3G91O+ChpStW8YJUjYZ+94w7WE7G+yvjJXR8bsesNs179VxkbE3ukifVJv bZaK/S8Djend/m05IfhvV4YGIB0sBefKWMJ6qjqawc8RJVBagPdhisE3rSxRddzG4ErM ekVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711637903; x=1712242703; 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=9Fx8AAht2TORL/d2+41/Df9ZqP6TZujF0eEGKeSNpqc=; b=EE0ywNrPjb5uUMrPIRVzUBMj5bUaEh6eBhPDrHbjnji5cm1Po6IIGlSgY7HmglnDkp JowOWc9gNaQ0ZxpSoMOy9+LMyTd38zyHY2sNod80lFCQXwuhOB8F2qWymJ+qIxQiX3Dx A724MwsGlX/PORAgYMGZGLbnefCkiO8Sv3c+aHbv2B7OiYX9XANRw/llUz3hg5Mvnr6h IfG08LfIlTnzaleIKB7Gz8EgIPsGUJR/6IRrBdkxALFufSl5jSojZbiRzhgfCBhO8iox PCsqT6cgY7W8KLY+h0YwWKxpnnef4pqVMzSipUY49n9N2WByjKGlp308Mukt0DxLkyGR e0UQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVJOEEteUHDo5TAdJ765OF8B5Epf6ucZHvj5bYdY7JikGcj5JPvvWDhnCdln40/zPxnxDhNpfKtLmT7SH6kpSAdhwJgedU= X-Gm-Message-State: AOJu0Yx43MGaSymPEyvYHRW0F0l7oAJ1zFktqkpGtb8rlXhHe/6v39oN tifXAyxZcMBSoAMr0a1csPnqHPo+6c9oCJqzq/bxFn/8QvBkkmgonpg= X-Google-Smtp-Source: AGHT+IG1YNp8sCfWj+fMvjMc9wRSTHMt8L82Xh+WG2aVozIw4TYstWKEAs/46fRFpijmHBlnFf88xw== X-Received: by 2002:a05:6870:4629:b0:220:8c16:fe1b with SMTP id z41-20020a056870462900b002208c16fe1bmr3166064oao.40.1711637902719; Thu, 28 Mar 2024 07:58:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6870:be92:b0:22a:62fa:314f with SMTP id nx18-20020a056870be9200b0022a62fa314fls375638oab.2.-pod-prod-08-us; Thu, 28 Mar 2024 07:58:22 -0700 (PDT) X-Received: by 2002:a05:6870:65a4:b0:21e:917a:1430 with SMTP id fp36-20020a05687065a400b0021e917a1430mr73358oab.5.1711637901954; Thu, 28 Mar 2024 07:58:21 -0700 (PDT) Received: by 2002:a05:6808:19a3:b0:3c3:cc75:72a7 with SMTP id 5614622812f47-3c3de8ca926msb6e; Thu, 28 Mar 2024 07:27:26 -0700 (PDT) X-Received: by 2002:a05:6e02:1d84:b0:366:99ee:f14a with SMTP id h4-20020a056e021d8400b0036699eef14amr3220022ila.22.1711636045853; Thu, 28 Mar 2024 07:27:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1711636045; cv=none; d=google.com; s=arc-20160816; b=dG0Od5ie4jQL9et/d40uJpblbjhhc24DabJs7/vVJfLyUR7gKMofhWpYwAR79Iy88I xzWkp88iAxW0EZtKjgXo17rdfeARhwjQRfwEWa8GM+CgP2K+LqlE+h2FMvpN5IOJZYk3 7Qpi1Qe6c1ZARkVX4dx6frNaas01FfgspPStyjtDN8vRUBrP3vVgUnZVAYtdnKWJgVgI ewQ6tmCxqWRxvs7GAACJ12YIcQJUBd3Kl6bozrfZrtSX2lKWKrafrn0gjv91GOdABVIV O2iROWPpypShJEHYZdTSlROGlgIqOMxhUpUgF7RRpHcL8tDCvBhFHcQSA31LZ8ttQcP7 vkmA== 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=XS2sWnXhFP4W3vuBUaxVOQuomv57q+McRqdpU959ink=; fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=; b=oHc7BlQy2JiVMMABcH3ZhZfR0HbVx/tG6bLw0qijawvWo9mB+EM2+cUv5g53QKunw1 RGBImlbKM8C+eQAPeGfOuCJ/TKQ4UmcxnR+uRNorKQjx0VXCzgYxLOVCSWLhn+NsHJ3S H4zE89eol9QUxtR6kde4/z38PmUirIzkg3vVlVD6pAuTGYUkkrYsaqyh03YVT3O3TM8V HpxrTpaBFkzWg7fuz0STKqUyKGUi6QHnmrMmSPJkU6rbV2s6rLX0J0dEO96JuGErECVv 3k3enPMdRCtAJ0q/FLpZGvMsBVwC7au9hxNo0ebxnSH4BUoNi4WFB+C4oumOyEzP+DgU +xaw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=E0mYFOIq; spf=pass (google.com: domain of pete@petertodd.org designates 64.147.123.144 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from wfout1-smtp.messagingengine.com (wfout1-smtp.messagingengine.com. [64.147.123.144]) by gmr-mx.google.com with ESMTPS id ct3-20020a056e023b0300b0036898b55a0esi108242ilb.4.2024.03.28.07.27.25 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Mar 2024 07:27:25 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 64.147.123.144 as permitted sender) client-ip=64.147.123.144; Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.west.internal (Postfix) with ESMTP id 4EDFA1C000E5; Thu, 28 Mar 2024 10:27:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 28 Mar 2024 10:27:24 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrudduledgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr ohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 28 Mar 2024 10:27:22 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id C44D75F87B; Thu, 28 Mar 2024 14:27:18 +0000 (UTC) Date: Thu, 28 Mar 2024 14:27:18 +0000 From: Peter Todd To: Antoine Riard Cc: Bitcoin Development Mailing List Subject: Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 Message-ID: References: <0a377ddb-b001-41ba-9208-27b3fa059bb5n@googlegroups.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nQsR4l3SVl/46568" 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=fm2 header.b=E0mYFOIq; spf=pass (google.com: domain of pete@petertodd.org designates 64.147.123.144 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 (/) --nQsR4l3SVl/46568 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote: > > I don't believe the other attacks in this attack class are even possible > to > fix. We just have to live with the fact that a degree of free relay is > always > going to be possible. > > See comments under proof-of-UTXO ownership as plausible mitigations. > > In anway, I think this is not the type of fixes we can land in a covert > fashion given the > order of magnitude of engineering effort and potential tx-relay network > impact. Indeed, at this point I strongly suspect had I instead lobbied for a fix privately, given that one obvious mitigation is replace-by-fee-rate, I'd instead just get accused of nefarious behavior for not doing so openly. > > Can you explain in more detail how exactly you'd pull that off? Are you > aware > of LN implementations that actually create feerate ascending LN states? > > I think you can create feerates ascending LN states with today's LN > implementations by playing with BOLT2's `dust_limit_satoshis`. > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... > State N has N dust HTLCs trimmed. Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis` value can be changed on an existing channel. It *should* be possible to change on an existing channel, as the economic dust limit is fee-rate dependent. But the protocol does not support that yet IIUC. > > Imagine if the mempool size was 1TB, an amount larger than the entire BTC > > blocksize to date. I think that example helps make it obvious that with > such an > > enormous mempool, there *must* be free relay attacks, because it's simply > > impossible for all broadcast transactions to even get mined. > > I think there is an interesting distinction that can be made between > mempool size > ressources dedicated to increase block template efficiency and minimum > mempool size > to just ensure you have good BIP152 compact block validation time. > Obviously if you're > aiming for the first, you're incentivized to offer "free-relay" bandwidth > to your peers and > increase your view of the ongoing transaction traffic. There's also a convenience aspect to this: large mempools are convenient for transaction senders, as it allows them to go off line after sending transactions that aren't going to be mined in the near future. If we had a world of purely always-online transaction senders, mempools could be smaller. > > All the existing replacement mechanisms _are_ basically a proof-of-UTXO > > ownership, because they're transactions spending UTXOs. The only question > is > > the details of how that proof works. > > Yeah somehow it's correct that any replacement mechanisms encompass a > proof-of-UTXO > ownership mechanism. Yet in a world you can partition mempool like you show > with your > for example, it's easy to make this proof-of-UTXO economically unpaid by > the attacker. Asking > aged UTXOs attached to a replacement candidate could be make such proof > more robust, in > my understanding. I think you're missing a third aspect to this: # of peers. Modulo economic irrationalities with differently sized txs like the Rule #6 attack, the proof-of-UTXO is almost economically paid even when mempools are partitioned because the bandwidth used by a given form of a transaction is limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of nodes, and TxB to the other 50%, both spending the same txout, the total cost/KB used in total would exactly the same... except that nodes have more than one 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. If the # of peers is reduced, the impact of this type of attack is also reduced. Of course, a balance has to be maintained. I call the Rule #6 attack an economic irrationality because the higher fee-rate transaction should have replaced the low fee-rate transactions: it's the one that got mined, so bandwidth spend on the low fee-rate txs was clearly wasted, and miners lost out on some fees. -- 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/ZgV%2BRk0m4azlbRZP%40petertodd.org. --nQsR4l3SVl/46568 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmYFfj8ACgkQLly11TVR LzdZWg/+N7SHalFTmifKpJ4KaADVlyoGlRFittRIFLzlz6roSp/sQ2c7NJwmfUtH Uulj9V3MPfQZ5PBMc6L5Xhx+fOLD6i1M+P3lMendFPiQAje0SrQOy/n/oW//dR6K AiRrhf6aYkbVygITLgw2oQP2ukfze0ls10YL1ezI/itEKYLoWNHMLNF+RVtl6DMn 14lf9WTadAVUXcs6avbpUNggEYE7w8MYf+zC7tisZKcphdJm6stvLQYZ5yHWVqNM AnOb7ejkL5Y2jFl1urz84f+quqwb1OxUJ6+UkVoKjmVaBL7fcvflOL2+PWWA0H1J HPf9nQSzGUVVk+oBa6yGU8vyw1KyXsFm55LI0KQyqyuOTa81UVUEKM/mONae2ymu oe2xjMKIOfu091O0jxrGDu90iaqS3R1QEPtAE4U4BDcePPsazG39BlvHzhM2Mbxq JM/2FI7EQoXdHE5GETey/ENz7AsvzyepG3QLM65HV6OzLR6rdnZj7sPuJWMZsCTo kn75B/afJmbuV6fO1tKA4tKl091ckPE/P9S/ggp3A6xrNzEMJA2i2BuYgA2Dn7Fg xb5P4D06aZTKXjtwmj7qMaflnbzAsrI68jpzK/pX9JC+RbNwCahF18y9EZ5PK65c t5p6H0Ry/YXpYpGVrz2Fbqe7OLl2lEytiCgtoe5sr3G9SgXlmF4= =wXFE -----END PGP SIGNATURE----- --nQsR4l3SVl/46568--