This week’s newsletter requests help testing the next version of LND, summarizes a discussion about soft fork activation mechanisms, and describes a few notable changes to popular Bitcoin infrastructure software.

Action items

• ● Help test LND 0.9.0-beta-rc1: this pre-release of the next major version of LND brings several new features and bug fixes. Experienced users are encouraged to help test the software so that any problems can be identified and fixed prior to release.

News

• ● Discussion of soft fork activation mechanisms: Matt Corallo started a discussion on the Bitcoin-Dev mailing list about what attributes are desirable in a soft fork activation method and submitted a proposal for a mechanism that contains those attributes. In short, the attributes are:

  1. The ability to abort if a serious objection to the proposed consensus rules changes is encountered

  2. The allocation of enough time after the release of updated software to ensure that most economic nodes are upgraded to enforce those rules

  3. The expectation that the network hash rate will be roughly the same before and after the change, as well as during any transition

  4. The prevention, as much as possible, of the creation of blocks that are invalid under the new rules, which could lead to false confirmations in non-upgraded nodes and SPV clients

  5. The assurance that the abort mechanisms can’t be misused by griefers or partisans to withhold a widely desired upgrade with no known problems

  Corallo believes that a well-crafted soft fork using the BIP9 versionbits activation mechanism and surrounded with good community engagement fulfills the first four criteria—but not the fifth. Alternatively, a BIP8 flag-day soft fork fulfills the fifth criteria but encounters challenges fulfilling the other four criteria. Corallo also worries that using BIP8 from the start of a soft fork deployment gives the impression that the developers of node software get to decide the rules of the system.

  As an alternative to either BIP9 or BIP8 alone, Corallo proposes a three-step process: use BIP9 to allow a proposal to be activated within a one-year window; pause for a six-month discussion period if the proposal is not activated; and—if it’s clear that the community still wants the proposal activated—force activation using a BIP8 flag day set to two years in the future (with faster activation possible using versionbits signaling). Node software can prepare for this maximum 42-month process by including, even in its initial versions, a configuration option that users can manually enable to enforce the BIP8 flag day if necessary. If the first 18 months of the activation period passes without activation (but also without any blocking problems being discovered), new releases can enable this option by default for the remaining 24 months of the activation period.

  In the responses to the post, Jorge Timón and Luke Dashjr both proposed that any BIP8-like mechanism use mandatory versionbits signaling leading up to the flag day (similar to how BIP148 proposed to activate segwit); Corallo notes that this conflicts with the third and fourth goals. Jeremy Rubin provides a quick analysis of his previous spork proposal (see Newsletter #32) in the context of the five goals. Anthony Towns provides lucid commentary on several aspects of Corallo’s proposal and Timón’s response.

  No clear conclusion was reached in the thread and we expect to see continued discussion.

Notable code and documentation changes

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

• ● Bitcoin Core #17578 updates the getaddressinfo RPC to return an array of strings corresponding to the label used by an address. Previously, it returned an array of objects where the label contained fields for its name and its purpose, where purpose corresponded to the part of the wallet that generated the address. Users who need the old behavior can use the -deprecatedrpc=labelspurpose configuration parameter until Bitcoin Core 0.21.

• ● Bitcoin Core #16373 causes the bumpfee RPC used for Replace-by-Fee fee bumping to return a Partially Signed Bitcoin Transaction (PSBT) when the user attempts to fee bump a transaction using a wallet with disabled private keys. The PSBT can then be copied to an external wallet (such as a hardware device or cold wallet) for signing.

• ● Bitcoin Core #17621 fixes a potential privacy leak for users of the avoid_reuse wallet flag. The flag prevents the wallet from spending bitcoins received to an address the wallet has already used for spending (see Newsletter #52). This enhances privacy by preventing otherwise-unrelated transactions from being associated together because they all involve the same address. However, Bitcoin Core currently monitors for payments to any of its public keys using any of several different address formats. This meant that multiple payments to the same public key—but with different addresses (e.g. P2PKH, P2WPKH, P2SH-P2WPKH)—could be associated with each other on the block chain even though the avoid_reuse behavior is supposed to prevent this type of linkability. This merged PR fixes the problem for the avoid_reuse flag, and the ongoing adoption of output script descriptors is expected to eliminate the problem of Bitcoin Core monitoring for alternative addresses. This change is expected to be backported into the next Bitcoin Core maintenance release (see PR #17792).

• ● LND #3829 makes a number of internal changes and documentation updates in order to simplify adding anchor outputs in the future.