path: root/57/e2b1ae3c3c67b3998a6e60b395696635149067

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D3127C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <xms:iZ-UZd94A7Ed40kYged940MOvEuPRtDQ3T8d12XJOCILGsn8rBdr7A>
 <xme:iZ-UZRvtnJRechgEJNpDeLNa3pE9mNOHR-mKe8cLRhvp0z-5jE1XPLxN4LSQjajO9
 j-_hcqw7DyDbJgWuzA>
X-ME-Received: <xmr:iZ-UZbCOGzr96_QmDlY437zlQeUuDhuF9-A0hNVaVYj_u2i7RdvASTv10g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeggedgudefucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvfevuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeelvdellefftddukeduffejgfefjeeuheeileeftdfgteduteeggeevueethfej
 tdenucffohhmrghinhepphgvthgvrhhtohguugdrohhrghenucevlhhushhtvghrufhiii
 gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvgesphgvthgvrhhtohguugdr
 ohhrgh
X-ME-Proxy: <xmx:iZ-UZRdNEe-5FQhCUOeVgQhBkV4OpxIAi0uEq-eBJfoc5GCHAySoMg>
 <xmx:iZ-UZSNBGJUuktYR1AXr_uoquETJ8RMoUrETHSS2IKDRnMD-I3muWQ>
 <xmx:iZ-UZTnKAy0WkrO7pIvbQVLZbVrDUUxdRIqQV5goPReAk6FhfhqfuQ>
 <xmx:ip-UZfq-txHUgOo4kY05mruASTs1ItoXepYmxwk1X7wJWzY5fz8Nyg>
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 <pete@petertodd.org>
To: Gloria Zhao <gloriajzhao@gmail.com>
Message-ID: <ZZSfhQ3KD1uK8T45@petertodd.org>
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
 <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
 <ZYNFK5V5e9PnT9eL@petertodd.org>
 <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
 <ZYNYgBovvwodqSuZ@petertodd.org>
 <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="V/rGWnEjcmJbv4Cz"
Content-Disposition: inline
In-Reply-To: <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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.

<snip, replied to in another email>

> 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--