This week’s newsletter follows up on several recent discussions about proposed changes to Bitcoin’s scripting language. Also included are our regular sections announcing new releases and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Continued discussion about scripting changes: there were several replies on the Bitcoin-Dev mailing list to discussions we’ve previously covered.

    • ● Covenants research: Anthony Towns replied to a post by Rusty Russell that we mentioned last week. Towns compares Russell’s approach to other approaches specifically for covenant-based vaults and finds it unappealing. In a further reply, Russell notes that there are different designs for vaults and that vaults are fundamentally less optimal than other transaction types, implying that optimization isn’t critical for vault users. He argued that the BIP345 vault approach is more suitable for an address format than a set of opcodes, which we think means that BIP345 makes more sense as a template (like P2WPKH) that is designed for one function than it does as a set of opcodes that are designed for that one function but which will interact in possibly unanticipated ways with the rest of script.

      Towns also considers the use of Russell’s approach for the purpose of generally enabling experimentation and finds it “more interesting […] but still fairly crippled.” He reminds readers of his previous proposal to provide a Lisp-style alternative to Bitcoin Script (see Newsletter #191) and shows how it could bring increased flexibility and power to perform transaction introspection during witness evaluation. He provides links to his test code and notes some toy examples he’s written. Russell replies, “I still think there’s much room for improvement before a replacement. It’s hard to compare the hobbled [S]cript we have today with an alternative, since most interesting cases are impossible.”

      Towns and Russell also briefly discuss OP_CHECKSIGFROMSTACK, specifically its ability to allow authenticated data from an oracle to be placed directly on an evaluation stack.

    • ● OP_CAT proposal: several people replied to Ethan Heilman’s post announcing a proposed BIP for OP_CAT, which we also mentioned last week.

      After several replies mentioned concern about whether OP_CAT would be excessively restricted by the 520-byte limit on the size of stack elements, Peter Todd described a way to raise the limit in a future soft fork without using any additional OP_SUCCESSx opcodes. The downside is that all uses of OP_CAT before an increase would require including a small number of extra already-available opcodes in their scripts.

      In a post made before Anthony Towns’s similar reply to Russell’s covenant research, James O’Beirne notes the significant limitations of using OP_CAT to implement vaults. He specifically notes several features that the OP_CAT versions lack compared to BIP345-style vaults.

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.

  • ● LDK 0.0.118 is the latest release of this library for building LN-enabled applications. It includes partial experimental support for the offers protocol in addition to other new features and bug fixes.

  • ● Rust Bitcoin 0.31.1 is the latest release of this library for working with Bitcoin data. See its release notes for a list of new features and bug fixes.

Note: Bitcoin Core 26.0rc1, mentioned in our last newsletter, is tagged but binaries have not been uploaded due to a change by Apple that prevented the creation of reproducible binaries for macOS. Bitcoin Core developers are working on a mitigation for a second release candidate.

Notable code and documentation changes

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

  • ● Bitcoin Core #28685 fixes a bug in the calculation of the hash of a UTXO set, mentioned in a previous newsletter. It includes a breaking change to the gettxoutsetinfo RPC, replacing the previous hash_serialized_2 value with hash_serialized_3, containing the corrected hash.

  • ● Bitcoin Core #28651 allows miniscript to more accurately estimate the maximum number of bytes that will need to be included in the witness structure in order to spend a taproot output. The improved accuracy will help prevent Bitcoin Core’s wallet from overpaying fees.

  • ● Bitcoin Core #28565 builds on #27511 to add a getaddrmaninfo RPC that exposes counts of peer addresses that are either “new” or “tried”, segmented by network (IPv4, IPv6, Tor, I2P, CJDNS). See Newsletter #237 and Podcast #237 for the motivation behind this segmentation.

  • ● LND #7828 begins requiring that peers respond to its LN protocol ping messages within a reasonable amount of time or they will be disconnected. This helps ensure the connections remain active (reducing the chance that a dead connection will stall a payment and trigger an unwanted channel force closure). There are many additional benefits of LN pings and pongs: they may help disguise network traffic, making it harder for a network observer to track payments (as payments, pings, and pongs are all encrypted); they trigger more frequent rotations of encryption keys as described in BOLT1; and LND in particular uses pong messages to help prevent eclipse attacks (see Newsletter #164).

  • ● LDK #2660 gives callers more flexibility over what feerates they can choose for onchain transactions, including settings for paying the absolute minimum, a low rate that may take over a day to confirm, a normal priority, and a high priority.

  • ● BOLTs #1086 specifies that nodes should reject (refund) an HTLC and return an expiry_too_far error if the instructions for creating a forwarded HTLC request that the local node wait more than 2,016 blocks before being able to claim a refund. Lowering this setting reduces the worst-case loss of income to a node from any particular channel jamming attack or long-held hold invoice. Raising this setting allows payments to be forwarded across more channels for the same maximum HTLC delta setting (or the same number of hops for a higher maximum HTLC delta setting, which can improve resistance to certain attacks, such as the replacement cycling attack described in last week’s newsletter).