This week’s newsletter summarizes a proposal for an update to the LN gossip protocol. Also included are our regular sections on bech32 sending support and notable changes in popular Bitcoin infrastructure projects.

Action items

None this week.

News

  • Gossip update proposal: Rusty Russell made a short proposal to update the gossip protocol that LN nodes use to announce what channels they have available for routing payments and what capabilities those channels currently support. Most notably, the proposal significantly reduces the byte size of messages through two mechanisms: schnorr signatures and optional message extensions. Schnorr signatures based on bip-schnorr save a few bytes because of their more efficient encoding compared to DER-encoded ECDSA signatures, but their most significant savings in the gossip improvement proposal comes from the ability to aggregate the two signatures for a channel announcement into a single signature using MuSig. Optional message extensions using Type-Length-Value (TLV) records allow omitting unnecessary details when the protocol defaults are being used (for more information about TLV, see the notable code and documentation changes section below).

Bech32 sending support

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

We have heard from wallet providers that a reason for their hesitation to default to receiving to bech32 addresses is concern that they’d see a significant increase in customer support requests. Despite this, some wallets already default to bech32 addresses and others plan to move to use them soon, such as Bitcoin Core.

We solicited input from a number of services including BitGo, BRD, Conio, Electrum, and Gemini regarding their customer support burden from use of bech32 addresses. Most services report minimal issues (“no support requests” and “there isn’t too much confusion”).

One service said, “So Bitcoin address-related customer support tickets increased 50%, but the absolute number of tickets is so small that not sure we can give too much significance. There have never been many tickets on this subject either before or after Bech32 so not sure this is an important point in making the argument for exchanges to make the switch. Instead, I might suggest focusing on fees, which really can add up if you are using an old wallet implementation.”

Electrum has seen some reports though, which are public, such as “strange addresses” and “Localbitcoins does not support sending to bech32”.

While not conclusive, it is reassuring that services opting to support receiving to bech32 addresses have not seen a negative impact on their customer support teams. The suggestion above to consider fee savings likely far outweighs concerns, and is consistent with Bitcoin Optech’s guidance. With few negative reports and significant potential fee savings for those wallets and services that support receiving to bech32 addresses, it may be time for more wallets to begin making bech32 their default address format. If that happens, it’ll be even more important for other wallets and services to support sending to bech32 addresses.

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 #15277 allows the Linux versions of Bitcoin Core to be deterministically compiled using GNU Guix (pronounced “geeks”). This requires much less setup than the currently-still-supported mechanism based on Gitian and so it is hoped that it will lead to a greater number of users being able to independently verify that the release binaries are derived solely from the Bitcoin Core source code and its dependencies. Additionally, Guix requires fewer build environment dependencies and there is ongoing work to essentially eliminate its need for any pre-compiled binaries in the typical build toolchain, both of which make the build system much easier to audit. Altogether this should reduce the amount of trust users need to place in the developers of Bitcoin Core and the software used to build Bitcoin Core. Although this merged PR only builds Linux binaries, it is expected that support for Windows and macOS will follow. For more information, see PR author Carl Dong’s recent talk from the Breaking Bitcoin conference (video, transcript).

  • BOLTs #607 extends the LN specification to allow packets to contain records that start with a type identifying their purpose, followed by the message length and the record’s value, called TLV records. Because each message starts with a type and a length, LN nodes can ignore records with a type they don’t understand—e.g., optional parts of the specification that are newer than the node or experimental records that are only being used by a subset of nodes and so aren’t part of the spec yet. Existing LN records haven’t been converted to use TLV, but subsequently-added optional records are expected to use this format. All LN implementations monitored by Optech currently support TLV on at least their development branch.

  • BIPs #784 updates BIP174 Partially Signed Bitcoin Transactions (PSBTs) to include a BIP32 extended pubkey (xpub) field in the global section. This is described in a new part of the BIP entitled “Change Detection” that describes how signing wallets can use this new field to identify which outputs belong to that wallet (in whole or as part of a set of wallets using multisig). The idea for this modification of the specification was previously discussed on the Bitcoin-Dev mailing list as described in Newsletter #46.