path: root/a7/40f3c5eb8a7d4d69d9651f07af6e425b0f4d41

Return-Path: <pete@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 03D8DC0032;
 Tue, 14 Nov 2023 19:50:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id C016E40972;
 Tue, 14 Nov 2023 19:50:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C016E40972
Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm1 header.b=uwUwuaff
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id XynFBU9z_wal; Tue, 14 Nov 2023 19:50:12 +0000 (UTC)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28])
 by smtp4.osuosl.org (Postfix) with ESMTPS id E1C874096D;
 Tue, 14 Nov 2023 19:50:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org E1C874096D
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id A14865C0274;
 Tue, 14 Nov 2023 14:50:07 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute2.internal (MEProxy); Tue, 14 Nov 2023 14:50:07 -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:sender:subject
 :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; t=1699991407; x=1700077807; bh=MaXJBOr8R+dCa
 NSp3GPPXBDNuWs4/GNfSjoKX8Cr2mE=; b=uwUwuafft/WLP5eJO6wt3z4s3L6+z
 BRacChu0vncDG+n4qXAoFF+HhL04VKbcN8y+D+qdundSzxpZE2zyGU4BuXVKoTC5
 84vabKgRy4VGnVNmEGbBz1ToWS0ml0mFEZx/RlnYVRTuqgbj9YSK5ZvFBIHYvJma
 nbl4PNEnmtm2l0kNyLWj+Hb/OJhqPDxQy2mOLERMRs6FkCU6ZIULF5LFuAB+lt2o
 c5GKJT25nOkQW8G9DyOBmXBNy+7u6z2por6NfxF05mtdcbNeXvYZD3wYZ3PrRZq9
 OUbL2Q5ti+2TIO7mTeMRItwXO2lQJJkNv3M19DBowgQT77QJ3kopGuGNw==
X-ME-Sender: <xms:b89TZRJNOAT4I01NkVKLPifOKXL2G3CW1Y5yMjP3P-6ot2sy06817w>
 <xme:b89TZdIYxVHKlolPsZo9u2qB06lKeq06C9VaCUyBAbQDRUd67wpjeLawzFqrQYFkm
 qpD4Wlur9744vFjE2s>
X-ME-Received: <xmr:b89TZZuVMNpBoqWsK0nxXcHyPGgjE-hQCpYEYQwWV0Y479NqZqXv6dFGxw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeffedgfeekucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhepfffhvfevuffkfhggtggujgesghdtroertddtvdenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeefgfeigeffuefgfffgfefftdeigeekhedtfefgtdeijefgveettedtudekvdfg
 gfenucffohhmrghinheplhhinhhugihfohhunhgurghtihhonhdrohhrghdpphgvthgvrh
 htohguugdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
 fhhrohhmpehpvghtvgesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:b89TZSZh4CbDO3nldDzy08sPpjnWBTyUWGp7jsv67wI67lm1mf4Kig>
 <xmx:b89TZYZFHeTs1YOXscuKmpGqkN3fjohepN9wJIMyPh3JAVQNqzWdSw>
 <xmx:b89TZWCaWzkgC1fOqegd_VAzgp1CvaROb3-LQNlzTCEl5X8Hg_QwHw>
 <xmx:b89TZXzpyElMy0aVxn9IycygDUsk7t_E-4I1Ph0azIi_YnFKsEBZZg>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 14 Nov 2023 14:50:06 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 9D04F5F82A; Tue, 14 Nov 2023 19:50:04 +0000 (UTC)
Date: Tue, 14 Nov 2023 19:50:04 +0000
From: Peter Todd <pete@petertodd.org>
To: Antoine Riard <antoine.riard@gmail.com>
Message-ID: <ZVPPbNdmPxahOGqA@petertodd.org>
References: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com>
 <CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com>
 <ZUrbk9a9jiL87pxd@petertodd.org> <ZUrtHyQBOEZTM3Bj@petertodd.org>
 <CALZpt+FEwjwQQWY6TBFuWeZbqC6Ywa7eSTcpqYuQPZ6+6QBzaw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="NYUiNwSwe5WSdZas"
Content-Disposition: inline
In-Reply-To: <CALZpt+FEwjwQQWY6TBFuWeZbqC6Ywa7eSTcpqYuQPZ6+6QBzaw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making
 HTLCs Safer by Letting Transactions Expire Safely
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, 14 Nov 2023 19:50:14 -0000


--NYUiNwSwe5WSdZas
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2023 at 02:18:16AM +0000, Antoine Riard wrote:
> Your two latest mails.
>=20
> > The problem that OP_Expire aims to solve is the fact that Carol could
> prevent
> > Bob from learning about the preimage in time, while still getting a
> chance to
> > use the preimage herself. OP_Expire thoroughly solves that problem by
> ensuring
> > that the preimage is either broadcast in the blockchain in a timely
> fashion, or
> > becomes useless.
>=20
> I respectfully disagree - There is a more general underlying issue for
> outdated states in multi-party off-chain constructions, where any "revoke=
d"
> or "updated" consensus-valid state can be used to jam the latest off-chain
> agreed-on, through techniques like replacement cycling or pinning.

No, that's not a general underlying issue. You've found two separate issues.

Furthermore, revoked states are clearly different than HTLCs: they're
fraudulent, and thus in punishment-using protocols they are always associat=
ed
with high risks of loss if they do in fact get detected or mined. There's
probably tweaks we can do to improve this security. But the general princip=
le
there is certainly true.

