This week’s newsletter notes a change to Bitcoin Core’s consensus logic and announces a new feature on the Optech website for tracking technology adoption between different wallets and services. Also included are our regular sections about bech32 sending support and notable changes in popular Bitcoin infrastructure projects.

Action items

● Upgrade to C-Lightning 0.7.2.1: this release contains several bug fixes as well as new features for plugin management and support for the in-development alternative to testnet, signet.

News

● Hardcoded previous soft fork activation blocks: the heights of the blocks where two previous soft forks activated have now been hardcoded into Bitcoin Core as the point where those forks activate. This means any block chain reorganization that extends further back than those blocks can create a chainsplit between nodes with this hardcoding and those without it. However, such a reorganization would require an amount of proof of work roughly equal to the annual output of all active Bitcoin miners (at the time of writing), so this is considered to be both very unlikely and indicative of a threat that could prevent consensus formation anyway. The hardcoding, which is similar to the BIP90 hardcoding made a couple of years ago, simplifies Bitcoin Core’s consensus code. For more information, see the mailing list post or PR #16060.

● New Optech Compatibility Matrix: a new feature on the Optech website shows what wallets and services support certain recommended features, currently opt-in Replace-by-Fee (RBF) and segwit (with more comparisons planned for the future). The matrix is designed to help developers gauge how well supported features are and learn from the designs of early adopters. For details, please see our announcement post.

Bech32 sending support

Week 23 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

The News section from this week’s newsletter introduced a new feature on the Optech website. As of this writing, here are what we think are some of the most significant bech32-related insights we’ve gleaned from creating and reviewing the Compatibility Matrix.

Most tools support paying bech32 addresses: 74% of the wallets and services surveyed support paying to segwit addresses. Although this isn’t the near-universal support we’d like to see, it may be enough support that we’ll soon see more wallets switching to bech32 receiving addresses by default.

Supporting P2WPKH but not P2WSH: when we started testing various apps, we assumed “bech32 sending support” would be binary—either a tool supported it or not. However, one service we surveyed supports spending money to native segwit (bech32) P2WPKH addresses but not bech32 P2WSH addresses. This led us to tracking the two different segwit version 0 addresses separately. (If you’re a developer, please support sending to both address types.)

Address input field length restrictions: some services might have supported sending to bech32 addresses, but when we attempted to enter a bech32 address, either it was rejected as being too long or the field simply refused to accept all the characters. (Reminder, BIP173 says this about the lengths of Bitcoin mainnet bech32 addresses: they “are always between 14 and 74 characters long [inclusive], and their length modulo 8 cannot be 0, 3, or 5.”)

Screenshots of input fields: we documented the steps we took to try sending to bech32 addresses, which gives us a large collection of screenshots that UI designers can review for best practices when implementing their own bech32 sending support (or other features, such as RBF support).

Lack of bech32 change address support: because sending to bech32 addresses is still not universally supported, it makes sense for segwit-compatible wallets to generate P2SH-wrapped segwit receiving addresses by default. However, many of these wallets also use P2SH-wrapped segwit addresses for receiving change sent from themselves to themselves. In some cases, this may have been done for privacy benefits (e.g. Bitcoin Core currently tries to match the type of change output to the type of payment output) but, in most cases, this seems like a missed opportunity for wallets to send change to their own bech32 addresses for increased fee savings.

Notable code and documentation changes

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