This week’s newsletter announces a new major version of Bitcoin Core, provides some updates on Bitcoin and LN developer mailing lists, and describes recent developments in the ongoing schnorr/taproot review. Also included are our regular sections with top-voted questions and answers from the Bitcoin StackExchange and notable changes to popular Bitcoin infrastructure projects.

● New LND mailing list and new host of existing mailing lists: a new mailing list hosted by Google Groups was announced for LND application developers, with an initial post by Olaoluwa Osuntokun describing short-term goals for LND’s next release. Separately, the existing mailing lists for Bitcoin-Dev and Lightning-Dev have recently had their hosting transferred to Oregon State University’s Open Source Lab (OSL), a well-respected organization that provides hosting to a variety of open source projects. Optech extends our thanks to Warren Togami, Bryan Bishop, and everyone else involved in maintaining all of Bitcoin’s many open communication channels, without which this newsletter wouldn’t exist.

For a full list of notable changes, links to the PRs where those changes were made, and additional information useful to node operators, please see the Bitcoin Core project’s release notes .

● Optional privacy-preserving address management: a new avoid_reuse wallet flag, which can be toggled using a new setwalletflag RPC, can be enabled to prevent the wallet from spending bitcoins received to an address that was previously used (see Newsletter #52 ). This prevents certain privacy leaks based on block chain analysis such as dust flooding .

● GUI improvements: graphical users can now create new wallets for use with multiwallet mode from the GUI’s file menu (see Newsletter #63 ). The GUI also now provides users with bech32 Bitcoin addresses by default, but users can easily request a backwards-compatible P2SH-P2WPKH address by toggling a checkbox next to the button to generate an address (see Newsletter #42 ).

● Customizable permissions for whitelisted peers: when specifying which peers or interfaces should be whitelisted, users can now specify which special features the whitelisted peers can access. Previously, whitelisted peers wouldn’t be banned and received relayed transactions faster. These defaults haven’t changed, but now it’s possible to toggle those settings on a per-peer basis or to allow specified whitelisted peers to request BIP37 bloom filters even though they’re disabled for non-whitelisted peers by default. For details, see Newsletter #60 .

● Deprecated or removed features: support for the BIP70 payment protocol, BIP37 P2P protocol bloom filters, and BIP61 P2P protocol reject messages has been disabled by default, eliminating the source of various problems (respectively, see Newsletters #19 , #57 , and #37 ). The payment protocol and reject messages are scheduled to be fully removed in the next major Bitcoin Core version about six months from now.

● BIP158 block filters (RPC only): users can now set a new configuration option, blockfilterindex , if they want Bitcoin Core to generate compact block filters as specified by BIP158 . The filter for each block can then be retrieved using the new RPC getblockfilter . Filters can be provided to a compatible lightweight client to allow it to determine whether a block might contain any transactions involving its keys (see Newsletter #43 for more information). PR#16442 is currently open to add support for the corresponding BIP157 protocol that will allow sharing these filters with clients over the P2P network.

● CPFP carve-out: this new mempool policy helps two-party contract protocols (such as the current LN) ensure that both parties will be able to use Child-Pays-For-Parent (CPFP) fee bumping (see Newsletter #63 ). LN developers already have a proposal under discussion for how they’ll use this feature to simplify fee management for commitment transactions (see newsletters #70 and #71 ).

● Bitcoin Core 0.19 released: featuring over 1,000 commits from more than 100 contributors, the latest Bitcoin Core release offers several new user-visible features, numerous bug fixes, and multiple improvements to internal systems such as P2P network handling. Some changes which may be especially interesting to newsletter readers include:

Bitcoin StackExchange 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.

● What is the difference between Bitcoin policy language and Miniscript? Pieter Wuille, James C., and sanket1729 explain the relationship between Bitcoin Script, the policy language (a tool for humans to design spending conditions), and miniscript (a more structured representation of Bitcoin Script for communication and analysis).

● How does the bech32 length-extension mutation weakness work? Jnewbery asks for details about why adding or removing q characters immediately before the final p character of an address can sometimes produce a new bech32 address that’s valid. Pieter Wuille provides some algebraic details about why the problem is more likely to occur than the roughly 1-in-a-billion chance expected for any random length-change error to go undetected. MCCCS provides a second explanation using some of the applicable code from Bitcoin Core.

● MuSig Signature Interactivity Justinmoon asks why MuSig signing is always interactive and about secure, offline interactive signing. Nickler explains each of the rounds involved with MuSig signing as well as some pitfalls to avoid during signing.

● Would a schnorr pubkey be a different length than a taproot pubkey like P2WPKH and P2WSH? Murch explains that, unlike segwit v0 which has different P2WPKH and P2WSH output types and lengths, all segwit v1 Pay-to-Taproot (P2TR) outputs are always the same length.

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

● Bitcoin Core #16944 updates the GUI to generate a BIP174 Partially Signed Bitcoin Transaction (PSBT) and automatically copies it to the clipboard if the user tries to create a transaction in a watch-only wallet that has its private keys disabled. The PSBT can then be copied into another application for signing (e.g. HWI). The GUI doesn’t yet provide a special dialog for copying the signed PSBT back in for broadcasting.

● Bitcoin Core #17290 changes which coin selection algorithm is used in cases where the user requests certain inputs be used or asks that the fee be selected from the payment amounts. These now use Bitcoin Core’s normal default algorithm of Branch and Bound (BnB). BnB was designed to minimize fees and maximize privacy by optimizing for the creation of changeless transactions.

● C-Lightning #3264 includes several mitigations for LND #3728, a bug in the implementation of gossip queries. This change also adds two new command line parameters useful for testing and debugging, --hex and --features .

● C-Lightning #3274 causes lightningd to refuse to start if it detects that bitcoind is now on a lower block height than it was the last time lightningd was run. If a lower height is seen while lightningd is running, it will simply wait until a higher height is seen. Block heights can decrease during a block chain reorganization, during a block chain reindex, or if the user runs certain commands intended for developer testing. It’s easier and safer for lightningd to wait for those situations to be resolved by bitcoind than it is to try to work around the problems. However, if the LN user really wants to use the truncated chain, they can start lightningd with the --rescan parameter to reprocess the block chain.

● Eclair #1221 adds a networkstats API that returns various information about the LN network as observed from the local node, including the number of known channels, number of known LN nodes, the capacity of LN nodes (grouped into percentiles), and the fees that nodes are charging (also grouped into percentiles).

● LND #3739 makes it possible to specify what node should be the last hop on a route before a payment is delivered to the receiver. In conjunction with other still-pending work, such as LND #3736, this will make it possible for a user to rebalance their channels using built-in LND features (instead of requiring external tools, as is currently the case).

● LND #3729 makes it possible to generate invoices with millisatoshi precision. Previously, LND would not generate invoices with sub-satoshi precision.