This week’s newsletter describes proposals to extend or replace Bitcoin Script with new opcodes, summarizes recent discussions about improving RBF policy, and links to continued work on the OP_CHECKTEMPLATEVERIFY opcode. Also included is our regular section describing notable changes to popular Bitcoin infrastructure projects.

News

  • ● Extensions and alternatives to Bitcoin Script: several developers discussed on the Bitcoin-Dev mailing list ideas for improving Bitcoin’s Script and tapscript languages, which those receiving bitcoins use to specify how they’ll later prove they authorized any spending of those bitcoins.

    • ● Looping (folding): developer ZmnSCPxj described a proposed OP_FOLD opcode as a way to allow loop-like behavior in Bitcoin Script. He described a series of constraints that could be placed on the looping to ensure they didn’t use any more CPU or memory than Bitcoin Script and tapscript can currently use—but which would reduce bandwidth by eliminating the need to include repeated code in scripts.

    • ● Using Chia Lisp: Anthony Towns posted about adding to Bitcoin a variation on Chia Lisp, which is a dialect of Lisp designed for the Chia altcoin. This would be a completely different alternative to traditional Bitcoin Script and tapscript, providing some of the same benefits of a fresh start as the previously proposed Simplicity language. Towns suggests that his alternative—“Binary Tree Coded Script” or “btc-script”—would be easier to understand and use than Simplicity, although perhaps it would be harder to formally validate.

  • ● Ideas for improving RBF policy: Gloria Zhao posted a summary of discussion about Replace-by-Fee (RBF) policy from the recent CoreDev.Tech meeting in London as well as some related updates. She reports that the main concept discussed was attempting to bound the maximum amount of resources used for relaying transactions and their replacements, such as by limiting the number of related transactions that get relayed within a certain amount of time.

    Zhao also summarized a separate discussion on a gist which examined allowing transactions to suggest a descendant limit to use. For example, a transaction could suggest limiting the maximum amount of space it and its descendants could consume in the mempool to 1,000 vbytes instead of the default 100,000 vbytes. This would make the worst case pinning attack less expensive for the honest party to overcome.

    Additionally, Zhao is seeking feedback on an algorithm for calculating the value to miners of a transaction given the current mempool. This could facilitate more flexible decision making in node software about whether or not to accept a replacement transaction.

  • ● Continued CTV discussion: as mentioned in Newsletter #183, meetings to discuss the proposed OP_CHECKTEMPLATEVERIFY (CTV) opcode have continued with summaries provided by Jeremy Rubin: 1, 2, 3, 4, and 5. Additionally this past week, James O’Beirne posted code and design documentation for a CTV-based vault.

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 #24198 extends the listsinceblock, listtransactions and gettransaction RPCs with a new wtxid field containing each transaction’s Witness Transaction Identifier as defined in BIP141.

  • ● Bitcoin Core #24043 adds new multi_a and sortedmulti_a descriptors for creating spending authorization policies that can work with tapscript’s OP_CHECKSIGADD opcode rather than older Script’s OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes. See Newsletter #46 for more information about this aspect of tapscript.

  • ● Bitcoin Core #24304 adds a new demo bitcoin-chainstate executable that can be passed a Bitcoin Core data directory and a block, which it will validate and add to the data directory. This isn’t expected to be directly useful, but creates a tool the libbitcoinkernel project will leverage to produce a library other projects can use to validate blocks and transactions using the exact same code Bitcoin Core uses.

  • ● C-Lightning #5068 increases the minimum number of BOLT7 node_announcement messages C-Lightning will relay per node per day from one to two. This may mitigate some problems related to nodes changing IP addresses or temporarily going offline for maintenance.

  • ● BIPs #1269 assigns BIP326 to a recommendation that taproot transactions set an nSequence value even when it’s not needed for a contract protocol in order to improve privacy when BIP68 consensus-enforced nSequence values are needed. BIP326 also describes how the use of nSequence can provide an alternative to anti fee sniping protection currently enabled through the transaction locktime field. See Newsletter #153 for a summary of the original mailing list proposal.