This week’s newsletter relays a security warning for LND users, summarizes discussion about LN upfront payments, describes a mailing list thread about updating bech32 addresses for taproot, and links to an updated proposal for an alternative way to secure LN payments. Also included are our regular sections with summaries of a Bitcoin Core PR Review Club meeting, releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

Action items

  • ● Upgrade LND to 0.11.x: the LND development team posted announcements to the Lightning-Dev and LND Engineering mailing lists warning users about the planned disclosure on 20 October 2020 of vulnerabilities affecting LND versions 0.10.x and earlier. The team “strongly urge[s] the community to upgrade to lnd 0.11.0 or above [as soon as possible].” (Note: the mailing list archive software slightly alters the text of the announcement, so anyone wanting to verify the PGP signature on the announcement should follow some additional steps.)

News

  • ● LN upfront payments: in the current LN protocol, the attempt to route a payment can lock part of a routing node’s funds for hours or days. Since routing fees are only paid if a payment succeeds, an attacker can use payments designed to fail in order to prevent routing nodes from earning income on the capital they store in their channels. One previously discussed option that may better align incentives is to charge a non-refundable fee upfront when a routing request is received (see Newsletter #72).

    This week on the Lightning-Dev mailing list, a discussion about a proposed minor protocol change transformed into a conversation about upfront fees:

    • ● Incremental routing: ZmnSCPxj described a nested encrypted tunneling protocol where routes would be built incrementally, with the spender being able to pay each successive routing hop independently. This would ensure routing fees couldn’t be stolen by an earlier hop that deliberately failed a route. A downside to this approach is that it would require a significant number of network round trips, which could make even successful payments take a long time. A spy node that kept track of routed message timing and HTLC duration could also estimate how many hops away the spender or receiver are from it, reducing the amount of privacy users would receive from LN.

    • ● Trusted upfront payment: Antoine Riard promoted the idea of simply paying the upfront fees and, if your peer steals them, downgrade their score so that your routing algorithm prefers not to use them again. Assuming a single upfront fee is much smaller than the aggregate amount of fees a peer could earn over weeks or months of routing, there should be an incentive to behave honestly.

  • ● Bech32 addresses for taproot: Rusty Russell resumed a previous discussion (see Newsletter #107) about revising the BIP173 rules for bech32 addresses in order to prevent the bech32 extension bug from affecting users of taproot and future similar upgrades. Russell proposed using a backwards-incompatible format based on a revised bech32 encoding scheme previously described by Pieter Wuille. This would eliminate the bug but also require wallets to upgrade in order to be able to pay taproot users.

    A previously proposed alternative would be a backwards-compatible restriction on bech32 address lengths. This only directly provides safety to taproot users receiving payments from spenders who upgraded their wallets to enforce the new length restrictions. In the discussion, it was proposed that broader safety could be provided by also enforcing length restrictions at either the consensus layer or the transaction relay policy layer.

    Russell concluded his post by noting that “the sooner a decision is reached on this, the sooner we can begin upgrading software for a taproot world.” Feedback would be especially appreciated from authors of wallets and bitcoin-sending services as they will be asked to implement whatever change is decided upon.

  • ● Updated witness asymmetric payment channel proposal: Lloyd Fournier posted to a thread from several weeks ago about witness asymmetric payment channels (see Newsletter #113). The idea behind this proposal is to change how LN users get the evidence they need to prove their channel counterparty cheated. Currently the evidence is placed in separate transaction for each channel participant; Fournier proposes placing the evidence in separate signatures (“witnesses”) for each participant by using signature adaptors. Advantages of this approach are that it provides a protocol that should be easier to integrate with hoped-for improvements to Bitcoin (e.g. schnorr signatures with and without MuSig aggregation) and hoped-for improvements to LN (e.g. a switch from HTLCs to PTLCs). The approach may also be conceptually simpler, which could help attract more security review of LN’s basic operations.

    This week, Fournier linked to an updated version of his proposed protocol. The main difference from the original version is that a party who broadcasts a revoked signature reveals the primary private key they use in the channel’s multisig spends. The other party to the channel can use that key combined with their own key to immediately claim all funds in the channel. Along with another change, this should allow storing an entire channel’s penalty data in a small number of bytes.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

BIP-325: Signet is a PR (#18267) by Kalle Alm that implements a new kind of Bitcoin test network. The PR has since been merged (see Newsletter #117), and the upcoming v0.21 release will support signet.

The review club discussion covered general concepts before diving into the deeper technical aspects. Participants with good answers were rewarded with signet coins. Here is a mini-quiz on general signet concepts:

  • What is signet?

    Signet is defined by BIP325 and is a mechanism to build stable, centralized, and custom proof-of-work networks. It’s also the name of a specific global testnet. ➚

  • Is signet intended to replace existing Bitcoin testing networks like testnet or regtest?

    They are complementary. Signet was conceived as a centralized, stable improvement for cases where the current testnet isn’t ideal. 

  • What problems do we have with the current testnet?

    Testnet is unreliable due to disruptive reorgs, highly variable block production, and a skewed incentive model: testnet coins don’t have value, but testnet mining is not free and the difficulty fluctuates. ➚

  • What is the difference between signet and regtest (Bitcoin Core’s regression test framework)?

    Regtest is a sandboxed environment with entirely manual network topology and block generation that is suitable for local testing, but its permissionless nature that allows anyone to mine means that regtest cannot be used publicly with third-party peers in a stable fashion. Signet is an actual network with public nodes, suitable for testing network effects like finding peers, transaction selection, and transaction and block propagation. 

  • What is the default signet challenge script in the PR?

    Multisig 1-of-2 addresses. This may be modified with the -signetchallenge configuration option. ➚

  • In the CreateGenesisBlock() method, which parameter determines the difficulty?

    Difficulty is set by the nBits parameter, a custom compressed representation of the proof of work target whose human-readable representation is difficulty. ➚

  • Is the difficulty for the signet genesis block lower than the difficulty for the mainnet genesis block?

    Yes, signet has a higher default nBits and therefore a lower difficulty target: mainnet 1d00ffff, signet 1e0377ae. However, it’s just a minimum target; the signer may set it to be higher. ➚

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.

  • ● HWI 1.2.0 is a new release that adds support for a new hardware device (the BitBox02) and contains multiple bug fixes.

  • ● Eclair 0.4.2 is a new release that gives more capabilities to Eclair plugins, adds experimental support for anchor outputs, and lets users send and receive spontaneous payments. Also included are several API changes and 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 #19954 completes the BIP155 implementation, also referred to as addr v2. As previously covered in Newsletter #110, this upgrade supports Tor v3 and makes it possible to add support for I2P and other networks with longer endpoint addresses that do not fit in the 16 bytes/128 bits of Bitcoin’s current addr message. Tor v2 was deprecated in September 2020 and will be obsolete in July 2021.

  • ● Eclair #1537 extends the sendtoroute API call to allow specifying a list of channel IDs for the payment with the --shortChannelIds flag. This finer-grain control over the payment is especially useful when two nodes have more than one channel between them and so listing the node IDs is not specific enough (e.g. when consolidating and rebalancing channels).