This week’s newsletter summarizes a discussion about updating the specification for BIP21 bitcoin: URIs, describes a proposal to manage multiple concurrent MuSig2 signing sessions with a minimum of state, links to a thread about adding editors for the BIPs repository, and discusses a set of tools that allow quickly porting the Bitcoin Core GitHub project to a self-hosted GitLab project. Also included are our regular sections announcing new releases and release candidates and summarizing recent changes to popular Bitcoin infrastructure software.

News

• ● Updating BIP21 bitcoin: URIs: Josie Baker posted to Delving Bitcoin to discuss how BIP21 URIs are specified to be used, how they’re used today, and how they can be used in the future. The specification requires the body immediately after the colon to be a legacy P2PKH Bitcoin address, e.g. bitcoin:1BoB.... After the body, additional parameters can be passed using HTTP query encoding, including addresses for non-legacy address formats. For example, a bech32m address could be bitcoin:1Bob...?bech32m=bc1pbob.... However, this is significantly different from how bitcoin: URIs are being used. Non-P2PKH addresses are often used as the body and sometimes the body is left blank by software that only wants to receive payment through an alternative payment protocol. Additionally, Baker notes that bitcoin: URIs are increasingly being used to transmit privacy-respecting persistent identifiers, such as those for silent payments and offers.

  As discussed on the thread, an improvement could be having the creator of the URI specify all of the payment methods they supported using bare parameters, for example: bitcoin:?bc1q...&sp1q.... The spender (who is usually responsible for paying fees) could then choose their preferred payment method from the list. Although some minor technical points were still being discussed at the time of writing, no major criticisms of this approach have been posted.

• ● PSBTs for multiple concurrent MuSig2 signing sessions: Salvatore Ingala posted to Delving Bitcoin about minimizing the amount of state needed to perform multiple MuSig2 signing sessions in parallel. Using the signing algorithm described in BIP327, a group of co-signers will need to temporarily store a linearly increasing amount of data for each additional input they want to add to a transaction they create. With many hardware signing devices limited in the amount of storage they have available, it would be very useful to minimize the amount of state required (without reducing security).

  Ingala proposes generating a single state object for an entire PSBT and then deterministically deriving the per-input state from it in a way that still makes the result indistinguishable from random. That way the amount of state a signer needs to store is constant no matter how many inputs a transaction has.

  In a reply, developer Christopher Scott noted that BitEscrow already uses a similar mechanism.

• ● Discussion about adding more BIP editors: Ava Chow posted to the Bitcoin-Dev mailing list to suggest the addition of BIP editors to help the current editor. The current editor, Luke Dashjr, says he is backlogged and has requested help. Chow suggested two well-known expert contributors to become editors, which seemed to have support. Also discussed was whether the additional editors should have the ability to assign BIP numbers. No clear resolution has been reached as of this writing.

• ● GitLab backup for Bitcoin Core GitHub project: Fabian Jahr posted to Delving Bitcoin about maintaining a backup of the Bitcoin Core project’s GitHub account on a self-hosted GitLab instance. In case the project ever needed to leave GitHub suddenly, this would make all existing issues and pull requests accessible on GitLab within a short amount of time, allowing work to continue with only a brief interruption. Jahr provided a preview of the project on GitLab and plans to keep backups going forward to allow rapidly switching to GitLab if necessary. His post has not received any comments as of this writing, but we thank him for making a potential transition as easy as possible.

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.

• ● Eclair v0.10.0 is a new major release of this LN node implementation. It “adds official support for the dual-funding feature, an up-to-date implementation of BOLT12 offers, and a fully working splicing prototype” in addition to “various on-chain fee improvements, more configuration options, performance enhancements and various minor bug fixes”.

• ● Bitcoin Core 26.1rc1 is a release candidate for a maintenance release of this predominant full node implementation.

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

• ● Bitcoin Core #29412 adds code that checks for every known way to take a valid block, mutate it, and produce an alternative block that is invalid but has the same block header hash. Mutated blocks have caused multiple vulnerabilities in the past. In 2012, and again in 2017, Bitcoin Core’s cached rejection of invalid blocks meant that an attacker could take a new valid block, mutate it into an invalid block, and submit it to a victim’s node; that node would reject it as invalid and would not later accept the valid form of the block (until the node was next restarted), forking it off the best block chain and allowing the attacker to perform a type of eclipse attack; see Newsletter #37 for details. More recently, when Bitcoin Core would request a block from one peer, a different peer could send a mutated block that would lead Bitcoin Core to stop waiting for the block from the first peer; a fix for this was described in Newsletter #251.

  The code added in this PR allows quickly checking whether a newly-received block contains one of the known mutation types that makes it invalid. If so, the mutated block can be rejected early on, hopefully preventing anything about it from being cached or used to prevent the correct processing of a valid version of the block that will be received later.

• ● Eclair #2829 allows plugins to set a policy for contributing funds towards a dual-funded channel open. By default, Eclair will not contribute funds towards opening a dual-funded channel. This PR allows plugins to override that policy and decide how much of the node operator’s funds should be contributed towards a new channel.

• ● LND #8378 makes several improvements to LND’s coin selection features, including allowing users to choose their coin selection strategy and also allowing a user to specify some inputs that must be included in a transaction but allowing the coin selection strategy to find any additional needed inputs.

• ● BIPs #1421 adds BIP345 for the OP_VAULT opcode and related consensus changes that, if activated in a soft fork, would add support for vaults. Unlike vaults possible today with presigned transactions, BIP345 vaults aren’t vulnerable to last-minute transaction substitution attacks. BIP345 vaults also allow batched operations that make them more efficient than most proposed designs that only use more generic covenant mechanisms.