This week’s newsletter contains our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

No significant news this week was found on the Bitcoin-Dev or Lightning-Dev mailing lists.

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.

• ● Did the P2SH BIP-0016 make some Bitcoin unspendable? User bca-0353f40e lists 6 outputs that existed with the P2SH script format, OP_HASH160 OP_DATA_20 [hash_value] OP_EQUAL, before BIP16’s activation. One of those outputs had been spent under the old rules before activation and an exception made for that single block in the P2SH activation code. Other than this exception, activation applied back to the genesis block so the remaining UTXOs would need to satisfy BIP16 rules in order to be spent.

• ● What software was used to make P2PK transactions? Pieter Wuille notes that P2PK outputs were created using the original Bitcoin software in coinbase transactions as well as when sending using pay-to-IP address.

• ● Why are both txid and wtxid sent to peers? Pieter Wuille references BIP339 and explains that while using wtxid is better for relay (due to malleability among other reasons), some peers do not support the newer wtxid identifiers and txids are supported for older pre-BIP339 peers for backward compatibility.

• ● How do I create a taproot multisig address? Pieter Wuille points out that Bitcoin Core’s existing multisig RPCs (like createmultisig and addmultisigaddress) will only support legacy wallets and outlines that with Bitcoin Core 24.0, users will be able to use descriptors and RPCs (like deriveaddresses and importdescriptors) along with the new multi_a descriptor to create taproot-compatible multisig scripts.

• ● Is it possible to skip Initial Block Download (IBD) on pruned node? While not currently supported in Bitcoin Core, Pieter Wuille points to the assumeutxo project which would allow for a new node to bootstrap by fetching a UTXO set that can be verified by a hard-coded hash.

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.15.5-beta.rc2 is a release candidate for a maintenance release of LND. It contains only minor bug fixes according to its planned release notes.

• ● Core Lightning 22.11rc2 is a release candidate for the next major version of CLN. It’ll also be the first release to use a new version numbering scheme, although CLN releases continue to use semantic versioning.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• ● Bitcoin Core #25730 updates the listunspent RPC with a new argument that will include in the results any immature coinbase outputs—outputs which can’t yet be spent because fewer than 100 blocks have passed since they were included in the miner coinbase transaction of a block.

• ● LND #7082 updates the way invoices without requested amounts are created to allow the inclusion of route hints, which can help the spender find a path to the receiver.

• ● LDK #1413 removes support for the original fixed-length onion data format. The upgraded variable-length format was added to the specification over three years ago and support for the old version has already been removed from the specification (see Newsletter #220), Core Lightning (Newsletter #193), LND (Newsletter #196), and Eclair (Newsletter #217).

• ● HWI #637 adds support for a major planned upgrade of the Bitcoin-related firmware for Ledger devices. Not included in this PR but mentioned in its description as future planned work is the policy management work mentioned in Newsletter #200.