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
