This week’s newsletter announces a new aggregate signature protocol compatible with secp256k1 and describes a standardized backup scheme for wallet descriptors. Also included are our regular sections summarizing recent Bitcoin Stack Exchange questions and answers, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

• ● Interactive aggregate signatures compatible with secp256k1: Jonas Nick, Tim Ruffing, Yannick Seurin posted to the Bitcoin-Dev mailing list to announce a paper they’ve written about creating 64-byte aggregate signatures compatible with the cryptographic primitives already used by Bitcoin. Aggregate signatures are the cryptographic requirement for cross-input signature aggregation (CISA), a feature proposed for Bitcoin that could reduce the size of transactions with multiple inputs, which would reduce the cost of many different types of spending—including privacy-enhanced spending through coinjoins and payjoins.

  In addition to an aggregate signature scheme like the DahLIAS scheme proposed by the authors, adding support for CISA to Bitcoin would require a consensus change and possible interactions between signature aggregation and other proposed consensus changes that may warrant further study.

• ● Standardized backup for wallet descriptors: Salvatore Ingala posted to Delving Bitcoin a summary of various tradeoffs related to backing up wallet descriptors and a proposed scheme that should be useful for many different types of wallets, including those using complex scripts. His scheme encrypts descriptors using a deterministically generated 32-byte secret. For each public key (or extended public key) in the descriptor, a copy of the secret is xored with a variant of the public key, creating n 32-byte secret encryptions for n public keys. Anyone who knows one of the public keys used in the descriptor can xor it with the 32-byte secret encryption to get the 32-byte secret that can decrypt the descriptor. This simple and efficient scheme allows anyone to store many encrypted copies of a descriptor across multiple media and network locations, and then use their BIP32 wallet seed to generate their xpub, which they can use to decrypt the descriptor if they ever lose their wallet data.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

• ● Practicality of half-aggregated schnorr signatures? Fjahr discusses why independent, unaggregated signatures are not required in order to validate a half-aggregated signature in cross-input signature aggregation (CISA) and why unaggregated signatures can actually be problematic.

• ● What’s the largest size OP_RETURN payload ever created? Vojtěch Strnad links to a Runes meta-protocol transaction with 79,870 bytes as the largest OP_RETURN.

• ● Non-LN explanation of pay-to-anchor? Murch details the rationale and structure of pay-to-anchor (P2A) output scripts.

• ● Up-to-date statistics about chain reorganizations? 0xb10c and Murch point to sources of reorg data, including the stale-blocks repository, the forkmonitor.info website, and the fork.observer website.

• ● Are Lightning channels always P2WSH? Polespinasa notes the ongoing development of P2TR simple taproot channels and summarizes current support across Lightning implementations.

• ● Child-pays-for-parent as a defense against a double spend? Murch lists complications with using a high fee CPFP child transaction to incentivize a blockchain reorg in defense of an already-confirmed double-spent output.

• ● What values does CHECKTEMPLATEVERIFY hash? Average-gray outlines the fields that OP_CHECKTEMPLATEVERIFY commits to: nVersion, nLockTime, input count, sequences hash, output count, outputs hash, input index, and in some cases the scriptSig hash.

• ● Why can’t Lightning nodes opt to reveal channel balances for better routing efficiency? Rene Pickhardt explains concerns about the staleness and trustworthiness of the data, privacy implications, and points to a similar proposal from 2020.

• ● Does post-quantum require hard fork or soft fork? Vojtěch Strnad outlines an approach of how a post-quantum (PQC) signature scheme could be soft-fork activated as well as how a hard or soft fork could lock quantum-vulnerable coins.

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.

• ● LND 0.19.0-beta.rc3 is a release candidate for this popular LN node. One of the major improvements that could probably use testing is the new RBF-based fee bumping for cooperative closes.

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 #31247 adds support for serializing and parsing MuSig2 PSBT fields as specified in BIP373 to allow wallets to sign and spend MuSig2 inputs. On the input side, this consists of a field listing the participant pubkeys, plus a separate public nonce field and a separate partial signature field for each signer. On the output side, it is a single field listing the participant pubkeys for the new UTXO.

• ● LDK #3601 adds a new LocalHTLCFailureReason enum to represent each standard BOLT4 error code, along with some variants that surface additional information to the user that was previously removed for privacy reasons.

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 April 29. The discussion is also recorded and will be available from our podcasts page.