This week’s newsletter asks for comments on the miniscript language, publishes our final bech32 sending support section, includes popular Q&A from the Bitcoin StackExchange, and describes several notable changes to popular Bitcoin infrastructure projects.

Action items

● Evaluate miniscript: wallet developers are encouraged to evaluate this proposed language that can allow wallets to adapt to new script templates without requiring changes to the underlying wallet code for each new template. See the news section for details.

News

Bech32 sending support

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

After six months and over 10,000 words published, this is our last bech32 sending support section. Our goal was to gently persuade as many developers as possible to add support for paying bech32 addresses in their applications. We hoped that would make it easier for segwit-ready wallets to switch from using P2SH-wrapped segwit addresses by default to more efficient native segwit bech32 addresses.

By our efforts and by the efforts of many other Bitcoiners, we think we’re on the brink of success: 19 of the 23 popular wallets and services we’ve evaluated are ready to pay bech32 addresses and 4 already generate bech32 receiving addresses by default.

Every week, it’s looking more and more reasonable for wallets to switch to bech32 soon, and we expect to hear from an increasing number of developers that their next major release will default to bech32 receiving addresses. This will lower the transaction fees for the users of that software and make more block space available to all Bitcoin users, helping to keep fees lower for everyone a little bit longer.

Even though this series has ended, we’ll continue to update the segwit section of the compatibility matrix and report on notable bech32 developments in the other parts of the weekly newsletter. We thank all of you for reading this series and for helping to improve Bitcoin scalability one wallet and service at a time.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments of time to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers made since our last update.

Notable code and documentation changes

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

● LND #2203 adds a rejecthtlc configuration option that will prevent the node from forwarding payments for other nodes but will still allow it to accept incoming payments and send outgoing payments.

● LND #3256 increases the number of inferences LND draws from routing failures and uses that information to adjust subsequent routes. For example, nodes are now penalized in the routing preference database if they produce an error message that they shouldn’t be generating given their particular role in a transaction (e.g. intermediate node or final node).

● BOLTs #608 provides a privacy update to BOLT4 that makes it harder for a routing node to identify which node is ultimately receiving a payment. Previously, the final node would send a final_expiry_too_soon error if it received a payment due to expire too soon in the future. Other non-final nodes would simply report that they didn’t recognize the payment. This made it possible to probe various channels to determine the recipient. The updated BOLT now recommends final nodes send a generic incorrect_or_unknown_payment_details message even when they know the problem is a too-soon expiry. This is the same basic privacy leak and solution described for the wrong-amount problem in last week’s newsletter.

Special thanks

We thank Pieter Wuille and Sanket Kanjalkar for reviewing drafts of this newsletter and helping us understand the full range of miniscript’s capabilities. Any remaining errors are the fault of the newsletter author.