Delivery-date: Mon, 22 Jul 2024 05:06:52 -0700 Received: from mail-oo1-f59.google.com ([209.85.161.59]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sVroZ-0001Dm-M1 for bitcoindev@gnusha.org; Mon, 22 Jul 2024 05:06:52 -0700 Received: by mail-oo1-f59.google.com with SMTP id 006d021491bc7-5c654141680sf3398601eaf.0 for ; Mon, 22 Jul 2024 05:06:51 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1721650005; cv=pass; d=google.com; s=arc-20160816; b=FcjtWaMzLffezyPxBKoKyyF5WAfOnmIP2I0/dXkg29r76krpyj8ejwFMY+MvcpYjCt +PCv5uxFsHirEtUwIQpvLjCUyKePzPjtJdPtvWqH36O9y6qGkjwOtm1wkOF0CoL/7NF5 /woju5vA+F+3RQ+43R4MU6q8yo6RG9VU8CihmNbEb7Gu7OpKvjBxhXOGFs8UxY4ljsGC wGHQNNtpNUQfZPrfTHoeuPhfLcP3jORzc3SllFqasOEK55KGglJFmhtbb80vuZH/H6qb IVdsiPYQfcpbHki2KzFnOKZDuyW/zG/q8spa1Qie9k4l+qnAupwh/R/nQFaE98Uh4LUO oAKA== 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=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=; fh=mxtM/GxI3WIhY17fb5rwGAZk8FcYZWCDS2+8WgkBWgM=; b=wyFezsIwLi3lHtHDbGlPLdX42oBVu3qPC2oKaHITIE9zVfixiKvKlT5eRZN/fctwpW Iy+42Ebgx4M0SKTGaH/IInomRQ9qJhDudcj2vu+n+GwnqOoRgw1C/1TTAWEaa1uCBMbz +zwN/8Xko2dFh/mevV5xmOwdHUUBnJB5WMvI8TrPstHH1PGioXoAFF7pkk+JjQKAIytS qmuyHzasIedRS7TwYMCaxQyzAF2CwhkpREOKAGQLlbV8dZQlF97Nt9vF93FXAo11pEAg Km8ZBc0NROrp7D99ajhRrO/1g0At9XgHkJLrKzvzsp27/uwLdc8EXFXbKPO1FYBbVEFN PA5g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=fArmyUkT; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1721650005; x=1722254805; 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=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=; b=XVdcn0O4a1puWDP+ShtNZZy4Cdn3L1yqetThIjXKROkJJ/1pQp5/vVip/lmocIdcH9 MkVbJM3pSbQ8G5cy7U6qw982CG+lsHVUUfIBl85zmQmd9lUMBXqjQERT622zIiQgRsOp BcTB1gd43toL8yVeiRJKLB/iQpTF1GUjG9yl6dqgKTw5VSdl+mywIUA18Af3bBfKFnnX Df1ixciHIaxIxXD9eI6VGrKWCep2f3y8GUwZVDhJGebnOO60i7+0+jo8r3Y4QnoDFUuF R+5FHSXqUXcYUQgPk+1cGALeejzOvZy3VqNV51Ugy3RTOivyGkmQaqtJ4mI4FARIbNSG 9vaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721650005; x=1722254805; 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=tYXDsH5arjKv2W50PVtGlpnnwZhIfdC6U6w9XMTeAZ8=; b=V5CQ6MLzlHqcI06N53n5cxRIViZm2d40O3Dbonjr41/EJRvwyL2Xo+Xtu77bUQTAaA Kt9DxzXK9c/wHG1Or6aikST9+7bnwn6CgAFLeF5c2DvYLg6NZK/R2sWGe0S6K8zwKEC9 rWxAYSVZtQq677JyUnrVATBUmmyJ2v7O4SBhhwd0u4U/ZHXL19+Q4SQ+WbNkOGh1KCXS 3bPcoK/QH2iBG2B0Jby3mPzn/YN3n13MpGTrYwUWudOHlU0rheEFH1kmkNYoT7PPeHJa 1vHGr5PzHOiRg/5OlNI82AHAmBVj3D6Dw0Sdnqt0KBXDnf8AuS6k24DelyzZoFvpvKI/ kGbA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVlGpO/mhXzmbT7bhBoVQEgITmiiGSpFUAX2XXW2f2/bejj21wmf+1cBuoJQ40P03lTIJmeAWCUJjUPiVvY/myqiR2sIN0= X-Gm-Message-State: AOJu0YzaZRQFL4FxW10JYV9kkP2iNsxd1Pa1Wr9fcxI/O+5nV3P/CQfw iyR1Uut4pUVsbmouxuV0kb96dbkNNqnudUVizFSQk+XXEcZp5Uyf X-Google-Smtp-Source: AGHT+IF0SgJ3w9VXtmJ9PwbLsbwTV/BodwHHfGlcoub9OW/Dh4OsTrB2C7b7g+14tNOQXCS86ZhT+Q== X-Received: by 2002:a05:6820:1e05:b0:5ce:3ccb:2118 with SMTP id 006d021491bc7-5d564fedb98mr3688157eaf.3.1721650005462; Mon, 22 Jul 2024 05:06:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a4a:e8de:0:b0:5c4:69bc:810f with SMTP id 006d021491bc7-5d51eebf713ls4360523eaf.2.-pod-prod-07-us; Mon, 22 Jul 2024 05:06:43 -0700 (PDT) X-Received: by 2002:a05:6820:810:b0:5cd:4c18:93b2 with SMTP id 006d021491bc7-5d564cfc731mr384397eaf.0.1721650003480; Mon, 22 Jul 2024 05:06:43 -0700 (PDT) Received: by 2002:a05:6808:a09:b0:3d9:2ea5:e56e with SMTP id 5614622812f47-3dadf32f947msb6e; Mon, 22 Jul 2024 04:45:59 -0700 (PDT) X-Received: by 2002:a05:6808:1810:b0:3d9:33e9:e2b9 with SMTP id 5614622812f47-3dae657d6d2mr3744677b6e.24.1721648758484; Mon, 22 Jul 2024 04:45:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1721648758; cv=none; d=google.com; s=arc-20160816; b=CAWGDc9dXZZADiUJRIm6/Z2F0HaJCuoETLA4Y/7yknXjerSATUjk4Je/SpTeqsmVqi yo+0IhtjjfXJnT/jyhxul6iyZsUPnHw1kUbnIA7qYUFSlelHRyl758C1bof/47IRJ5dR YrXhWR5gVzrc1j7Of4V2q1hqVW5IG3L9tBVmBxzd8hTN6ynp0kkWNvmdaHvt8sf9HV2R r/XitqvAxQt3+pNmp2c9v5PRWofbdU5xQ6CE/Sh7mOQhEV2pGvuAR/ufqmbCCEA60Mbc SAd3sgtRuUA1uJeMRcfZDUo+PGTkcJwKJaPhKsZv+XasYv6RxQJttFU8MQKV5QwqMWLX 6W2A== 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=/RN5O/THORAsaf0hvHIxJn2YW1sBZyKbQcJ/QmvFYTQ=; fh=qAkUFgesXJOBZlEhHhc6qjOrC9x9vwcQK9K5cSmyNz0=; b=hJOI4ELd54pt2irR0ofaGAr13hlA2llYhduqLNpX78Hr0mxPnqJnvw1ah+mcOOPG0o ad1jM1RLPfPNp9LY3HSr6qD0YevIs02GXlynP7l757gwimRSE6IOW+4SC9kOpwn5Z9Dm tnoxzxlAg0a1A57g0m52JvlVVz8Lt20q48A+VVWqevq4DRF8pN8GKj5nbL2CY2TvYkJX S/pl+kqDZRF8loSzGTCm69lT3ugZVY2f/sTcxebhMTi8Bx1nSCM+fQ+/cnQ3SmVLXJzQ 5hMN31CO0T7BooFfPckMGxeWmRkfopG0o7ZRVaJ6b1uHDQ979jHzFiFc+WuMkn0pWKMb /OnQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=fArmyUkT; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) smtp.mailfrom=pete@petertodd.org Received: from fout8-smtp.messagingengine.com (fout8-smtp.messagingengine.com. [103.168.172.151]) by gmr-mx.google.com with ESMTPS id 5614622812f47-3dae08d3e89si264392b6e.0.2024.07.22.04.45.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jul 2024 04:45:58 -0700 (PDT) Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 as permitted sender) client-ip=103.168.172.151; Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailfout.nyi.internal (Postfix) with ESMTP id 7DE15138013E; Mon, 22 Jul 2024 07:45:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 22 Jul 2024 07:45:57 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrheejgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddunecuhfhrohhmpefrvghtvghr ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg hrnhepjeetvedvteelvdfgfeeftdekkeekjeffhefhfedugfegheeggeefgefgffehueff necuffhomhgrihhnpegsihhttghoihhnohhpshdrohhrghdpghhoohhglhgvrdgtohhmpd hpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 22 Jul 2024 07:45:52 -0400 (EDT) Received: by localhost (Postfix, from userid 1000) id 3CBE95F83F; Mon, 22 Jul 2024 11:45:31 +0000 (UTC) Date: Mon, 22 Jul 2024 11:45:31 +0000 From: Peter Todd To: "David A. Harding" Cc: bitcoindev@googlegroups.com Subject: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CmiQh1B8k9DSHLU1" 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=fArmyUkT; spf=pass (google.com: domain of pete@petertodd.org designates 103.168.172.151 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 (/) --CmiQh1B8k9DSHLU1 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote: > 3. Limiting the worst-case free relay and excessive mempool eviction > requires additional rules (e.g. one-shot RBFr) that are challenging > to implement and analyze at present, as several devs have noted[3]. > Both implementation and analysis should become much easier if cluster > mempool is deployed (also noted by devs), but the deployment of > cluster mempool requires removal of CPFP carve-out, and removal of > CPFP carve-out requires either the upgrade of thousands of LN nodes > and channels or a drop-in solution (ideally one that can be analyzed > independently from cluster mempool, like TRUC). I'm going to answer this separately for the sake of easy citation in the future. tl;dr: cluster RBFR makes the CPFP carve-out obsolete, fixing pinni= ng for existing implementations; TRUC meanwhile isn't even a drop-in solution,= and requires everyone to upgrade before cluster mempool is even possible. To recap, the CPFP carve-out=C2=B9 is an exception to package size limits t= hat allows a single transaction to exceed those limits slighty, provided that t= he transaction has only one unconfirmed ancestor. This is relevant to protocol= s like Lightning, where your counterparty might try to pin a transaction by spending one of the two anchor outputs with a large, low-fee, transaction s= uch that the total package size is just under the package limit. Notably, in th= is scenario, there is *no* way for you to broadcast a CPFP without the CPFP carve-out because regardless of fee-rate, your transaction will simply be rejected due to it causing the package limit to be exceeded. I won't comment on whether or not the cluster mempool is genuinely incompat= ible with CPFP carveouts; I'm not convinced that's true. But that point is irrelevant anyway. To understand why, let's look at package replacement. Package replacement is the idea that we can do RBF with packages of transactions. For situations where the CPFP carve-out is relevant, we can instead evaluate the CPFP child transaction, and the parent transaction(s),= as a package and compare that package to the package consisting of the existin= g child transaction(s), and the parent transaction. With RBF alone, that woul= d allow you to defeat a package size pin by paying more in fees than the conflicting child transaction(s), reducing this scenario to a straightforwa= rd BIP-125 Rule #3 total fees pin. Actually implementing this type of package replacement is simple: if you receive a single transaction with an unconfirmed parent, if the transaction= is rejected due to package limits, try again, treating it as a package replacement. Finally, with package (one-shot) RBFR, we defeat both the package size pin = and the Rule #3 pin: so long as your CPFP child transaction pays a higher fee-r= ate than the conflicting large, low-fee-rate, child transaction(s) made by the attacker, you can replace the conflict and get the parent transaction(s) mi= ned. The only thing protocols need to do is ensure that the combination of paren= t transaction(s) and child CPFP doesn't itself exceed the package size limits= , which Lightning already does just fine. This is a much better upgrade path than TRUC + cluster mempool. We don't ha= ve to wait for existing Lightning users to upgrade and open new channels. Inde= ed, we even fix existing pinning problems for existing Lightning implementation= s, which RBFR is already=C2=B2 doing!. And we actually fix pinning in general,= for all use-cases, not just the narrow subset that can make use of TRUC. # References 1) https://bitcoinops.org/en/topics/cpfp-carve-out/ 2) https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw --=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/Zp5GW/yHzPB8wyjU%40petertodd.org. --CmiQh1B8k9DSHLU1 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmaeRlkACgkQLly11TVR LzfJLg//Zyljmi4YmcyauyrFs3DYiC1ZCC+zXBOzDOxwiAeLTltdrU7fHX74k1LH LYym7max1fXoRO2rRL7lilDxtg9nW4xUHnpmZ+pmCjjL0xruptw6OkQOgraYyXM2 SN7iCZp+j45pI39j9X0LNx5It6lCnP1TAJzU50sQUj6FC1F0NwPIrbdMc5QTLOE1 og5DfsgU86hDXeeYN+gBpZDEpnPyzNn7nDDM3tILPULTNlddvQ22ecxcYrCoYDdN k9qhzdi3iRitua7nu2NoVzKAr8KWgVJDvo+CD+pY1OD0Q/DfAVxYXQbc9w08HrJN w3iQHK6aW7Q4SI6YFkosTu/0UtjaaeLVFedr1zkn1EmQv542NXT8MpP0Ey6KFpKy HNmmGkGDGWhleTCQm7xpVon2xv4g3UhQVC67bn+2eChtzgbAu4qm90zFUqpueu76 7vUe8kppF9ryf+YrC9Xtj9AgmrUrvK+aCmHkC3fw1hwsQwMCQ3g08/ed+qA4Osj2 5CqJJOycolpOdbH9E4FjLu0SXgw6apasBIG+NJHDrWg8jRYcnUs05+xhcMG7FUUr +Ucdi1/CpKf8TyrH/0u8SWiCQl9a60VQ82kLPVIGQGsHL3FYQ0iL8IFgUc0IY9LC l5srqLtPKRapRuwR9TuwVt7fZ3dOrZlYeasFhjsqS0gziG2BPsc= =3HCN -----END PGP SIGNATURE----- --CmiQh1B8k9DSHLU1--