Feedback-ID: i525146e8:Fastmail
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
Precedence: list


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