Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
On Tue, Jan 30, 2024 at 05:17:04AM +, ZmnSCPxj via bitcoin-dev wrote: > > > I should note that under Decker-Russell-Osuntokun the expectation is that > > both counterparties hold the same offchain transactions (hence why it is > > sometimes 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 > > update+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. > > No, wait, #2 does not actually work as stated. > Decker-Russell-Osuntokun uses `SIGHASH_NOINPUT` meaning the `nSequence` is > not committed in the signature and can be malleated. BIP 118 as at March 2021 (when it defined NOINPUT rather than APO): ] The transaction digest algorithm from BIP 143 is used when verifying a ] SIGHASH_NOINPUT signature, with the following modifications: ] ] 2. hashPrevouts (32-byte hash) is 32 0x00 bytes ] 3. hashSequence (32-byte hash) is 32 0x00 bytes ] 4. outpoint (32-byte hash + 4-byte little endian) is ]set to 36 0x00 bytes ] 5. scriptCode of the input is set to an empty script ]0x00 BIP 143: ] A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program: ] ] Double SHA256 of the serialization of: ] ... ] 2. hashPrevouts (32-byte hash) ] 3. hashSequence (32-byte hash) ] 4. outpoint (32-byte hash + 4-byte little endian) ] 5. scriptCode of the input (serialized as scripts inside CTxOuts) ] ... ] 7. nSequence of the input (4-byte little endian) So nSequence would still have been committed to per that proposal. Dropping hashSequence just removes the commitment to the other inputs being spent by the tx. Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
On Tue, Jan 30, 2024 at 04:12:07AM +, 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 signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Sent with Proton Mail secure email. On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd wrote: > On Tue, Jan 30, 2024 at 04:12:07AM +, 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). There is a reason why I mention "initiator pays", and it is because the channel 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 existing 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 commitment 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, under "initiator pays", has its onchain fee paid by me, thus the victim is not 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 Lightning, but at least more of the onchain fees (the fees to unilaterally close 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 reserve anyway that is proportional to the channel size, so that the attacker 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" advantage 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 both counterparties hold the same offchain transactions (hence why it is sometimes 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 update+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 > > 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. No, I am referring to a variation of your proposal where the side paying the fees in "initiator pays" gets full signatures for all feerate-versions but 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 fees or with the one exiting the channel paying the fee, then this variation is unnecessary and you can
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
> I should note that under Decker-Russell-Osuntokun the expectation is that > both counterparties hold the same offchain transactions (hence why it is > sometimes 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 > update+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. No, wait, #2 does not actually work as stated. Decker-Russell-Osuntokun uses `SIGHASH_NOINPUT` meaning the `nSequence` is not committed in the signature and can be malleated. Further, in order for update transactions to be able to replace one another, the amount output of the update transaction needs to be the same value as the input of the update transaction --- meaning cannot deduct the fee from the channel, at least for the update tx. This forces the update transaction to be paid for by bringing in an external UTXO owned by whoever constructed the update transaction (== whoever started the closing). Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
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
Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
Hi Peter Interesting post. By implicitly committing in advance to the fee paid by the spending transaction CTV is certainly nailing its colors to the CPFP mast rather than operating in a RBF world. And in a future high fee environment (ignoring whatever is driving those high fees, monetary or non-monetary use cases) as you state paying for an additional CPFP transaction is suboptimal rather than just replacing an existing unconfirmed transaction. I did a cursory search to look for an in depth technical comparison of CPFP and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [0]. In that he states his view that: "If most nodes didn't enforce mandatory BIP125 signalling, RBF would be superior in all aspects to CPFP from the perspective of the emitter of transaction. CPFP is much less efficient, and not always possible: you need the transaction to have a change output and (at least at the time of writing [0]) the parent to pass policy checks on its own, for instance if it's below the minimum feerate of most mempools on the network you won't be able to CPFP it at the moment." 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. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-cpfp-and-bip125-for-fee-bumping -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev wrote: > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > transaction that can spend an output. Namely, # of inputs, # of outputs, > outputs hash, etc. In practice, in many if not most CTV use-cases intended to > allow multiple parties to share a single UTXO, it is difficult to impossible > to > allow for sufficient CTV variants to cover all possible fee-rates. It is > expected that CTV would be usually used with anchor outputs to pay fees; by > creating an input of the correct size in a separate transaction and including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get > transactions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have at > least one UTXO of suitable size to pay for those fees. > > This requirement for all users to have a UTXO to pay fees negates the > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a UTXO, > CTV requires each user to have an extra UTXO. The only realistic alternative > is > to use a third party to pay for the UTXO, eg via a LN payment, but at that > point it would be more efficient to pay an out-of-band mining fee. That of > course is highly undesirable from a mining centralization perspective.(2) > > Recommendations: CTV in its current form be abandoned as design foot-gun. > Other > convenant schemes should be designed to work well with replace-by-fee, to > avoid > requirements for extra UTXOs, and to maximize on-chain efficiency. > > 1) > https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0119.mediawiki > 2) > https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ > bitcoin-dev mailing list > bitcoin-...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
