From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5FFA0C0037 for ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfedthedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpefrvght vghrucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrth htvghrnhepledvleelffdtudekudffjefgfeejueehieelfedtgfetudetgeegveeutefh jedtnecuffhomhgrihhnpehpvghtvghrthhouggurdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehpvghtvghrthhouggu rdhorhhg X-ME-Proxy: 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 To: ZmnSCPxj Message-ID: References: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com> <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@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: Cc: bitcoin-dev@lists.linuxfoundation.org, Lightning Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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--