* [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment
@ 2024-01-24 19:31 Peter Todd
2024-01-25 12:57 ` Michael Folkson
` (3 more replies)
0 siblings, 4 replies; 14+ messages in thread
From: Peter Todd @ 2024-01-24 19:31 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-24 19:31 [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd @ 2024-01-25 12:57 ` Michael Folkson 2024-01-30 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj 2024-01-25 17:49 ` [bitcoin-dev] " jlspc ` (2 subsequent siblings) 3 siblings, 1 reply; 14+ messages in thread From: Michael Folkson @ 2024-01-25 12:57 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, 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 <bitcoin-dev@lists•linuxfoundation.org> 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-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-25 12:57 ` Michael Folkson @ 2024-01-30 4:12 ` ZmnSCPxj 2024-01-30 4:38 ` Peter Todd 0 siblings, 1 reply; 14+ messages in thread From: ZmnSCPxj @ 2024-01-30 4:12 UTC (permalink / raw) To: Michael Folkson; +Cc: bitcoin-dev, 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-30 4:12 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj @ 2024-01-30 4:38 ` Peter Todd 2024-01-30 5:07 ` ZmnSCPxj 0 siblings, 1 reply; 14+ messages in thread From: Peter Todd @ 2024-01-30 4:38 UTC (permalink / raw) To: ZmnSCPxj; +Cc: bitcoin-dev, Lightning Dev [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-30 4:38 ` Peter Todd @ 2024-01-30 5:07 ` ZmnSCPxj 2024-01-30 5:17 ` ZmnSCPxj 2024-01-30 8:40 ` Peter Todd 0 siblings, 2 replies; 14+ messages in thread From: ZmnSCPxj @ 2024-01-30 5:07 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev, Lightning Dev Sent with Proton Mail secure email. On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <pete@petertodd•org> wrote: > 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). 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 this paragraph. Regards, ZmnSCPxj ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 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 1 sibling, 1 reply; 14+ messages in thread From: ZmnSCPxj @ 2024-01-30 5:17 UTC (permalink / raw) To: ZmnSCPxj; +Cc: bitcoin-dev, 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-30 5:17 ` ZmnSCPxj @ 2024-01-30 5:55 ` Anthony Towns 0 siblings, 0 replies; 14+ messages in thread From: Anthony Towns @ 2024-01-30 5:55 UTC (permalink / raw) To: ZmnSCPxj, Bitcoin Protocol Discussion; +Cc: Lightning Dev On Tue, Jan 30, 2024 at 05:17:04AM +0000, 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-30 5:07 ` ZmnSCPxj 2024-01-30 5:17 ` ZmnSCPxj @ 2024-01-30 8:40 ` Peter Todd 1 sibling, 0 replies; 14+ messages in thread From: Peter Todd @ 2024-01-30 8:40 UTC (permalink / raw) To: ZmnSCPxj; +Cc: bitcoin-dev, Lightning Dev [-- Attachment #1: Type: text/plain, Size: 5868 bytes --] On Tue, Jan 30, 2024 at 05:07:16AM +0000, ZmnSCPxj wrote: > Sent with Proton Mail secure email. > > On Tuesday, January 30th, 2024 at 4:38 AM, Peter Todd <pete@petertodd•org> wrote: > > > 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). > > 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 RBF concept, and initator pays, you just need to negotiate a minimum fee rate that you take out of the initiators balance. That aspect of the design is orthogonal to how exactly the rest of the fees are paid, and the concept of negotiating a minimum fee for the commitment transaction to pay is relevant to all forms of anchor channels too. > 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. ...and no-one is proposing that variation for the obvious reason that the receipient has no incentive not to use the full fee-rate every time. Indeed, a hypothetical CPFP version of this variation would have the exact same incentive issue. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-24 19:31 [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd 2024-01-25 12:57 ` Michael Folkson @ 2024-01-25 17:49 ` jlspc 2024-01-30 4:49 ` Peter Todd 2024-01-27 6:28 ` Brandon Black [not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com> 3 siblings, 1 reply; 14+ messages in thread From: jlspc @ 2024-01-25 17:49 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev Hi Peter, If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible to use CTV to define a transaction with a fixed fee and no anchor outputs, as long as it's racing against a transaction with an FDT. Regards, John (1) https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004254.html Sent with Proton Mail secure email. On Wednesday, January 24th, 2024 at 11:31 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 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 0 siblings, 1 reply; 14+ messages in thread From: Peter Todd @ 2024-01-30 4:49 UTC (permalink / raw) To: jlspc; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 620 bytes --] On Thu, Jan 25, 2024 at 05:49:26PM +0000, jlspc wrote: > Hi Peter, > > If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible to use CTV to define a transaction with a fixed fee and no anchor outputs, as long as it's racing against a transaction with an FDT. Fee-rate-dependant timelocks have obvious issues around manipulation of observed fee-rates by miners. It not unreasonable to say they assume miners are honest, which is a significant weakening of the economic incentive-based security model we usually assume in Bitcoin. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* [bitcoindev] Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-30 4:49 ` Peter Todd @ 2024-02-20 23:13 ` 'jlspc' via Bitcoin Development Mailing List 0 siblings, 0 replies; 14+ messages in thread From: 'jlspc' via Bitcoin Development Mailing List @ 2024-02-20 23:13 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoindev Hi Peter, Yes, Bitcoin's security should be based on all parties following economic incentives. As you explain very convincingly in your V3 post [1], it's essential that miners' economic incentives don't include receiving offchain payments for their mining decisions. If we're successful in preventing incentives for offchain payments (e.g., by avoiding the use of anchor outputs for paying fees [1]), then the onchain fees will represent the true cost of putting transactions onchain. Even without other incentives for offchain payments, if feerate-dependent timelocks (FDTs) were used to secure Layer 2 protocols, miners could collude with the operators of the Layer 2 protocols to mine blocks with artificially low median feerates and thus steal funds. However, miners can already create reorgs that enable double-spends and steal funds. The defences against FDT attacks are similar to the defences against double-spend attacks. In both cases, a conservative choice of security parameters (namely FDT parameters or safe_confirmation_depth blocks) virtually eliminates the possibility of a successful attack involving less than 45% of the hashpower. For example, an FDT with 16k window_size and 1k block_count has less than a 10^-33 chance of being artificially manipulated by miners with 45% of the hashpower. Thus, in both cases, the key issue is whether or not a majority of hashpower (or at least more than 45% of it) will collude in order to enable theft. In the case of double-spend attacks, if a majority of the hashpower colluded in order to steal funds from deep in the blockchain, the attack would be highly-visible and would likely backfire due to damage to the value of bitcoin and/or other responses. Similarly, if FDTs were used to secure funds in Lightning channels, channel factories, or Timeout-Trees, and if a majority of the hashpower colluded in order to manipulate FDTs to steal those funds, the attack would again be highly-visible and likely to backfire. It would be ideal if we could invent something that prevents forced expiration spam attacks without relying on detecting a spike in onchain fees. Such an invention would be strictly better than FDTs. However, I'm not aware of any such invention, and there's a case to be made that FDTs (or something else that's defined in terms of onchain fees) are our best chance for preventing forced expiration spam attacks [2]. This observation only strengthens your argument that we should avoid anything (such as the use of anchor outputs for paying fees) that rewards miners for receiving offchain payments [1]. Offchain fees endanger not only miner decentralization, but also our ability to scale Bitcoin without incentivizing forced expiration spam attacks. Given that Bitcoin will be far more valuable if it is decentralized and if it can scale safely, all parties (including miners) should want to keep fees onchain. Regards, John [1] https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a-danger-to-mining-decentralization [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022198.html Sent with Proton Mail secure email. On Monday, January 29th, 2024 at 8:49 PM, Peter Todd <pete@petertodd•org> wrote: > On Thu, Jan 25, 2024 at 05:49:26PM +0000, jlspc wrote: > > > Hi Peter, > > > > If feerate-dependent timelocks (FDTs) (1) are supported, it would be possible to use CTV to define a transaction with a fixed fee and no anchor outputs, as long as it's racing against a transaction with an FDT. > > > Fee-rate-dependant timelocks have obvious issues around manipulation of > observed fee-rates by miners. It not unreasonable to say they assume miners are > honest, which is a significant weakening of the economic incentive-based > security model we usually assume in Bitcoin. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/PnCfwvddzyZz4IZayq9GxSFhmc77F9-eL0EnnAl3QMNNB-S_FppHP8QXZ4ZR-9LoBW_6B3_GC3FqfpykjFUHGrR-hmNQ4_XJSGBH0CriI9g%3D%40protonmail.com. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-24 19:31 [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment Peter Todd 2024-01-25 12:57 ` Michael Folkson 2024-01-25 17:49 ` [bitcoin-dev] " jlspc @ 2024-01-27 6:28 ` Brandon Black 2024-01-30 4:46 ` Peter Todd [not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com> 3 siblings, 1 reply; 14+ messages in thread From: Brandon Black @ 2024-01-27 6:28 UTC (permalink / raw) To: Peter Todd, Bitcoin Protocol Discussion Hi Peter, On 2024-01-24 (Wed) at 19:31:07 +0000, Peter Todd via bitcoin-dev wrote: > 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. I understand your reservations with regard to CTV-based protocols for scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" concern is readily answered (and you actually gave one answer to approximately the same concern from me when we discussed lightning fees): If the user's balance inside the protocol is not sufficient to pay exit fees then they aren't going to try to exit; so their in-protocol balance can be used to pay fees. With ephemeral anchors throughout the tree, an exiting user would spend their leaf UTXO, and the ephemeral anchors along the path to their leaf to create a package of the necessary fee rate to facilitate their timely exit. Alternatively, users entering into a channel tree protocol (e.g. Timeout Trees) can have their leaf include a second UTXO commitment which would create a fee-paying output exactly when they need it; without causing a scaling problem. Finally, the reality of these protocol proposals is that they are intended to enable users who may never have sufficient funds to pay the full cost to exit the protocol in on chain fees to use bitcoin in a trust-minimized way. To facilitate this, such a protocol could employ fee insurance which would accept claims for fees to pull a specific exit series on chain via any of the mechanisms you describe. This, by the way, would bring more than one user out of the protocol, so even in the worst case it does scale bitcoin by requiring only 1 fee paying UTXO for log_r(n)*(r-1) users to exit. Hope this helps, --Brandon ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 2024-01-27 6:28 ` Brandon Black @ 2024-01-30 4:46 ` Peter Todd 0 siblings, 0 replies; 14+ messages in thread From: Peter Todd @ 2024-01-30 4:46 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2564 bytes --] On Fri, Jan 26, 2024 at 10:28:54PM -0800, Brandon Black wrote: > Hi Peter, > > On 2024-01-24 (Wed) at 19:31:07 +0000, Peter Todd via bitcoin-dev wrote: > > 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. > > I understand your reservations with regard to CTV-based protocols for > scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" > concern is readily answered (and you actually gave one answer to > approximately the same concern from me when we discussed lightning > fees): If the user's balance inside the protocol is not sufficient to > pay exit fees then they aren't going to try to exit; so their > in-protocol balance can be used to pay fees. With ephemeral anchors > throughout the tree, an exiting user would spend their leaf UTXO, and > the ephemeral anchors along the path to their leaf to create a package > of the necessary fee rate to facilitate their timely exit. > > Alternatively, users entering into a channel tree protocol (e.g. Timeout > Trees) can have their leaf include a second UTXO commitment which would > create a fee-paying output exactly when they need it; without causing a > scaling problem. You are assuming a specific type of CTV use-case. Not all CTV use-cases have this property, which is why I called this a footgun: attractive, but likely to lead to protocol designs with unexpected flaws. Secondly, anchor outputs/CPFP is significantly less efficient than RBF, due to the extra bytes required for the CPFP transaction. As I explained in the email you are replying to, this is a danger to mining decentralization because it requires less bytes to pay fees with out-of-band fee payments. It is much better to deal with fees now, before CTV is standardized as-is, in a way that allows for efficient fee payment via RBF rather than locking in inefficient CPFP designs that invite out-of-band fees. -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com>]
* Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment [not found] ` <Plx5nCQxEjS8u-XLGEza0bBGgztkCh7wMTckN95VNqqM6HZfbXxywAqMxiwhO-VIIJq9vioSr7jPwWTIksLkgdTM9aBn6mkmlfHGm-1LhbM=@protonmail.com> @ 2024-01-30 4:41 ` Peter Todd 0 siblings, 0 replies; 14+ messages in thread From: Peter Todd @ 2024-01-30 4:41 UTC (permalink / raw) To: alicexbt; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3367 bytes --] On Sat, Jan 27, 2024 at 05:50:27PM +0000, alicexbt wrote: > Hi Peter, > > In addition to the various methods shared by Brandon, users also have the option of using multiple templates, each with different fee rates. While this introduces some trade-offs, it remains a possibility that some users might prefer. I mentioned this possibility in the email that you are replying to. It is difficult to impossible to implement in many (but not all!) CTV-using constructions because you get an exponential "blow-up" of possible fee variants. > OP_IF > //Template-A > OP_PUSHBYTES_32 HASH1 OP_CHECKTEMPLATEVERIFY > OP_ELSE > //Template-B > OP_PUSHBYTES_32 HASH2 OP_CHECKTEMPLATEVERIFY > OP_ENDIF Note that with taproot, it is more efficient to do this via taproot leafs than with IF statements. > /dev/fd0 > floppy disk guy > > Sent with Proton Mail secure email. > > On Wednesday, January 24th, 2024 at 7:31 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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-dev@lists•linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- https://petertodd.org 'peter'[:-1]@petertodd.org [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-02-21 0:12 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-24 19:31 [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 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
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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox