This week’s newsletter describes an analysis of the proposed OP_CHECKTEMPLATEVERIFY (CTV) opcode’s effect on discreet log contracts and summarizes a discussion about alternative changes to tapscript to enable CTV and SIGHASH_ANYPREVOUT. Also included are our regular sections with announcements of new releases and notable changes to popular Bitcoin infrastructure software.

News

  • Improving DLC efficiency by changing script: Lloyd Fournier posted to the DLC-Dev and Bitcoin-Dev mailing lists about how the proposed OP_CHECKTEMPLATEVERIFY (CTV) opcode could radically reduce the number of signatures required to create certain Discreet Log Contracts (DLCs), as well as reduce the number of some other operations.

    In brief, for each possible terminal state of a contract—e.g., Alice gets 1 BTC, Bob gets 2 BTC—DLCs currently require creating a separate signature adaptor for that state. Many contracts define a large number of possible terminal states, such as a contract about the future price of bitcoins which specify prices rounded to the nearest dollar and need to cover several thousand dollars worth of price range even for a relatively short-term contract. That requires the participants to create, exchange, and store thousands of partial signatures.

    Instead, Fournier suggests that the thousands of possible states be created using CTV in a tapleaf which commits to the outputs to put onchain. CTV commits to outputs using hashes, so parties can compute all the possible state hashes themselves quickly and on-demand, minimizing computation, data exchange, and data storage. Some signatures are still used, but the number is greatly reduced. In the case of contracts using multiple oracles (e.g. multiple price data providers for an exchange rate contract), there’s a further simplification and reduction in the amount of data required.

    Jonas Nick noted that a similar optimization is also possible using the proposed SIGHASH_ANYPREVOUT signature hash mode (and we’ll note that the same optimization is also available using the alternatives described in the following news item).

  • Composable alternatives to CTV and APO: Russell O’Connor posted to the Bitcoin-Dev mailing list the idea for a soft fork to add two new opcodes to Bitcoin’s Tapscript language. A tapscript could use the new OP_TXHASH opcode to specify which parts of a spending transaction should be serialized and hashed, with the hash digest being put on the evaluation stack for later opcodes to use. A new OP_CHECKSIGFROMSTACK (CSFS) opcode (as previously proposed) would allow a tapscript to specify a public key and require a corresponding signature over particular data on the stack—such as the computed digest of the transaction created by OP_TXHASH.

    O’Connor explained how these two opcodes would allow emulation of two earlier soft fork proposals, SIGHASH_ANYPREVOUT (APO, specified in BIP118) and OP_CHECKTEMPLATEVERIFY (CTV, specified in BIP119). For some purposes, the emulation might be less efficient than using CTV or APO directly, but OP_TXHASH and OP_CSFS would keep the Tapscript language simpler and provide more flexibility for future script writers, especially if combined with other simple additions to tapscript such as OP_CAT.

    In a reply, Anthony Towns suggested a similar approach using other alternative opcodes.

    The ideas were still being actively discussed as this summary was being written. We expect to revisit the topic in a future newsletter.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #23201 improves the ability of wallet users to fund transactions with external inputs (previously mentioned in Newsletter #170) by allowing them to specify maximum weights instead of solving data. This enables applications to use fundrawtransaction, send, and walletfundpsbt RPCs to fee bump transactions with nonstandard outputs such as HTLCs (a requirement for LN clients described in Newsletter #184).

  • Eclair #2141 improves the automatic fee bumping mechanism (previously covered in Newsletter #184) by choosing a more aggressive confirmation target when the wallet is low on UTXOs. In such situations, it is important to have the fee bump transaction confirm quickly to preserve the wallet’s UTXO count in case of further force-closes. More details on the anchor outputs-style fee bumping used by Eclair can be found here.

  • BTCPay Server #3341 allows users to configure a BOLT11 expiry, different from the previous 30 day default, when requesting a refund via LN.