This week’s newsletter summarizes a proposed change to the LN specification to allow pluggable channel factories, links to a report and a new website for examining transactions on the default signet that use proposed soft forks, describes an update to the LNHANCE multi-part soft fork proposal, and discusses a paper about covenants based on grinding rather than consensus changes. Also included are our regular sections summarizing recent changes to services, client software, and popular Bitcoin infrastructure software.

News

  • ● Pluggable channel factories: ZmnSCPxj posted to Delving Bitcoin a proposal to make a small set of changes to the BOLT specification to allow existing LN software to manage LN-Penalty payment channels within a channel factory using a software plugin. The specification changes would allow the factory manager (e.g. a Lighting service provider, LSP) to send messages to an LN node that would be passed through to a local factory plugin. Many factory operations would be similar to splicing operations, allowing the plugin to reuse a significant amount of code. LN-Penalty channel operations within a factory would be similar to zero-conf channels, so they could also reuse existing code.

    ZmnSCPxj’s design is focused on SuperScalar-style factories (see Newsletter #327) but would probably be compatible with other factory styles (and possibly other multiparty contract protocols). Rene Pickhardt replied to ask about additional specification changes that could allow channels within factories to be announced but ZmnSCPxj said he deliberately didn’t consider those in his design in order to allow the specification change to be adopted as fast as possible.

  • ● Signet activity report: Anthony Towns posted to Delving Bitcoin a summary of activity on the default signet related to proposed soft forks available through Bitcoin Inquisition. The post looks at SIGHASH_ANYPREVOUT usage, including tests of LN-Symmetry and emulation of OP_CHECKTEMPLATEVERIFY. It then looks at OP_CHECKTEMPLATEVERIFY usage directly, including what are likely several different vault constructions and a few data carrier transactions. Finally, the post looks at OP_CAT usage, including for a proof-of-work faucet (see Newsletter #306), a possible vault or other covenant, and verification of a STARK zero-knowledge proof.

    Vojtěch Strnad replied that he was inspired by Towns’s post to create a website that lists “every transaction made on the Bitcoin signet that uses one of the deployed soft forks.”

  • ● Update to LNHANCE proposal: Moonsettler posted to Delving Bitcoin and also the Bitcoin-Dev mailing list a proposal for a new opcode, OP_PAIRCOMMIT, to be added to the LNHANCE soft fork proposal that includes OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACK. The new opcode allows making a hash commitment to a pair of elements; this is similar to what could be achieved using the proposed OP_CAT concatenation opcode or streaming-SHA opcodes such as those available in Elements-based sidechains but is deliberately limited to avoid enabling recursive covenants.

    Moonsettler also discussed on the mailing list other small potential tweaks to the LNHANCE proposal.

  • ● Covenants based on grinding rather than consensus changes: Ethan Heilman posted to the Bitcoin-Dev mailing list the summary of a paper he coauthored with Victor Kolobov, Avihu Levy, and Andrew Poelstra. The paper describes how covenants can be created easily without consensus changes, although spending from those covenants would require non-standard transactions and millions (or billions) of dollars worth of specialized hardware and electricity. Heilman notes that one application of the work is allowing users today to easily include a backup taproot spending path that can be securely used if quantum resistance is suddenly needed and elliptic curve signature operations on Bitcoin are disabled.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

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 #30666 adds the RecalculateBestHeader() function to recalculate the best header by iterating over the block index, which is automatically triggered when the invalidateblock and reconsiderblock RPC commands are used, or when valid headers in the block index are later found to be invalid during full validation. This fixes an issue where the value was incorrectly set after these events. This PR also marks headers that extend from an invalid block as BLOCK_FAILED_CHILD, preventing them from being considered for m_best_header.

  • ● Bitcoin Core #30239 makes ephemeral dust outputs standard, allowing zero-fee transactions with a dust output to appear in the mempool, provided they are simultaneously spent in a transaction package. This change improves the usability of advanced constructs such as connector outputs, keyed and unkeyed (P2A) anchors, which can benefit the extension of protocols such as LN, Ark, timeout trees, BitVM2, and others. This update builds on existing features such as 1P1C relays, TRUC transactions, and sibling eviction (see Newsletter #328).

  • ● Core Lightning #7833 enables the offers protocol by default, removing its previous experimental status. This follows the merging of its PR into the BOLTs repository (see Newsletter #323).

  • ● Core Lightning #7799 introduces the xpay plugin to send payments by constructing optimal multipath payments, using the askrene plugin (see Newsletter #316) and the injectpaymentonion RPC command. It supports paying both BOLT11 and BOLT12 invoices, setting retry durations and payment deadlines, adding routing data through layers, and making partial payments for multi-party contributions on a single invoice. This plugin is simpler and more sophisticated than the older ‘pay’ plugin, but doesn’t have all of its features.

  • ● Core Lightning #7800 adds a new listaddresses RPC command that returns a list of all bitcoin addresses that have been generated by the CLN node. This PR also sets P2TR as the default script type for anchor output spends and for unilateral-close change addresses.

  • ● Core Lightning #7102 extends the generatehsm command to run non-interactively with command line options. Previously, you could only generate a Hardware Security Module (HSM) secret through an interactive process at the terminal, so this change is particularly useful for automated installations.

  • ● Core Lightning #7604 adds the bkpr-editdescriptionbypaymentid and bkpr-editdescriptionbyoutpoint RPC commands to the bookkeeping plugin, which update or set the description on events matching the payment id or the outpoint respectively.

  • ● Core Lightning #6980 introduces a new splice command that takes either a JSON payload or a splice script that defines complex splicing and related actions, and combines all of these multi-channel operations into a single transaction. This PR also adds the addpsbtinput RPC command that allows users to add inputs directly to a PSBT, and adds the stfu_channels and abort_channels RPC commands that allow users to pause channel activity or abort multiple channels to enable channel commitment upgrades, which is critical when performing complex splice actions.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Twitter Spaces at 15:30 UTC on November 26. The discussion is also recorded and will be available from our podcasts page.