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.
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,
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
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.
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
-email@example.com/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
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.