This week’s newsletter announces a draft BIP for referencing unspendable keys in descriptors, examines how implementations are using PSBTv2, and corrects in depth our description last week of a new offchain DLC protocol. Also included are our regular sections describing changes to services and client software, announcing new releases and release candidates, and summarizing recent changes to popular Bitcoin infrastructure software.

News

  • ● Draft BIP for unspendable keys in descriptors: Andrew Toth posted to Delving Bitcoin and the Bitcoin-Dev mailing list a draft BIP for referencing provably unspendable keys in descriptors. This follows previous discussion (see Newsletter #283). Using a provably unspendable key, also called a nothing up my sleeve (NUMS) point, is particularly relevant for the taproot internal key. If it’s not possible to create a keypath spend using the internal key, then only a scriptpath spend using a tapleaf is possible (e.g., using a tapscript).

    As of this writing, active discussion is occurring on the PR for the draft BIP.

  • ● PSBTv2 integration testing: Sjors Provoost posted to the Bitcoin-Dev mailing list to ask about software that had implemented support for version 2 PSBTs (see Newsletter #141) in order to help test a PR adding support for it to Bitcoin Core. An updated list of software using it may be found on the Bitcoin Stack Exchange. We found two replies interesting:

    • ● Merklized PSBTv2: Salvatore Ingala explains that the Ledger Bitcoin App converts the fields of a PSBTv2 into a merkle tree and initially sends only the root to a Ledger hardware signing device. When specific fields are needed, they are sent along with the appropriate merkle proof. This allows the device to safely work with each piece of information independently without having to store the entire PSBT in its constrained memory. This is possible with PSBTv2 because it already has the parts of the unsigned transaction separated into distinct fields; for the original PSBT format (v0), this required additional parsing.

    • ● Silent payments PSBTv2: BIP352 specifying silent payments explicitly depends on the BIP370 specification of PSBTv2. Andrew Toth explains that silent payments need v2’s PSBT_OUT_SCRIPT field since output script to use can’t be known for silent payments until all signers have processed the PSBT.

  • ● Correction about offchain DLCs: in our description of offchain DLCs in last week’s newsletter, we confused the new scheme proposed by developer conduition with previously published and implemented offchain DLC schemes. There’s a significant and interesting difference:

    • The DLC channels protocol mentioned in Newsletters #174 and #260 uses a mechanism similar to LN-Penalty commit-and-revoke where parties commit to a new state by signing it and then revoke the old state by releasing a secret that allows their private version of the old state to be completely spent by their counterparty if it is published onchain. This allows a DLC to be renewed through interaction between the parties. For example, Alice and Bob do the following:

      1. Immediately agree to a DLC for the BTCUSD price a month from now.

      2. Three weeks later, agree to a DLC for the BTCUSD price two months from now and revoke the previous DLC.

    • The new DLC factories protocol automatically revokes both parties’ ability to publish states onchain at the time the contract matures by allowing any oracle attestation for the contract to serve as the secret that allows a private state to be completely spent by a counterparty if it is published onchain. In effect this automatically cancels old states, which allows successive DLCs to be signed at the start of the factory without any further interaction required. For example, Alice and Bob do the following:

      1. Immediately agree to a DLC for the BTCUSD price a month from now.

      2. Also immediately agree to a DLC for the BTCUSD price two months from now with a transaction timelock that prevents it from being published until a month from now. They can repeat this for month three, four, etc…

    In the DLC channels protocol, Alice and Bob can’t create the second contract until they’re ready to revoke the first contract, which requires interaction between them at that time. In the DLC factories protocol, all contracts can be created at the time the factory is created and no further interaction is required; however, either party can still interrupt a series of contracts by going onchain with the currently safe-and-publishable version.

    If factory participants are able to interact after the contract is established, they can extend it—but they can’t decide to use a different contract or different oracles until after all previously signed contracts have matured (unless they go onchain). Although it may be possible to eliminate this shortcoming, this currently is the tradeoff for the reduced interactivity compared to the DLC channels protocol, which allows arbitrary contract changes at any time by mutual revocation.

    We thank conduition for informing us about our mistake in last week’s newsletter and for patiently answering our questions.

Changes to services and client software

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

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.

  • ● BTCPay Server 2.0.6 contains a “security fix for merchants using refunds/pull payments onchain with automated payout processors.” Also included are several new features and bug fixes.

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 #31397 improves the orphan resolution process by tracking and using all potential peers that can provide missing parent transactions. Previously, the resolution process relied solely on the peer that originally provided the orphaned transaction. If the peer did not respond or returned a notfound message, there was no retry mechanism, resulting in likely transaction download failures. The new approach attempts to download the parent transaction from all candidate peers while maintaining bandwidth efficiency, censorship resistance, and effective load balancing. It is particularly beneficial for one-parent one-child (1p1c) package relay, and it sets the stage for BIP331’s receiver-initiated ancestor package relay.

  • ● Eclair #2896 enables the storage of a MuSig2 peer’s partial signature instead of a traditional 2-of-2 multisig signature, as a prerequisite for a future implementation of simple taproot channels. Storing this allows a node to unilaterally broadcast a commitment transaction when needed.

  • ● LDK #3408 introduces utilities for creating static invoices and their corresponding offers in the ChannelManager, to support async payments in BOLT12 as specified in BOLTs #1149. Unlike the regular offer creation utility, which requires the recipient to be online to serve invoice requests, the new utility accommodates recipients who are frequently offline. This PR also adds missing tests for paying static invoices (see Newsletter #321), and ensures that invoice requests are retrievable when the recipient comes back online.

  • ● LND #9405 makes the ProofMatureDelta parameter configurable, which determines the number of confirmations required before a channel announcement is processed in the gossip network. The default value is 6.

Want more?

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