Good morning Michael et al,
>
> I assume that a CTV based LN-Symmetry also has this drawback when compared 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 market fee
> rate was at the time of the update. In today's pre LN-Symmetry world you are
> always going to have justice transactions for revoked states that were
> constructed when the market fee rate was very different from the present
> day's market fee rate.
This is the same in the future Decker-Russell-Osuntokun ("eltoo" /
"LN-Symmetry") 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 specific
feerate today, and if the counterparty is offline for some time, the market
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 diverge
tremendously from the last signed feerate.
Anchor commitments Fixes This by adding an otherwise-unnecessary change output
(called "anchor output") for both parties to be able to attach a CPFP
transaction.
However, this comes at the expense of increased blockspace usage for the anchor
outputs.
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 counterparty
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 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 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 want to trust you
with signatures for higher-fee versions because you will just abuse 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 for
paying the fees.
However, this may require that both parties always bring in funds on all
channel 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 definition
of "fair" (how to define "fair" may be problematic --- do they pay equal 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 nested
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
multi-feerate *in addition to* multi-feerate the outer transaction (e.g.
commitment transaction in Poon-Dryja) resulting in a O(N * N) transactions for
N feerates?
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
