Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7ADEFC0037 for ; Wed, 20 Dec 2023 21:11:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 2AE3461099 for ; Wed, 20 Dec 2023 21:11:39 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2AE3461099 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=Bxz3HDwz X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgr-zgbN0UYv for ; Wed, 20 Dec 2023 21:11:38 +0000 (UTC) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by smtp3.osuosl.org (Postfix) with ESMTPS id C12A361063 for ; Wed, 20 Dec 2023 21:11:37 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org C12A361063 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C3D6C5C07BB; Wed, 20 Dec 2023 16:11:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 20 Dec 2023 16:11:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1703106691; x=1703193091; bh=tmErTbPXai6GqyGx9rBJtWCQjqZ9 lXnY4OFrhf8ZpD0=; b=Bxz3HDwz0I/nRnMl1feNTWr484oWTSiYuP+u7qGo/9VR ovo31O8y2mBpcHoAu0TAojr9+K+KBA7RQfeqxm467apyqQkid2prWyBlghI/Nejb YuftvnxsC3fgl8WefbwzUu0ph74nwyiaSGWCnFTlf6kJKhKVnfkL59fQO+VrYPTZ /0GRmgRTrBzhKMe8q6yZDrEPkt13v/tS2Vqic/qZ0Dx+TtScUussVdmCUjiifNqz z4dxS+kEjQqC4VXs/01yCSrkm7vHRhvCua4a1E14IYDN6IaHXXNlwJWg5oUM9Z6q NCrvKuBz8/0jQm15WEh/fx2QtcGWHbwzkMQpbL8Naw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduvddgudeghecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehgtdorredttddvnecuhfhrohhmpefrvght vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth htvghrnhepfefgieegffeugfffgfefffdtieegkeehtdefgfdtieejgfevteettddukedv gffgnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvg hrthhouggurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomhepphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Dec 2023 16:11:31 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 68A8A5F84E; Wed, 20 Dec 2023 21:11:28 +0000 (UTC) Date: Wed, 20 Dec 2023 21:11:28 +0000 From: Peter Todd To: Greg Sanders Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="q0iLX+HWYyGFjg7I" Content-Disposition: inline In-Reply-To: Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2023 21:11:39 -0000 --q0iLX+HWYyGFjg7I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote: > Hi Peter, >=20 > Thanks for taking the time to understand the proposal and give thoughtful > feedback. >=20 > With this kind of "static" approach I think there are fundamental > limitations because > the user has to commit "up front" how large the CPFP later will have to b= e. > 1kvB > is an arbitrary value that is two orders of magnitude less than the > possible package > size, and allows fairly flexible amounts of inputs(~14 taproot inputs > IIRC?) to effectuate a CPFP. Why would you need so many inputs to do a CPFP if they all have to be confirmed? The purpose of doing a CPFP is to pay fees to get another transaction mined. Unless you're in some degenerate, unusual, situation whe= re you've somehow ended up with just some dust left in your wallet, dust that = is barely worth its own fees to spend, one or maybe two UTXOs are going to be sufficient for a fee payment. I had incorrectly thought that V3 transctions allowed for a single up-to 10= 00vB transaction to pay for multiple parents at once. But if you can't do that, = due to the restriction on unconfirmed inputs, I can't see any reason to have su= ch a large limit. > I'd like something much more flexible, but we're barely at whiteboard sta= ge > for alternatives and > they probably require more fundamental work. So within these limits, we > have to pick some number, > and it'll have tradeoffs. >=20 > When I think of "pinning potential", I consider not only the parent size, > and not > only the maximum child size, but also the "honest" child size. If the hon= est > user does relatively poor utxo management, or the commitment transaction > is of very high value(e.g., lots of high value HTLCs), the pin is > essentially zero. > If the honest user ever only have one utxo, then the "max pin" is effecti= ve > indeed. Which is the situation you would expect in the vast majority of cases. > > Alice would have had to pay a 2.6x higher fee than > expected. >=20 > I think that's an acceptable worst case starting point, versus the status > quo which is ~500-1000x+. No, the status quo is signed anchors, like Lightning already has with anchor channels. Those anchors could still be zero-valued. But as long as there is= a signature associated with them, pinning isn't a problem as only the intended party can spend them. Note BTW that existing Lightning anchor channels inefficiently use two anch= or outputs when just one is sufficient: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December= /004246.html [Lightning-dev] The remote anchor of anchor channels is redundant Peter Todd, Dec 13th, 2023 --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --q0iLX+HWYyGFjg7I Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWDWH4ACgkQLly11TVR Lzec0g/6AxYkVbsqn4ggDFJaf9cjNDMK0CSImUbZGis+enzrLEOSOzXQanW4Z3xG A5oMLhXiDdZEiBDLbppbRwhahLMZ2OFkZ4ZQtsSIO0hgzYeljz4vbuKC3i5jtu84 OBz3m+TqvuIiPUwVmB7pKd77okPsDMdy8EN5f10rr+YT7RZgiYiOr8IRQiKL+EVg O8Po0ms7WrLz6W0C8s0zNDGgOEeKVUjPhSEWracaHCASioptvTeH8UWnMsxwqlin 2YNKSp5DFvokLPNWpCU9uOCmuQPk6pc8Hn/CpPOuz18qPouoIUjkpyF3Erx+kFaD ryIl4rjzSIWJuTxPGrXlMoxEG88SZboLKDmHTBOBwYh1OykpXzgjJG+hLsSkH9gG mgjMdal4eFOQiqQQObEnu0mhQQl44hkqOtsD5JFHT53ruY/4bbV/kL9CEyghVwGC mx+Gn4D55k8zgvF1ACwtTZLI63McAI9IT8Tn3F6IkvTsCLIFOhVMA+HwEx4WMpy4 /+f5Oi+xAzpCfUltTyZhEyHp+G5+g/5xffrrgD4mBpgaML6i7lZkIYVfmipCNO8z 4ljZnCCme/xXF0GZUV2l3wdbXVXL/ioCUunlj+SAciT9KRzsWpvhKCJHUkng418R OJaiDG3+IwYSSvYgNRGJbZjtwuNf48h6bzkGuH4SQcImZZ6hcEc= =Yt7F -----END PGP SIGNATURE----- --q0iLX+HWYyGFjg7I--