Date: Tue, 30 Jan 2024 05:07:16 +0000
To: Peter Todd <pete@petertodd.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <FPf9XHCyxV96ABG154D8WapYmEE8XVFWqpQXBXz7p21xjdOk1Ho_lC4IpUznFbhleS7g_kKhUqsU0gtMT06_zo6B9heKyHfp1P1zfMWkjmA=@protonmail.com>
In-Reply-To: <Zbh9Qqk2jK0tqKgp@petertodd.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
 <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
 <Zbh9Qqk2jK0tqKgp@petertodd.org>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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


Sent with Proton Mail secure email.

On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <pete@petertodd.org> =
wrote:

> On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
>=20
> > Peter Todd proposes to sign multiple versions of offchain transactions =
at varying feerates.
> > However, this proposal has the issue that if you are not the counterpar=
ty paying for onchain fees (e.g. the original acceptor of the channel, as p=
er "initiator pays" principle), then you have no disincentive to just use t=
he highest-feerate version always, and have a tiny incentive to only store =
the signature for the highest-feerate version to reduce your own storage co=
sts 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 f=
ees be
> taken from the side choosing to sign and broadcast the transaction. Which=
 is
> essentially no different from CPFP anchors, where the side choosing to ge=
t the
> transaction mined pays the fee (though with anchors, it is easy for both =
sides
> to choose to contribute, but in practice this almost never seems to happe=
n in
> my experience running LN nodes).

There is a reason why I mention "initiator pays", and it is because the cha=
nnel opener really ought to pay for onchain fees in general.

For example, I could mount the following attack:

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 exi=
sting LN node.
5.  I retire my new node forever.

This forces the victim node to use its commitment tx.

If the onchain fee for the commitment tx is paid for by who holds the commi=
tment tx (as in your proposal) then I have forced the victim node to pay an=
 onchain fee.

This is why the initial design for openv1 is "initiator pays".
In the above attack scenario, the commitment tx held by the victim node, un=
der "initiator pays", has its onchain fee paid by me, thus the victim is no=
t 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 Lig=
htning, but at least more of the onchain fees (the fees to unilaterally clo=
se the channel with the now-dead node) is paid by the attacker.

On the other hand, it may be possible that "initiator pays" can be dropped.
In this attack scenario, the victim node should really require a non-zero r=
eserve anyway that is proportional to the channel size, so that the attacke=
r needs to commit some funds to the victim until the victim capitulates and=
 unilaterally closes.
In addition, to repeat this attack, I need to keep opening channels to the =
victim and thus pay onchain fees for the channel open.

So it may be that your proposal is sound; possibly the "initiator pays" adv=
antage in this attack scenario is small enough that we can sacrifice it for=
 multi-fee-version.

I should note that under Decker-Russell-Osuntokun the expectation is that b=
oth counterparties hold the same offchain transactions (hence why it is som=
etimes called "LN-symmetry").
However, there are two ways to get around this:

1.  Split the fee between them in some "fair" way.
    Definition of "fair" wen?
2.  Create an artificial asymmetry: flip a bit of `nSequence` for the updat=
e+state txes of one counterparty, and have each side provide signatures for=
 the tx held by its counterparty (as in Poon-Dryja).
    This lets you force that the party that holds a particular update+state=
 tx is the one that pays fees.

> > In addition, it is also incentive-incompatible for the party that pays =
onchain fees to withhold signatures for the higher-fee versions, because if=
 you are the party who does not pay fees and all you hold are the complete =
signatures for the lowest-fee version (because the counterparty does not wa=
nt to trust you with signatures for higher-fee versions because you will ju=
st abuse it), then you will need anchor outputs again to bump up the fee.
>=20
>=20
> That is also incorrect. If the protocol demands multiple fee variants exi=
st,
> the state of the lightning channel simply doesn't advance until all requi=
red
> fee-variants are provided. Withholding can't happen any more than someone=
 could
> "withhold" a state by failing to provide the last byte of a commitment
> transaction: until the protocol state requirements have been fufilled in =
full,
> the previous state remains in effect.

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

If you can build the multi-version proposal with both sides contributing fe=
es or with the one exiting the channel paying the fee, then this variation =
is unnecessary and you can ignore this paragraph.

Regards,
ZmnSCPxj