This week’s newsletter announces the release of LND 0.8.2-beta, requests help testing the latest C-Lightning release candidate, discusses widespread support for basic multipath payments in LN, provides an update on bech32 error detection reliability, summarizes updates to the proposed OP_CHECKTEMPLATEVERIFY opcode, and links to a discussion about the impact of eclipse attacks on LN channels. Also included are our regular sections about notable changes to popular Bitcoin infrastructure projects, changes to services and client software, and popular Bitcoin StackExchange questions and answers.

● Review bech32 action plan: as described below , Pieter Wuille suggests restricting all bech32 addresses to 20 or 32 byte witness programs in order to prevent a loss of funds from transcription errors involving addresses ending with a p . This rule already applies to v0 segwit addresses used for P2WPKH and P2WSH, so the change would simply be extending it to v1+ addresses currently reserved for future upgrades (such as the proposed taproot ). This will require wallets and services that have already implemented bech32 sending support to upgrade their code, but it should be a tiny change; e.g. for the Python reference implementation it might look something like:

● Help test C-Lightning 0.8.0 RC: the release candidate for the next version of C-Lightning switches the default network to mainnet instead of testnet (see Newsletter #75 ) and adds support for basic multipath payments (described below) among many other features and bug fixes.

● LN implementations add multipath payment support: after a significant amount of discussion and development, all three LN implementations tracked by Optech have now added basic support for multipath payments (merges: C-Lightning, Eclair, LND). A multipath payment consists of multiple LN payments routed over different paths which may all be claimed at the same time by the receiver. This provides a major upgrade to the usability of LN by allowing users to spend or receive funds in several of their channels in the same overall payment. This upgrade means that spenders in particular have much less need to worry about how much balance they have in any particular channel as they can send up to their full available balance across all their channels (subject to other LN limits).

● Analysis of bech32 error detection: Pieter Wuille sent an email to the Bitcoin-Dev mailing list following up on the bech32 malleability concerns described in previous newsletters (#72, #74, and #76) where it’s possible to add or remove any number of q characters immediately before a p character at the end of a bech32 string. Wuille’s analysis shows that this is the only exception to bech32’s expected error detection properties and that “changing one constant in bech32 would resolve this issue.” Wuille plans to amend BIP173 to describe the weakness, propose a change to limit existing bech32 address uses to either 20 byte or 32 byte witness program payloads, and define a modified version of bech32 with the alternative constant for non-Bitcoin uses and for a potential future where we want witness programs that are not 20 bytes or 32 bytes.

● Proposed changes to bip-ctv: Jeremy Rubin suggested several changes to the proposed soft fork addition of an OP_CHECKTEMPLATEVERIFY (CTV) opcode. Most notably, the changes will remove the restriction that templates used by CTV cannot be derived from other data via Bitcoin Script. This update simplifies the modification to the Script language discussed in Newsletter #75. None of the updates modifies CTV’s behavior in a way that would significantly affect previously described usecases as far as we’re aware (but anyone who is aware of fundamental changes is encouraged to discuss them on-list).