> > My suggestion of pre-signing RBF replacements, without anchor outputs,
> and with
> > all outputs rendered unspendable with 1 CSV, is clearly superior: there
> are
> > zero degrees of freedom to the attacker, other than the possibility of
> > increasing the fee paid or broadcasting a revoked commitment. The latter
> of
> > course risks the other party punishing the fraud.
>=20
> Assuming the max RBF replacement is pre-signed at 200 sats / vb, with
> commitment transaction of ~268 vbytes and at least one second-stage HTLC
> transaction of ~175 vbytes including witness size, a channel counterparty
> must keep at worst a fee-bumping reserve of 35 268 sats, whatever payment
> value.

For a lightning channel to be economical at all in a general routing
environment, the highest likely fee has to be small enough for it to repres=
ent
a small percentage of the total value tied up in the Lightning channel. Tyi=
ng
up a small percentage of the overall capacity for future fee usage is not a
significant expense.

> As of today, any payment under $13 has to become trimmed HTLCs.
> Trimmed HTLCs are coming with their own wormhole of issues, notably making
> them a target to be stolen by low-hashrate capabilities attackers [0].
>=20
> [0]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-May/002714=
=2Ehtml

That attack doesn't make sense. HTLCs go to fees at a certain feerate. In a
normal environment where there is a constant supply of fee paying transacti=
ons,
the profit for the miner is not the total HTLC value, but the increase in
feerate compared to the transactions they had to give up to mine the commit=
ment
transaction.

Second, it's obvious that the total trimmed HTLCs should be limited to what
would be a reasonable transaction fee. A situation where you have 80% of the
channel value going to fees due to a bunch of small HTLCs is obviously
ridiculous, and to the extent that existing implementations have this issue,
should be fixed.

For RBF fee bumping, obviously you can take the increased channel fees from=
 the
party choosing to broadcast the commitment transaction.

> > This does have the practical problem that a set of refund transactions
> will
> > also need to be signed for each fee variant. But, eg, signing 10x of ea=
ch
> isn't
> > so burdensome. And in the future that problem could be avoided with
> > SIGHASH_NOINPUT, or replacing the pre-signed refund transaction mechani=
sm
> with
> > a covenant.
>=20
> I think if you wish to be safe against fees griefing games between
> counterparties, both counterparties have to maintain their own fee-bumping
> reserves, which make channel usage less capital efficient, rather than
> being drawn from a common reserve.

Yes, obviously. But as I said above, it just doesn't make sense for channel=
s to
be in a situation where closing them costs a significant % of the channel v=
alue
in fees, so we're not changing the status quo much.

> > Using RBF rather than CPFP with package relay also has the advantage of
> being
> > more efficient, as no blockspace needs to be consumed by the anchor
> outputs or
> > transactions spending them. Of course, there are special circumstances
> where
> > BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, =
eg
> by
> > reducing the replacement relay fee, or by delta-encoding transaction
> updates.
>=20
> It is left as an exercise to the reader how to break the RBF approach for
> LN channels as proposed.

Do you have a concrete attack?

> > As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing
> both it
> > and OP_Expire could make sense.
>=20
> I think there is one obvious issue of pre-signing RBF replacements combin=
ed
> with LN-symmetry, namely every state has to pre-commit to fee values
> attached and such states might spend each other in chain. So now you would
> need `max-rbf-replacement` *  `max-theoretical-number-of-states` of
> fee-bumping reserves unless you can pipe fee value with some covenant
> magic, I think.

No, you are missing the point. RBF replacements can use SIGHASH_NOINPUT to =
sign
HTLC refund transactions, removing the need for a set of different HTLC ref=
und
transactions for each different feerate of the commitment transaction.

I'm making no comment on how to do RBF replacements with LN-Symmetry, which=
 I
consider to be a broken idea in non-trusted situations anyway. Removing jus=
tice
=66rom Lightning is always going to be hopelessly insecure when you can't at
least somewhat trust your counterparty. If your usage of LN-Symmetry is
sufficiently secure, you probably don't have to worry about them playing fee
games with you either.
=20
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--NYUiNwSwe5WSdZas
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmVTz2kACgkQLly11TVR
LzdmOA//VGalabwbbsi2SZe5DrtPsud4nwI+Kbe0u562FkYoIa2mubmkZ3HpTAkW
li9OXSBZnzB+HhNFhPqFRKtj0BrIwQoxLy3IOJPbFZTA7yUFCHjIy+Om87Xjl4Zj
yXlrvwdSxbOMH9fNq1ItWC3OgMwqhUQNVfnr0UgJGLUjr8tSlMOKagaWI4v/+QMP
cMQ+E9g0JvBJPwyBMTBkJJ0Dr9YXimx+ookzDYO63lLB++wqgQ5A5vv6oEX491dq
v4LrRQw2XIzgoW03gJ0AARHuOiNybkboiJe+KHyffeYrLLCHwZdVgL89cF3cAIVE
YqPHixMT8OP0OxUdjueVJ6NLebkoz9kXGzO66mTMi1XdwLNyChTr7R7PtKs9mgtf
Btt619CKCMYIyQ6W7JaHyrVqXIR37mzKwL00L/Lsjwe/aR5UTefvRCJNxhSEVstJ
TcSPmbnOmcZSUyM9TW6nbY1iPaEXXBs7EzS6Vo9Hara+qLZez63oz6fNa3R1d2gf
Jj88CgbfyQ1hmkatSjXXo60orMu5R5JsrvtTlEDHL/7kagwjz4wZc/i/yzukkXN3
0gPGAAbxtqZFTcvK25Vv0ggUPuwv5KC7TvY63+21IzwGCO2x4RIReqpexok6pJXM
6ezSOycsUd+CndYCCjAYlETRCtsS2Qud8SS+IAkEXeA5XYaAllM=
=RvmN
-----END PGP SIGNATURE-----

--NYUiNwSwe5WSdZas--