From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3127C0037 for ; Tue, 2 Jan 2024 23:43:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8E12660BEB for ; Tue, 2 Jan 2024 23:43:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8E12660BEB 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=B6N/++xO 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 8SU_RbuaD8SL for ; Tue, 2 Jan 2024 23:43:07 +0000 (UTC) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by smtp3.osuosl.org (Postfix) with ESMTPS id 8CEAD60B78 for ; Tue, 2 Jan 2024 23:43:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 8CEAD60B78 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7835A5C0172; Tue, 2 Jan 2024 18:43:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 02 Jan 2024 18:43:06 -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=1704238986; x=1704325386; bh=+fJbdUCxqUVkxvw+qPZWEIEWaqcl RjTU+uTXwrP0V4A=; b=B6N/++xOzHdUNLRnKw0l1NwQTF+vd8ZY68cwYzcJiO50 oOiRe2rm/6o20LXLomHBQZqQPiI3kj4h/YV06W3Jm3/qdXfRo3k8Z940QsKUYaZA IXLM/uti9bssyQASkVbMw++yptlW/LGUbc1hg5qX+TiK3yZoWt77spu1lqG4kuuO u83sTwYbqXtN/RHjc0BMDKKJj4tMMYZb4SrUSoB0C6x6DDBFklHb99kaJIW+YQqv zjd0BLC99KCMyG0pU7sG/X5mO0i9gyu1UQXmCYT0lYuY/54msZh53E1UGLK0sXRp /TnLXboNEB/UCkOXshkiSDzSMtG/42hE0KxIUru5lg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeggedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr ohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Jan 2024 18:43:05 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 152B35F81D; Tue, 2 Jan 2024 23:43:01 +0000 (UTC) Date: Tue, 2 Jan 2024 23:43:01 +0000 From: Peter Todd To: Gloria Zhao Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="V/rGWnEjcmJbv4Cz" Content-Disposition: inline In-Reply-To: Cc: Bitcoin Protocol Discussion , Greg Sanders 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: Tue, 02 Jan 2024 23:43:08 -0000 --V/rGWnEjcmJbv4Cz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 02, 2024 at 11:12:05AM +0000, Gloria Zhao wrote: > Hi Peter, >=20 > > You make a good point that the commitment transaction also needs to be > included > > in my calculations. But you are incorrect about the size of them. >=20 > > With taproot and ephemeral anchors, a typical commitment transaction > would have > > a single-sig input (musig), two taproot outputs, and an ephemeral anchor > > output. Such a transaction is only 162vB, much less than 1000vB. >=20 > Note that these scenarios are much less interesting for commitment > transactions with no HTLC outputs, so 162 isn't what I would use for the > minimum. > So, I apologize for not using a more accurate minimum, though I think this > helps illustrate the 100x reduction of v3 a lot better. > While I think the true minimum is higher, let's go ahead and use your > number N=3D162vB. > - Alice is happy to pay 162sat/vB * (162 + 152vB) =3D 50,868sat > - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB)= + > 152 =3D 80,152sat > - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 =3D *29,284s= at* > more > - In a non-v3 world, Mallory can make the cost to replace 80sat/vB * > (100,000vB) + 152 =3D 8,000,152sat > - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 =3D *7,94= 9,284sat > *more (maxed out by the HTLC amount) >=20 > As framed above, what we've done here is quantify the severity of the > pinning damage in the v3 and non-v3 world by calculating the additional > fees Mallory can force Alice to pay using Rule 3. To summarize this > discussion, at the lower end of possible commitment transaction sizes, > pinning is possible but is restricted by 100x, as claimed. Also, you're writeup is still missing a very important point: existing Lightning anchor channels solved pinning by having a CHECKSIG. Only the par= ties with the right to spend the anchor channel can do that, and all other outpu= ts are unspendable until the commitment transaction confirms. So the question is not whether or not V3 transactions can improve pinning compared to a hypothetical protocol with vulnerabilities. The question, for Lightning, is how much better or worse V3 transactions would be than the st= atus quo. So far, they look like the difference is marginal at best, quite possi= bly worse. Now, with other protocols, maybe we could make an argument that V3 transact= ions is worthwhile and for those protocols no other solution is possible. But you have not attempted to make that argument in the documentation provided in y= our pull-req(s). --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --V/rGWnEjcmJbv4Cz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWUn4MACgkQLly11TVR LzfAoA//TVf7PNzDxhIYJpL5WefCbdR6/fGxs7qbRsjrnB8b5SMrJtZzcsJ8oW8H t0d2h/en1n5H9ChtPlXyCNRjWsMAO757iWrt/e+ovN/u2G6/9mPmc/269p2OIXsb 9i5+Wqw9E55Fw2w321YmBBILni/bcFkNDOB/bvzlQD9UC7ccjqs/cdFSty9DWD7d 0rTIt3DqiM8on7DZRSUeVe4n+4F6fj5ZkMrIL89ynGc0G9GYzkW/KaQZbWiWD9uQ u9TLB/B5bERv6muuhyDBUXledx59+bAAU6wv5K8nj2BANryaBEnuzu0bBQeNcDhl hklLbajMMZ7SA6p4RNyPmysftELss0HnEEm4xvtmtpLpeCfNR7JBO6pjUhgTyC2A Wi3jno+mlst2cGdHl3cCHzf7to6UtoK891U15bQdHMtuKg/FLAJchbTa+210gjAE 5LDdOJ6MqgU0DZLWE/riRVP79FBBzNIkcz9WKxKPYBe7n6XOobV8QzhrqEWb0med HJWxCz6hGrTBn5uzjF/UbqvrEK4xrhdG9RT3VYSCJbWDrTUvqbT2L+3ljcD7Sw2s PCDnUCNrZaRibpTbiJ583V/8VBd+P2pcT0NOp9hOvRHzye/HCCHe6aLH50G5Upg8 O3Wts2tIwGY9Z8zE26kB/pm4q1a5OKiJSwEMYckEAy2d0argxZE= =65O9 -----END PGP SIGNATURE----- --V/rGWnEjcmJbv4Cz--