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.

  • ● Bitcoin Core #16248 extends the whitelisting configuration options in Bitcoin Core to allow specifying which services should be provided to different IP addresses or ranges. For example, a motivation for the change was allowing bloom filters to be provided to particular peers (such as a user’s own lightweight wallet) even if the filters are disabled by default. This can be done with -whitelist=bloomfilter@1.2.3.4/32. If only an IP address is provided (i.e., no permissions are specified), the behavior is the same as before.

  • ● Bitcoin Core #16383 changes RPC commands that accept an include_watchonly parameter so that it is automatically set to True for wallets that have private keys disabled (i.e. that are only useful as watch-only wallets). This ensures results for watch-only addresses are included in results.

  • ● Bitcoin Core #15986 extends the getdescriptorinfo RPC described in Newsletter #34 with an additional checksum field. The RPC already added a checksum to any descriptor provided without one, but it also normalized the descriptor by removing private keys and making other changes users might not want. The new field added in this merge returns the checksum for the descriptor exactly as it was provided by the user. Descriptor checksums follow a # character at the end of the string as described in the output script descriptor documentation.

  • ● Bitcoin Core #16060 adds the hardcoded block heights for previous soft forks as described in the news section.

  • ● LND #3391 always returns the same error message for failed payments in order to avoid leaking whether or not an invoice exists. See BOLTs #516 for more details about the information leak and BOLTs #608 for a related leak.

  • ● LND #3355 extends the GetInfo RPC with a SyncedToGraph bool that indicates whether or not the node thinks it has the latest gossip information so that it can efficiently route payments.