This week’s newsletter includes our regular sections summarizing discussion about changing Bitcoin’s consensus rules, announcing new release and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

No significant news this week was found in any of our sources.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

• ● Draft BIPs for Script Restoration: Rusty Russell posted to the Bitcoin-Dev mailing list a summary and four BIPs (1, 2, 3, 4) in various stages of draft relating to a proposal to restore Script’s capabilities in a new tapscript version. Russell has previously spoken and written about these ideas. Briefly, this proposal aims to restore enhanced programmability (including covenant functionality) to Bitcoin while avoiding some of the trade-offs required in more narrowly scoped proposals.

  • ● Varops budget for script runtime constraint: The first BIP is fairly complete and proposes assigning a cost metric to nearly all Script operations, similar to the SegWit sigops budget. For most operations in Script the cost is based on the number of bytes written to the node’s RAM during execution of the opcode by a naive implementation. Unlike the sigops budget, the cost for each opcode depends on the size of its inputs - hence the name “varops”. With this unified cost model, many limits currently used to protect nodes from excessive Script validation cost can be raised to the point that they are impossible or nearly impossible to hit in practical scripts.

  • ● Restoration of disabled script functionality (tapscript v2): The second BIP is also fairly complete (aside from a reference implementation) and details the restoration of opcodes removed from Script back in 2010, as required to protect the Bitcoin network from excessive Script validation cost. With the varops budget in place, all of these opcodes (or updated versions of them) can be restored, limits can be raised, and numbers can be made arbitrary length.

  • ● OP_TX: The third BIP is a proposal for a new general introspection opcode. OP_TX allows the caller to get nearly any item or items from the transaction into the script stack. By providing direct access to the spending transaction, this opcode enables any covenant functionality possible with opcodes such as OP_TEMPLATEHASH or OP_CHECKTEMPLATEVERIFY.

  • ● New opcodes for tapscript v2: The final BIP proposes new opcodes which round out the functionality that was either missing or not needed when Bitcoin was first launched. For example, adding the ability to manipulate taptrees and taproot outputs was not necessary at Bitcoin’s introduction, but in a world with restored Script it makes sense to have these capabilities as well. Brandon Black noted an omission in the specified opcodes needed to fully construct taproot outputs. Two of the proposed opcodes seem likely to require their own full BIPs: OP_MULTI and OP_SEGMENT.

  OP_MULTI modifies the subsequent opcode to operate on more than its standard number of stack items, enabling (for example) a script to add up a variable number of items. This avoids the need for a looping construct in Script or for an OP_VAULT style deferred check while enabling value flow control and similar logic.

  OP_SEGMENT (if present) modifies the behavior of OP_SUCCESS such that instead of the whole script succeeding if an OP_SUCCESS is present, only the segment succeeds (bounded by script start, OP_SEGMENT, …, and script end). This enables the possibility of scripts with a required prefix, including OP_SEGMENT, and an untrusted suffix.

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.

• ● Bitcoin Core 30.0rc2 is a release candidate for the next major version of this full verification node software. Please see the version 30 release candidate testing guide.

• ● bdk-wallet 2.2.0 is a minor release of this library used for building wallet applications that introduces a new feature that returns events upon applying an update, new test facilities for test persistence, and documentation improvements.

• ● LND v0.20.0-beta.rc1 is a release candidate for a new version of this popular LN node implementation that introduces multiple bug fixes, persistence of node announcement settings across restarts, a new noopAdd HTLC type, support for P2TR fallback addresses on BOLT11 invoices, and an experimental XFindBaseLocalChanAlias endpoint, among many other changes.

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, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Bitcoin Core #33229 implements automatic multiprocess selection for inter-process communication (IPC) (see Newsletter #369), allowing users to skip specifying the -m startup option when IPC arguments are passed or IPC configurations are set. This change simplifies the integration of Bitcoin Core with an external Stratum v2 mining service that creates, manages and submits block templates.

• ● Bitcoin Core #33446 fixes a bug introduced when the target field was added to the responses of the getblock and getblockheader commands (see Newsletter #339). Instead of always incorrectly returning the chain tip’s target, it now returns the requested block’s target.

• ● LDK #3838 adds support for the client_trusts_lsp model for JIT channels, as specified in BLIP52 (LSPS2) (see Newsletter #335), on top of already supporting the lsp_trusts_client model. With the new model, the LSP will not broadcast the on-chain funding transaction until the receiver reveals the preimage required to claim the HTLC.

• ● LDK #4098 updates the implementation of the next_funding TLV in the channel_reestablish flow for splicing transactions, to align with the proposed specification change in BOLTs #1289. This PR follows the recent work on channel_reestablish covered in Newsletter #371.

• ● LDK #4106 fixes a race condition in which an HTLC held by an LSP on behalf of an async payment recipient would fail to be released because the LSP could not locate it. This occurred when the LSP received the release_held_htlc onion message (see Newsletters #372 and #373) before the HTLC was moved from the pre-decode map to the pending_intercepted_htlcs map. LDK now checks both maps, rather than just the latter one, to ensure the HTLC is found and released properly.

• ● LDK #4096 changes the per-peer outbound gossip queue from a 24-message limit to a 128 KB size limit. If the total number of bytes currently queued for a given peer exceeds this limit, new gossip forwards to that peer are skipped until the queue drains. This new limit significantly reduces missed forwards, and is particularly relevant because when messages vary in size.

• ● LND #10133 adds the experimental XFindBaseLocalChanAlias RPC endpoint, which returns a base SCID for a specified SCID alias (see Newsletter #203). This PR also extends the alias manager to persist the reverse mapping when aliases are created, enabling the new endpoint.

• ● BDK #2029 introduces the CanonicalView struct, which performs a one-time canonicalization of a wallet’s TxGraph at a given chaintip. This snapshot powers all subsequent queries, eliminating the need for re-canonicalization with every call. Methods that required canonicalization now have CanonicalView equivalents, and TxGraph methods that took a fallible ChainOracle are removed. See Newsletters #335 and #346 for previous canonicalization work on BDK.

• ● BIPs #1911 marks BIP21 as replaced by BIP321 and updates BIP321’s status from Draft to Proposed. BIP321 proposes a modern URI scheme for describing bitcoin payment instructions, see Newsletter #352 for more details.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on October 7. The discussion is also recorded and will be available from our podcasts page.