This week’s newsletter links to several discussions about activating taproot and summarizes a proposed update to BIP173 bech32 addresses. Also included are our regular sections summarizing interesting changes to services and client software, releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● Taproot activation discussions: several discussions were started or continued this week about choosing a method for activating taproot.

    • ● New IRC room: Steve Lee posted to the Bitcoin-Dev mailing list an announcement of a new ##taproot-activation IRC room on the Freenode network. The channel is logged and saw an impressive amount of conversation from dozens of participants during its first week.

    • ● Mailing list thread: Anthony Towns posted a summary of the recently updated BIP8 activation method (see Newsletter #104) and of his own new bip-decthresh activation proposal (based on Matt Corallo’s “modern soft fork activation” post in January, see Newsletter #80). An interesting feature of the decreasing threshold idea is that the amount of network hashrate needed to signal readiness to enforce the new soft fork rules would decrease during the final activation period, allowing miner activation with perhaps as little as 60% miner support rather than the 95% miner support needed during the first activation period.

  • ● Bech32 address updates: Russell O’Connor posted to the Bitcoin-Dev mailing list a reply to Pieter Wuille’s November post (see Newsletter #77) about amending BIP173 to only allow witness programs of either 20 or 32 bytes, minimizing the risk that typos would cause a user to irrecoverably send bitcoins to a wrong address. O’Connor made the counter-proposal that we could allow any witness program that had five more characters in its address than the next shortest address, up to the consensus-enforced length limit on witness programs. The counter-proposal didn’t receive any discussion on the mailing list, but a PR to update BIP173 did receive several comments. As of this writing, no conclusion has been reached about what length restrictions to use.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • ● LND 0.10.4 is a minor release that fixes a bug affecting backups on Windows.

  • ● C-Lightning 0.9.0rc2 is a release candidate for an upcoming major release. It adds support for the updated pay command and new keysend RPC described in this newsletter’s notable code changes section, among several other notable changes and multiple bug fixes.

Notable code and documentation changes

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

  • ● Bitcoin Core #19109 introduces further improvements to transaction-origin privacy. Building on Bitcoin Core #18861, this patch adds a per-peer rolling bloom filter to track which transactions were recently announced to the peer. When a peer requests a transaction, this upgrade checks the filter before fulfilling the request and relaying the transaction to prevent spy nodes from learning about the exact contents of our mempool or the precise timing of when a transaction was received.

  • ● Bitcoin Core #16525 updates several RPCs to return transaction version numbers as unsigned integers rather than signed integers. Early versions of Bitcoin interpreted version numbers as signed integers (and some transactions in the chain did actually set negative version numbers), but the introduction of BIP68 nSequence enforcement for transactions with version 2 or higher specified that it would match against transaction nVersion fields cast to unsigned integers. It’s expected that any other future soft forks that use transaction versions will specify the same rule, and so it makes sense for RPCs to always return unsigned numbers for transaction versions.

  • ● C-Lightning #3809 adds support to C-Lightning for effective sending of multipath payments—payments which are split into several parts, with each part routed using a different path. In brief, the algorithm C-Lightning uses splits a payment into parts of approximately 0.0001 BTC in value (each part having its amount randomly fuzzed by plus or minus 10%). If any sent part fails, that part is split into two parts (roughly in half, plus or minus 10%) and the two parts are re-sent. The PR additionally adds a disable-mpp configuration option that will prevent sending any multipath payments; a parameter of the same name is also added to the pay command to disable sending a multipath payment for that particular attempt.

  • ● C-Lightning #3825 changes the recently merged (but never released) reserveinputs RPC so that it no longer generates a new PSBT. Instead, a new fundpsbt RPC is introduced to create a new PSBT. An existing PSBT may now be passed to reserveinputs to prevent the UTXO inputs to the PSBT from being used in other transactions until a specified block height (default, 72 blocks in the future, about 12 hours from present) or as long as the daemon is running. Alternatively, fundpsbt will default to reserving the selected UTXOs when it creates the transaction.

  • ● C-Lightning #3826 completes a series of PRs that modify the logic C-Lightning uses to send payments. Most of those changes should be invisible to users, but in case of problems, the previous logic available with the pay command is available using the new legacypay command. Anyone using the pay command from this point forward will be using the new logic.

  • ● C-Lightning #3792 adds a new keysend RPC for sending spontaneous payments. This new RPC is different from the keysend plugin, described in Newsletter #94, which allows C-Lightning to receive spontaneous payments.

  • ● LND #4429 adds a --protocol.wumbo configuration option and enables it by default. When supported by both the local node and a remote peer, this option allows the opening of large channels where the total channel value exceeds 0.16 BTC.