path: root/d0/4eaeb1277385acd3f7cf66c94d238931330b5f

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5FFA0C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 08:40:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1EB0761007
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 08:40:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1EB0761007
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=fm3 header.b=Rndx//zL
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 euYSbG9z4RHO
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 08:40:46 +0000 (UTC)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com
 [66.111.4.26])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5A7D660B2D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 30 Jan 2024 08:40:46 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5A7D660B2D
Received: from compute7.internal (compute7.nyi.internal [10.202.2.48])
 by mailout.nyi.internal (Postfix) with ESMTP id 223635C0151;
 Tue, 30 Jan 2024 03:40:45 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
 by compute7.internal (MEProxy); Tue, 30 Jan 2024 03:40:45 -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=
 fm3; t=1706604045; x=1706690445; bh=RwpxA2Q/nTE29nEigKlHzbNxmwBf
 SyvkhQDhAzx4ABU=; b=Rndx//zL7PfT/9lSaTbb2BllXmGYbakk1slcbWND0KUN
 w9T/6h9y25gkmvHlR3l+rOOlWkc0r4gy2dK7iSM0tU/kAQQ2snmLPOprETC7jmD9
 i+G19iVqOJINUmEyR5nMWQx9Kz/G0U0djUVS00WiDPE+L/Qu6zy2MLuEomeGTj1w
 k76qGnU6cSF/oShcz7oqeVqKx8D3YBL84ekDBSESfo59yOIm8bZZSLMfuZok3jGj
 EPTEElFvRBufu/JLgbS+bG6Pqc3XCYZF1ETxRQaGXRs12nTIVx0BBM45ZNt5onUe
 RgaKPBz8gHxfVl6DLvhm4CibD24aB/WyNxlBe/Anvw==
X-ME-Sender: <xms:DLa4ZXMzDs-6wwLwPLgNwhqYhQEccZ3N71Bp0EV-ffs0okarE851jw>
 <xme:DLa4ZR9WP1vLiU4VeYo8zXB68nzhTVsERoEWd4E-rRFRun-uZrOUouVZgF82bMtO7
 NSJfM3GQIFtPlmTlfw>
X-ME-Received: <xmr:DLa4ZWTdS_9iqd65WNTk7tNtms1mbK0dVelIKefYII7lcLJGPGmT0NBrnkuU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedguddvtdcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvght
 vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth
 htvghrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefh
 jedtnecuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuih
 iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggu
 rdhorhhg
X-ME-Proxy: <xmx:DLa4ZbuHSPEiFBLxopBdphtH1HqHW3t3uNBFiKX9gTkAf_SZcWBUIw>
 <xmx:DLa4ZfeQe2z9TBxzKKV1QC38wbcVhBAassVQqozUw6RPLVIDko1IFQ>
 <xmx:DLa4ZX0_dYsmzygm-j6OhsbdyobuwXuQqEq6pOvPJhwnK7CP1mPYlw>
 <xmx:Dba4ZXRbi8pQEosBbpOZ-HXrqoWMBrt2N7LBo0uuPWquy1FxXxKUVQ>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 30 Jan 2024 03:40:44 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
 id 805645F849; Tue, 30 Jan 2024 08:40:41 +0000 (UTC)
Date: Tue, 30 Jan 2024 08:40:41 +0000
From: Peter Todd <pete@petertodd.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Zbi2CcSb7cQjqMQk@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
 <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
 <Zbh9Qqk2jK0tqKgp@petertodd.org>
 <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="u0msnDstTrEyrYit"
Content-Disposition: inline
In-Reply-To: <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org,
 Lightning Dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not
 Scale Due to UTXO's Required For Fee Payment
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, 30 Jan 2024 08:40:48 -0000


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

On Tue, Jan 30, 2024 at 05:07:16AM +0000, ZmnSCPxj wrote:
> Sent with Proton Mail secure email.
>=20
> On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <pete@petertodd.org=
> wrote:
>=20
> > On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
> >=20
> > > Peter Todd proposes to sign multiple versions of offchain transaction=
s at varying feerates.
> > > However, this proposal has the issue that if you are not the counterp=
arty paying for onchain fees (e.g. the original acceptor of the channel, as=
 per "initiator pays" principle), then you have no disincentive to just use=
 the highest-feerate version always, and have a tiny incentive to only stor=
e the signature for the highest-feerate version to reduce your own storage =
costs slightly.
> >=20
> >=20
> > You are incorrect. Lightning commitments actually come in two different
> > versions, for the local and remote sides. Obviously, I'm proposing that=
 fees be
> > taken from the side choosing to sign and broadcast the transaction. Whi=
ch is
> > essentially no different from CPFP anchors, where the side choosing to =
get the
> > transaction mined pays the fee (though with anchors, it is easy for bot=
h sides
> > to choose to contribute, but in practice this almost never seems to hap=
pen in
> > my experience running LN nodes).
>=20
> There is a reason why I mention "initiator pays", and it is because the c=
hannel opener really ought to pay for onchain fees in general.

You make a good point that Lightning channels *should* work that way. But e=
ven
right now they do not: Lightning commitment transactions pay a fixed, gener=
ally
low, fee-rate just high enough to propagate (and often lower) and are expec=
ted
to be brought up to full fee-rate via the anchor outputs.

Either side can pay the fees using the anchor outputs. And in practice, it's
quite common for the initiator to *not* pay the supermajority of the fees.

