Date: Tue, 30 Jan 2024 04:12:07 +0000
To: Michael Folkson <michaelfolkson@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
In-Reply-To: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
 <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
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

Good morning Michael et al,

>=20
> I assume that a CTV based LN-Symmetry also has this drawback when compare=
d to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry =
could change the fees in every channel update based on what the current mar=
ket fee rate was at the time of the update. In today's pre LN-Symmetry worl=
d you are always going to have justice transactions for revoked states that=
 were constructed when the market fee rate was very different from the pres=
ent day's market fee rate.

This is the same in the future Decker-Russell-Osuntokun ("eltoo" / "LN-Symm=
etry") world as in the current Poon-Dryja ("LN-punishment").

Every *commitment* transaction in Poon-Dryja commits to a specific fee rate=
, which is why it it problematic today.
The *justice* transaction is single-signed and can (and SHOULD!) be RBF-ed =
(e.g. CLN implements an aggressive *justice* transaction RBF-ing written by=
 me).

However, the issue is that every *commitment* transaction commits to a spec=
ific feerate today, and if the counterparty is offline for some time, the m=
arket feerate may diverge tremendously from the last signed feerate.

The same issue will still exist in Decker-Russell-Osuntokun --- the latest =
pair of update and state transactions will commit to a specific feerate.
If the counterparty is offline for some time, the market feerate may diverg=
e tremendously from the last signed feerate.

Anchor commitments Fixes This by adding an otherwise-unnecessary change out=
put (called "anchor output") for both parties to be able to attach a CPFP t=
ransaction.
However, this comes at the expense of increased blockspace usage for the an=
chor outputs.

Peter Todd proposes to sign multiple versions of offchain transactions at v=
arying feerates.
However, this proposal has the issue that if you are not the counterparty p=
aying 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 h=
ighest-feerate version always, and have a tiny incentive to only store the =
signature for the highest-feerate version to reduce your own storage costs =
slightly.
In addition, it is also incentive-incompatible for the party that pays onch=
ain 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 sign=
atures for the lowest-fee version (because the counterparty does not want t=
o trust you with signatures for higher-fee versions because you will just a=
buse it), then you will need anchor outputs again to bump up the fee.

The proposal from Peter Todd might work if both parties share the burden fo=
r paying the fees.
However, this may require that both parties always bring in funds on all ch=
annel opens, i.e. no single-sided funding.
I have also not considered how this game would play out, though naively, it=
 seems to me that if both parties pay onchain fees "fairly" for some defini=
tion of "fair" (how to define "fair" may be problematic --- do they pay equ=
al fees or proportional to their total funds held in the channel?) then it =
seems to me okay to have multi-feerate-version offchain txes (regardless of=
 using Poon-Dryja or Decker-Russell-Osuntokun).
However, there may be issues with hosting HTLCs; technically HTLCs are nest=
ed inside a larger contract (the channel) and if so, do you need a separate=
 transaction to resolve them (Poon-Dryja does!) and do you also have to mul=
ti-feerate *in addition to* multi-feerate the outer transaction (e.g. commi=
tment transaction in Poon-Dryja) resulting in a O(N * N) transactions for N=
 feerates?


Regards,
ZmnSCPxj