Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

[Peter Todd]

On Tue, Jan 30, 2024 at 05:07:16AM +, ZmnSCPxj wrote:
> 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.

You make a good point that Lightning channels *should* work that way. But even
right now they do not: Lightning commitment transactions pay a fixed, generally
low, fee-rate just high enough to propagate (and often lower) and are expected
to be brought up to full fee-rate via the anchor outputs.

Either side can pay the fees using the anchor outputs. And in practice, it's
quite common for the initiator to *not* pay the supermajority of the fees.

Furthermore, the proposals floating around for V3 transactions and Lightning is
to double-down on this design, with the commitment transaction paying no fees
at all and anchor outputs (and CPFP) being always used.

> 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.

Again, Lightning channels *right* now work this way too. I personally have done
steps #1 to #5 the other day on the same laptop I'm writing this email on. Due
to a glitch in channel closing, the cooperative close failed, and at the moment
the recipient has a 10sat/VB commitment transaction with a fee below most
mempools' minrelayfee. Their balance was ~2 million sats, and my local balance
was just ~20k sats, and the commitment transaction was signed with the default
10sat/vB fee, which is well below the minrelayfee, let alone competitive.

If the receipient wants their ~2 million sats any time soon they're going to
have to CPFP the commitment transaction to get it up to about 30sat/vB, at
which point they've paid the supermajority of the cost even though they're the
receipient. Personally, I've shut down that node for good (I archived .lnd) and
I'll check back in a month or two to see if they ever get their funds.

> This is why the initial design for openv1 is "initiator pays".

...and that design clearly went out the window with anchor channels.

> 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.

No, RBF channels have nothing to do with whether or not the "initiator pays".

If you want to have the

Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

[Anthony Towns]

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

[Peter Todd]

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

[ZmnSCPxj via Lightning-dev]

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 ignore

Re: [Lightning-dev] [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment

[ZmnSCPxj via Lightning-dev]

> 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

[ZmnSCPxj via Lightning-dev]

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

[Michael Folkson via Lightning-dev]

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