Furthermore, the proposals floating around for V3 transactions and Lightnin=
g is
to double-down on this design, with the commitment transaction paying no fe=
es
at all and anchor outputs (and CPFP) being always used.

> For example, I could mount the following attack:
>=20
> 1.  I already have an existing LN node on the network.
> 2.  I wait for a low-feerate time.
> 3.  I spin up a new node and initiate a channel funding to a victim node.
> 4.  I empty my channel with the victim node, sending out my funds to my e=
xisting LN node.
> 5.  I retire my new node forever.
>=20
> This forces the victim node to use its commitment tx.
>=20
> If the onchain fee for the commitment tx is paid for by who holds the com=
mitment tx (as in your proposal) then I have forced the victim node to pay =
an onchain fee.

Again, Lightning channels *right* now work this way too. I personally have =
done
steps #1 to #5 the other day on the same laptop I'm writing this email on. =
Due
to a glitch in channel closing, the cooperative close failed, and at the mo=
ment
the recipient has a 10sat/VB commitment transaction with a fee below most
mempools' minrelayfee. Their balance was ~2 million sats, and my local bala=
nce
was just ~20k sats, and the commitment transaction was signed with the defa=
ult
10sat/vB fee, which is well below the minrelayfee, let alone competitive.

If the receipient wants their ~2 million sats any time soon they're going to
have to CPFP the commitment transaction to get it up to about 30sat/vB, at
which point they've paid the supermajority of the cost even though they're =
the
receipient. Personally, I've shut down that node for good (I archived .lnd)=
 and
I'll check back in a month or two to see if they ever get their funds.

> This is why the initial design for openv1 is "initiator pays".

=2E..and that design clearly went out the window with anchor channels.

> In the above attack scenario, the commitment tx held by the victim node, =
under "initiator pays", has its onchain fee paid by me, thus the victim is =
not forced to pay the unilateral close fee, I am the one forced to pay it.
> They do still need to pay fees to get their now-onchain funds back into L=
ightning, but at least more of the onchain fees (the fees to unilaterally c=
lose the channel with the now-dead node) is paid by the attacker.
>=20
> On the other hand, it may be possible that "initiator pays" can be droppe=
d.
> In this attack scenario, the victim node should really require a non-zero=
 reserve anyway that is proportional to the channel size, so that the attac=
ker needs to commit some funds to the victim until the victim capitulates a=
nd unilaterally closes.
> In addition, to repeat this attack, I need to keep opening channels to th=
e victim and thus pay onchain fees for the channel open.
>=20
> So it may be that your proposal is sound; possibly the "initiator pays" a=
dvantage in this attack scenario is small enough that we can sacrifice it f=
or multi-fee-version.

No, RBF channels have nothing to do with whether or not the "initiator pays=
".

If you want to have the RBF concept, and initator pays, you just need to
negotiate a minimum fee rate that you take out of the initiators balance. T=
hat
aspect of the design is orthogonal to how exactly the rest of the fees are
paid, and the concept of negotiating a minimum fee for the commitment
transaction to pay is relevant to all forms of anchor channels too.

> No, I am referring to a variation of your proposal where the side paying =
the fees in "initiator pays" gets full signatures for all feerate-versions =
but the other side gets only the full signatures for the lowest-fee version.

=2E..and no-one is proposing that variation for the obvious reason that the
receipient has no incentive not to use the full fee-rate every time.

Indeed, a hypothetical CPFP version of this variation would have the exact =
same
incentive issue.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmW4tggACgkQLly11TVR
LzfNXxAAkmKQC4vp3a36lWROKi6J1Z9ew9Nu6Py8uBSsVr0FqioJ8NqitKlR64kk
WeHNlkI3JkITliuX3eKSxJAsidN73XfSXWauGn5SyHCj9LNbLmOXgBbSMF+Vdqiz
YhJgDlW3ZuGP81n1JjIkfNDs2o9vU5ghLE1kb/73z3Vos9MbnNXmhwHlEkITSg0f
bVpVmj0euV/x/OzZSJ1a8fBNMWMvQKGaF8bDLVPScyZeMq8HxIbqfQT5feXqxv5P
YuVQ8dTRG6+Ytg5/5BrOHJGuOl46QJuQ2EzkE8hFGbOwNvhLsGR3ChbUDKNj1D1m
7hp7zDNu29ZeAZOkIiv6TtTSDozsJ/XOIcjjkHPghCDY6bhnrl1e7kj191zbswXg
a3FziO51Hcp1a19Z0fl0O7VWGIap/Asxg0og2cHb93PuYUmqtfANpSzkwPnS0D8s
MBMvQhCDaN4CJCkcXuWFVtTYSoFA7xjh5odxSqDQoyM/HwIKkQTfElSKdnMhoYW7
gNG7sQhCb5d5tN5VVMu9ZoQCPZCCoHc4ku58pyqSosRNlzGvNevKcVvMHC9EQYyH
yMkYP/VeOYGlUlAOxTc2NaX70pkFopqCh4e7Dt/0oH2l/xcQWNh+tTSnzlPXCLcg
c2khfCzsOl2HzUjVcpYHJXu6NPRFALykZkA1E504sjIeHCgqssQ=
=5f6Q
-----END PGP SIGNATURE-----

--u0msnDstTrEyrYit--