From: Peter Todd <pete@petertodd•org>
To: ZmnSCPxj <ZmnSCPxj@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:38:26 +0000 [thread overview]
Message-ID: <Zbh9Qqk2jK0tqKgp@petertodd.org> (raw)
In-Reply-To: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2643 bytes --]
On Tue, Jan 30, 2024 at 04:12:07AM +0000, ZmnSCPxj wrote:
> 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.
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. Which 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 both sides
to choose to contribute, but in practice this almost never seems to happen in
my experience running LN nodes).
> 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.
That is also incorrect. If the protocol demands multiple fee variants exist,
the state of the lightning channel simply doesn't advance until all required
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.
> 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?
I covered HTLCs in my blog post on the subject; I would suggest you read it in
full. There are multiple potential options to deal with HTLC feerates to avoid
the obvious N^2 problem:
https://petertodd.org/2023/v3-transactions-review#htlcs-and-replace-by-fee
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-30 4:38 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 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2024-01-30 4:38 ` Peter Todd [this message]
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=Zbh9Qqk2jK0tqKgp@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/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