More uses for CTV
6 messages, 19 Aug to 19 Sep 2022. Started by James O'Beirne.
James O'Beirne, Greg Sanders, David A. Harding, Jeremy Rubin, ZmnSCPxj, Antoine Riard
Over the past few months there have been a few potential uses of OP_CHECKTEMPLATEVERIFY (BIP-119) (https://github.com/bitcoin/bitcoin/pull/21702) that I've found interesting.
# Congestion control redux
When I first heard of CTV, a presentation Jeremy did at Chaincode back in 2018 or '19, he cited congestion control as one of its main use cases.
The pitch went something like
Quoted text (6 lines)
> When there is a high demand for blockspace it becomes very expensive > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume > payment processor may aggregate all their payments into a single O(1) > transaction for purposes of confirmation. Then, some time later, the > payments can be expanded out of that UTXO when the demand for > blockspace is decreased.
(from https://utxos.org/uses/scaling/)
At the time that didn't particularly grab me; the idea of smoothing fee rates seemed nice but marginal.
But recently, two particular cases have made me reassess the value of congestion control.
The first stems from the necessity of L2 protocols (payment channels, vaults, etc.) to, under certain circumstances, settle to the chain in a timely way in order to prevent abuse of the protocol. If some unexpected condition (a protocol exploit, large network disconnect, en masse vault breach, etc.) creates a situation where a large number of contracts need to settle to the chain in short order, mempools could fill up and protocol failures could happen for want of mempool/block space ( https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all ).
In such a case, CTV could be used effectively to "compress" settlement commitments, get them on-chain, and then facilitate later unpacking of the CTV ouputs into the contract's true end state.
This amounts to `n` contract-control outputs (e.g. a lightning funding transaction outputs) being spent into a single CTV output, which commits to the final settlement state. Multiple parties could trustlessly collaborate to settle into a single CTV output using SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction similar to coinjoins.
Put simply, CTV allows deferring the chainspace required for the final settlement outputs, but still immediately requires space for the inputs. This might sound like a temporary reprieve from half-ish of the space required to settle, but in many (most?) cases the outputs require substantially more space than the inputs, given that often we're settling a single UTXO into multiple payouts per party. A 2, 3, or 4-fold increase (depending on the contracting pattern) in capacity isn't a silver bullet, but it could ameliorate the damage of unexpected settlement "tidal waves."
Conceptually, CTV is the most parsimonious way to do such a scheme, since you can't really get smaller than a SHA256 commitment, and that's essentially all CTV is.
The second congestion control case is related to a recent post Bram made about stability under a no-block-subsidy regime. He posted
Quoted text (9 lines)
> If transaction fees came in at an even rate over time all at the > exact same level then they work fine for security, acting similarly > to fixed block rewards. Unfortunately that isn't how it works in the > real world. There's a very well established day/night cycle with fees > going to zero overnight and even longer gaps on weekends and > holidays. If in the future Bitcoin is entirely dependent on fees for > security (scheduled very strongly) and this pattern keeps up > (overwhelmingly likely) then this is going to become a serious > problem.
(from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html )
Ryan Grant points out that CTV's congestion control use could help to smooth fees, creating a less spiky incentive to mine ( https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html ).
Admittedly the original concern is speculative and a ways off from now, as others in the thread pointed out. But having CTV-based fee smoothing as an option certainly doesn't seem like a bad thing.
# Atomic mining pool payouts
Laurentia is a mining pool design that pays participants out directly from the coinbase of found blocks.
Quoted text (4 lines)
> Block solve reward is distributed directly from the block to each > user, meaning each user gets a 'mined' transaction directly into > their wallet as soon as the block is solved so there is no wait to > get paid and no pool wallet storing user's rewards.
(from https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf )
I'm not a mining expert and so I can't speak to the efficacy of the paper as a whole, but direct-from-coinbase payouts seem like a desirable feature which avoids some trust in pools. One limitation is the size of the coinbase outputs owed to constituent miners; this limits the number of participants in the pool.
If the payout was instead a single OP_CTV output, an arbitrary number of pool participants could be paid out "atomically" within a single coinbase.
---
CTV both in concept and implementation is very simple, and I think it is likely to continue to yield potential applications. "Settlement compression" seems like a useful thing, especially in light of a possible increase in L2 usage, and CTV seems like the simplest means to enable it.
Interestingly, an analogue for this pattern going the other direction is possible, e.g. non-interactive channel openings (https://utxos.org/uses/non-interactive-channels/), which would allow e.g. opening a lightning channel with a merchant who doesn't want to have their spending keys constantly accessible from a point-of-sale, but can still parse/verify CTV commitments.
Regards, James
Hi James,
Could you elaborate on a L2 contract where speedy settlement of the "first part" can be done, while having the rest take their time? I'm more thinking about time-out based protocols.
Naturally my mind drifts to LN, where getting the proper commitment transaction confirmed in a timely fashion is required to get the proper balances back. The one hitch is that for HTLCs you still need speedy resolution otherwise theft can occur. And given today's "layered commitment" style transaction where HTLCs are decoupled from the balance output timeouts, I'm not sure this can save much.
I don't know enough about vault designs to judge.
CTV style commitments have popped up in a couple places in my work on eltoo(emulated via APO sig-in-script), but mostly in the context of reducing interactivity in protocols, not in byte savings per se.
Thanks!
Greg
On Fri, Aug 19, 2022 at 12:34 PM James O'Beirne via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (141 lines)
> Over the past few months there have been a few potential uses of > OP_CHECKTEMPLATEVERIFY (BIP-119) > (https://github.com/bitcoin/bitcoin/pull/21702) that I've found > interesting. > > # Congestion control redux > > When I first heard of CTV, a presentation Jeremy did at Chaincode back > in 2018 or '19, he cited congestion control as one of its main use > cases. > > The pitch went something like > > > When there is a high demand for blockspace it becomes very expensive > > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume > > payment processor may aggregate all their payments into a single O(1) > > transaction for purposes of confirmation. Then, some time later, the > > payments can be expanded out of that UTXO when the demand for > > blockspace is decreased. > > (from https://utxos.org/uses/scaling/) > > At the time that didn't particularly grab me; the idea of smoothing fee > rates seemed nice but marginal. > > But recently, two particular cases have made me reassess the value of > congestion control. > > The first stems from the necessity of L2 protocols (payment channels, > vaults, etc.) to, under certain circumstances, settle to the chain in a > timely way in order to prevent abuse of the protocol. If some > unexpected condition (a protocol exploit, large network disconnect, en > masse vault breach, etc.) creates a situation where a large number of > contracts need to settle to the chain in short order, mempools could > fill up and protocol failures could happen for want of mempool/block > space > ( > https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all > ). > > In such a case, CTV could be used effectively to "compress" settlement > commitments, get them on-chain, and then facilitate later unpacking of > the CTV ouputs into the contract's true end state. > > This amounts to `n` contract-control outputs (e.g. a lightning funding > transaction outputs) being spent into a single CTV output, which > commits to the final settlement state. Multiple parties could > trustlessly collaborate to settle into a single CTV output using > SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction > similar to coinjoins. > > Put simply, CTV allows deferring the chainspace required for the final > settlement outputs, but still immediately requires space for the > inputs. This might sound like a temporary reprieve from half-ish of the > space required to settle, but in many (most?) cases the outputs require > substantially more space than the inputs, given that often we're > settling a single UTXO into multiple payouts per party. A 2, 3, or > 4-fold increase (depending on the contracting pattern) in capacity > isn't a silver bullet, but it could ameliorate the damage of unexpected > settlement "tidal waves." > > Conceptually, CTV is the most parsimonious way to do such a scheme, > since you can't really get smaller than a SHA256 commitment, and that's > essentially all CTV is. > > The second congestion control case is related to a recent post Bram > made about stability under a no-block-subsidy regime. He posted > > > If transaction fees came in at an even rate over time all at the > > exact same level then they work fine for security, acting similarly > > to fixed block rewards. Unfortunately that isn't how it works in the > > real world. There's a very well established day/night cycle with fees > > going to zero overnight and even longer gaps on weekends and > > holidays. If in the future Bitcoin is entirely dependent on fees for > > security (scheduled very strongly) and this pattern keeps up > > (overwhelmingly likely) then this is going to become a serious > > problem. > > (from > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html > ) > > Ryan Grant points out that CTV's congestion control use could help to > smooth fees, creating a less spiky incentive to mine > ( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html > ). > > Admittedly the original concern is speculative and a ways off from now, > as others in the thread pointed out. But having CTV-based fee smoothing > as an option certainly doesn't seem like a bad thing. > > > # Atomic mining pool payouts > > Laurentia is a mining pool design that pays participants out directly > from the coinbase of found blocks. > > > Block solve reward is distributed directly from the block to each > > user, meaning each user gets a 'mined' transaction directly into > > their wallet as soon as the block is solved so there is no wait to > > get paid and no pool wallet storing user's rewards. > > (from > > https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf > ) > > I'm not a mining expert and so I can't speak to the efficacy of the > paper as a whole, but direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. One limitation is > the size of the coinbase outputs owed to constituent miners; this > limits the number of participants in the pool. > > If the payout was instead a single OP_CTV output, an arbitrary number > of pool participants could be paid out "atomically" within a single > coinbase. > > --- > > CTV both in concept and implementation is very simple, and I think it > is likely to continue to yield potential applications. > "Settlement compression" seems like a useful thing, especially in light > of a possible increase in L2 usage, and CTV seems like the simplest > means to enable it. > > Interestingly, an analogue for this pattern going the other direction > is possible, e.g. non-interactive channel openings > (https://utxos.org/uses/non-interactive-channels/), which would allow > e.g. opening a lightning channel with a merchant who doesn't want to > have their spending keys constantly accessible from a point-of-sale, > but can still parse/verify CTV commitments. > > Regards, > James > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On 2022-08-19 06:33, James O'Beirne via bitcoin-dev wrote:
Quoted text (4 lines)
> Multiple parties could > trustlessly collaborate to settle into a single CTV output using > SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction > similar to coinjoins.
Just to make sure I understand, is the reason for SH_ALL|SH_ACP so that any of the parties can subsequently RBF fee bump the transaction?
Quoted text (2 lines)
> Conceptually, CTV is the most parsimonious way to do such a scheme, > since you can't really get smaller than a SHA256 commitment
What's the advantage of CTV here compared to presigned transactions? If multiple parties need to interact to cooperatively sign a transaction, no significant overhead is added by having them simultaneously sign a second transaction that spends from the output of the first transaction. Presigned transactions actually have two small benefits I can think of:
1. The payment from the first transaction (containing the spends from the channel setup transactions) can be sent to a P2WPKH output, which is actually smaller than a SHA256 commitment. Though this probably does require an extra round of communication for commit-and-reveal to prevent a collision attack on the P2WPKH address.[1]
2. Having the first transaction pay a either a P2WPKH or bech32m output and the second transaction spend from that UTXO may blend in better with other transactions, enhancing privacy. This advantage probably isn't compatible with SH_ALL|SH_ACP, though, and it would require other privacy upgrades to LN.
Quoted text (8 lines)
> direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. > [...] > If the payout was instead a single OP_CTV output, an arbitrary number > of pool participants could be paid out "atomically" within a single > coinbase. One limitation is > the size of the coinbase outputs owed to constituent miners; this > limits the number of participants in the pool.
I'm confused by this. What is the size limitation on coinbase outputs, how does it limit the number of participants in a pool, and how does CTV fix that?
Thanks,
-Dave
Presigned transactions have to use a N-of-N (2-2 for ln, more for pools) multisignature which is computed over the network whereas in-script commitments can be done 1 key that is a non-secret point (e.g., just the generator I think works).
For large protocol trees (e.g., of size N) the savings can be substantial! It also reduces the amount of state that needs to be stored since the in-script sigs can be deterministic.
Rene has some nice work demonstrating that latency in generating state transitions has a very substantial cost to the efficiency of routing, maybe he can chime in further.
You can also do a "back-filling" where you get the best of both, by (after you commit to the quick to generate in-script version) lazily backfilling with an equivalent p2wpkh version. If you have a channel, when you are in "burst mode", you can cancel the longer to generate p2wpkh version when newer states come in. (data hazard/ bypass).
With respect to mining pools and size constraints, https://rubin.io/bitcoin/2021/12/12/advent-15/ shows how paying into batches of channels can be used to trustlessly compress payouts without custodial relationship.
Good morning Greg,
Quoted text (11 lines)
> Hi James, > Could you elaborate on a L2 contract where speedy > settlement of the "first part" can be done, while having the rest > take their time? I'm more thinking about time-out based protocols. > > Naturally my mind drifts to LN, where getting the proper commitment > transaction confirmed in a timely fashion is required to get the proper > balances back. The one hitch is that for HTLCs you still need speedy > resolution otherwise theft can occur. And given today's "layered > commitment" style transaction where HTLCs are decoupled from > the balance output timeouts, I'm not sure this can save much.
As I understand it, layered commitments can be modified to use `OP_CTV`, which would be slightly smaller (need only to reveal a 32-byte `OP_CTV` hash on the witness instead of a 64-byte Taproot signature, or 73-byte classical pre-Taproot ECDSA signature), and is in fact precisely an example of the speedy settlement style.
Quoted text (3 lines)
> CTV style commitments have popped up in a couple places in my > work on eltoo(emulated via APO sig-in-script), but mostly in the > context of reducing interactivity in protocols, not in byte savings per se.
In many offchain cases, all channel participants would agree to some pre-determined set of UTXOs, which would be implemented as a transaction spending some single UTXO and outputting the pre-determined set of UTXOs.
The single UTXO can be an n-of-n of all participants, so that all agree by contributing their signatures:
* Assuming Taproot, the output address itself is 33 bytes (x4 weight). * The n-of-n multisignature is 64 witness bytes (x1 weight).
Alternatly the single UTXO can be a P2WSH that reveals an `OP_CTV`:
* The P2WSH is 33 bytes (x4 weight) --- no savings here. * The revelation of the `<hash> OP_CTV` is 33 witness bytes (x1 weight).
Thus, as I understand it, `OP_CTV` can (almost?) always translate to a small weight reduction for such "everyone agrees to this set of UTXOs" for all offchain protocols that would require it.
Regards, ZmnSCPxj
Hi James,
Thanks to bringing to awareness the atomic mining pool thing, it's interesting.
Quoted text (5 lines)
> I'm not a mining expert and so I can't speak to the efficacy of the > paper as a whole, but direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. One limitation is > the size of the coinbase outputs owed to constituent miners; this > limits the number of participants in the pool.
I'm neither a mining expert, but I wonder if there is not some weird dependency here. The coinbase output scriptpubkey being part of the header's merkle root commitment, the CTV hash being part of the scriptpubkey and the payout outputs being part of the CTV hash, everytime the payout outputs as re-evaluated in function of the last work share submitted, as Laurentia is proposing, the whole payout transaction must be updated, then the CTV hash, then the merkle root commitment, leading all the mining devices to re-fetch a header from the job negotiator (in Stratum V2 parlance), I think ? I don't know the average shares submission frequency for a local pool of size 100 as targeted by Laurentia though the latency hit might downgrade the worthiness of this CTV-based atomic mining pool payouts design...
Beyond, I'm not sure about the trust removal statement of this design, as the job negotiator operator, sounds to always have malleability to select the coinbase output scriptpubkey, therefore selecting any CTV hash assigning all the reward to itself, at the detriment of other mining pool participant. I believe this is not a downside of CTV usage itself, but the fact that the coinbase output scriptpubkey is ultimately signed by the proof-of-work itself.
About compactness, I wonder if an atomic payment pool payouts design favoring the payouts settlement directly over Lightning channels wouldn't offer a smaller on-chain footprint. E.g, maybe the mining pool operator could send a long-term PTLC to each participant covering the period during which a block has odds to be mined by the pool. The PTLCs amounts should be stable once the block template is agreed on. The coinbase output is locked with some scriptless script point. When it is spent by the mining operator, the PTLCs could be fetched by the participant. If the mining operator doesn't spend before time lock expiration, there could be some on-chain fan-out transaction kicking-out. That type of scheme would allow you to save on-chain fees and not to leak the mining pool hashrate distribution. However, I believe it is more complex to make it fit with the SPLNS "real-time" calculation as it sounds to be proposed by the paper. Just a strawman proposal, if relevant, deserves more thinking.
The paper would deserve to have a fully fleshed-out "coinbase generation" scheme as the description is a bit loose, imo, like:
"Block solve reward is distributed directly from the block to each user, meaning each user gets a 'mined' transaction directly into their wallet as soon as the block is solved so there is no wait to get paid and no pool wallet storing user's rewards"
Anyway, left a scratch of further scheme analysis there: https://github.com/ariard/bitcoin-contracting-primitives-wg/pull/8
Best, Antoine
Le ven. 19 août 2022 à 12:33, James O'Beirne via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> a écrit :
Quoted text (141 lines)
> Over the past few months there have been a few potential uses of > OP_CHECKTEMPLATEVERIFY (BIP-119) > (https://github.com/bitcoin/bitcoin/pull/21702) that I've found > interesting. > > # Congestion control redux > > When I first heard of CTV, a presentation Jeremy did at Chaincode back > in 2018 or '19, he cited congestion control as one of its main use > cases. > > The pitch went something like > > > When there is a high demand for blockspace it becomes very expensive > > to make transactions. By using OP_CHECKTEMPLATEVERIFY, a large volume > > payment processor may aggregate all their payments into a single O(1) > > transaction for purposes of confirmation. Then, some time later, the > > payments can be expanded out of that UTXO when the demand for > > blockspace is decreased. > > (from https://utxos.org/uses/scaling/) > > At the time that didn't particularly grab me; the idea of smoothing fee > rates seemed nice but marginal. > > But recently, two particular cases have made me reassess the value of > congestion control. > > The first stems from the necessity of L2 protocols (payment channels, > vaults, etc.) to, under certain circumstances, settle to the chain in a > timely way in order to prevent abuse of the protocol. If some > unexpected condition (a protocol exploit, large network disconnect, en > masse vault breach, etc.) creates a situation where a large number of > contracts need to settle to the chain in short order, mempools could > fill up and protocol failures could happen for want of mempool/block > space > ( > https://github.com/jamesob/mempool.work#failure-one-mempool-to-rule-them-all > ). > > In such a case, CTV could be used effectively to "compress" settlement > commitments, get them on-chain, and then facilitate later unpacking of > the CTV ouputs into the contract's true end state. > > This amounts to `n` contract-control outputs (e.g. a lightning funding > transaction outputs) being spent into a single CTV output, which > commits to the final settlement state. Multiple parties could > trustlessly collaborate to settle into a single CTV output using > SIGHASH_ALL | ANYONECANPAY. This requires a level of interaction > similar to coinjoins. > > Put simply, CTV allows deferring the chainspace required for the final > settlement outputs, but still immediately requires space for the > inputs. This might sound like a temporary reprieve from half-ish of the > space required to settle, but in many (most?) cases the outputs require > substantially more space than the inputs, given that often we're > settling a single UTXO into multiple payouts per party. A 2, 3, or > 4-fold increase (depending on the contracting pattern) in capacity > isn't a silver bullet, but it could ameliorate the damage of unexpected > settlement "tidal waves." > > Conceptually, CTV is the most parsimonious way to do such a scheme, > since you can't really get smaller than a SHA256 commitment, and that's > essentially all CTV is. > > The second congestion control case is related to a recent post Bram > made about stability under a no-block-subsidy regime. He posted > > > If transaction fees came in at an even rate over time all at the > > exact same level then they work fine for security, acting similarly > > to fixed block rewards. Unfortunately that isn't how it works in the > > real world. There's a very well established day/night cycle with fees > > going to zero overnight and even longer gaps on weekends and > > holidays. If in the future Bitcoin is entirely dependent on fees for > > security (scheduled very strongly) and this pattern keeps up > > (overwhelmingly likely) then this is going to become a serious > > problem. > > (from > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html > ) > > Ryan Grant points out that CTV's congestion control use could help to > smooth fees, creating a less spiky incentive to mine > ( > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020702.html > ). > > Admittedly the original concern is speculative and a ways off from now, > as others in the thread pointed out. But having CTV-based fee smoothing > as an option certainly doesn't seem like a bad thing. > > > # Atomic mining pool payouts > > Laurentia is a mining pool design that pays participants out directly > from the coinbase of found blocks. > > > Block solve reward is distributed directly from the block to each > > user, meaning each user gets a 'mined' transaction directly into > > their wallet as soon as the block is solved so there is no wait to > > get paid and no pool wallet storing user's rewards. > > (from > > https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf > ) > > I'm not a mining expert and so I can't speak to the efficacy of the > paper as a whole, but direct-from-coinbase payouts seem like a > desirable feature which avoids some trust in pools. One limitation is > the size of the coinbase outputs owed to constituent miners; this > limits the number of participants in the pool. > > If the payout was instead a single OP_CTV output, an arbitrary number > of pool participants could be paid out "atomically" within a single > coinbase. > > --- > > CTV both in concept and implementation is very simple, and I think it > is likely to continue to yield potential applications. > "Settlement compression" seems like a useful thing, especially in light > of a possible increase in L2 usage, and CTV seems like the simplest > means to enable it. > > Interestingly, an analogue for this pattern going the other direction > is possible, e.g. non-interactive channel openings > (https://utxos.org/uses/non-interactive-channels/), which would allow > e.g. opening a lightning channel with a merchant who doesn't want to > have their spending keys constantly accessible from a point-of-sale, > but can still parse/verify CTV commitments. > > Regards, > James > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >