From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Michael Folkson <michaelfolkson@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
Date: Tue, 30 Jan 2024 04:12:07 +0000 [thread overview]
Message-ID: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com> (raw)
In-Reply-To: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com>
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
next prev parent reply other threads:[~2024-01-30 4:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 19:31 [bitcoin-dev] " Peter Todd
2024-01-25 12:57 ` Michael Folkson
2024-01-30 4:12 ` ZmnSCPxj [this message]
2024-01-30 4:38 ` [bitcoin-dev] [Lightning-dev] " Peter Todd
2024-01-30 5:07 ` ZmnSCPxj
2024-01-30 5:17 ` ZmnSCPxj
2024-01-30 5:55 ` Anthony Towns
2024-01-30 8:40 ` Peter Todd
2024-01-25 17:49 ` [bitcoin-dev] " jlspc
2024-01-30 4:49 ` Peter Todd
2024-02-20 23:13 ` [bitcoindev] " 'jlspc' via Bitcoin Development Mailing List
2024-01-27 6:28 ` Brandon Black
2024-01-30 4:46 ` Peter Todd
[not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>
2024-01-30 4:41 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
--cc=michaelfolkson@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox