This week’s newsletter describes a proposal for timeout tree channel factories and summarizes a draft BIP for proofs of discrete log equivalence to be used when generating silent payments. Also included are our regular sections with announcements of new software releases and descriptions of notable changes made to popular Bitcoin infrastructure software.

News

• ● Timeout tree channel factories: ZmnSCPxj posted to Delving Bitcoin and discussed with Optech contributors a proposal for a new multi-layer channel factory design named SuperScalar. A goal of the design is to provide a construction that could be easily implemented by a single vendor without waiting for large protocol changes that require widespread agreement. For example, a Lightning service provider (LSP) that distributes wallet software could allow its users to more cheaply open channels and receive inbound liquidity without sacrificing LN’s trustlessness.

  The overall construction is based on a timeout tree, where a funding transaction pays to a tree of pre-defined child transactions that are ultimately spent offchain into many separate payment channels. After a configurable timeout (e.g. a month), some of the parties involved in the timeout tree forfeit any of their funds remaining in the tree—this incentivizes them to withdraw or find alternative security for those funds before the expiry, which can encourage the use of cheap offchain mechanisms rather than publishing parts of the tree onchain. In previously described timeout trees (see Newsletter #270), user funds that timed out became the property of a service provider, but ZmnSCPxj reverses this and makes a service provider’s timed-out funds become the property of the users—this places the burden of getting transactions confirmed on the service provider rather than end users.

  The timeout trees used require each involved party to contribute a signature. This avoids the need for consensus changes but limits the practical maximum number of users in a factory due to the well-known multi-signer coordination problem.

  Most of the leaves of the timeout tree are offchain funding transactions for the common type of channel used today (LN-Penalty), allowing some reuse of existing code for managing LN channels. The counterparties in each channel are an end user and the Lightning service provider (LSP) who created the timeout tree. Some of the leaves of the tree may also be exclusively controlled by the LSP for the purpose of rebalancing funds.

  Between the root and the leaves are duplex micropayment channels. Unlike LN-Penalty channels, duplex channels allow more than two parties to safely share funds; however, they also only allow a relatively small number of state updates compared to LN-Penalty’s effectively unlimited number of updates. The intermediate duplex channels are used to allow rebalances involving the LSP and two end users; these rebalances could securely complete at offchain speeds, allowing a user to receive an incoming payment almost instantly even if they didn’t previously have enough capacity in their channel to accept it.

  In a later post, ZmnSCPxj described replacing part of a duplex channel with a Spillman-style (simplex) micropayment channel. This would be more efficient onchain in the case of a cooperative close, although it would be less efficient onchain in the case of a unilateral close.

  The proposal received a moderate amount of discussion. The author said that one of the weaknesses of the proposal is its technical complexity due to the use of multiple different channel types plus the inherent challenge in any channel factory design of managing additional offchain state. However, the proposal has the advantage of being something that could be implemented by a single team and made interoperable with the standard LN without requiring many changes to the LN protocol.

• ● Draft BIP for DLEQ proofs: Andrew Toth posted to the Bitcoin-Dev mailing list a draft BIP and a link to an implementation for generating and verifying proofs of discrete log equality (DLEQ) for the elliptic curve used by Bitcoin (secp256k1). A DLEQ allows a party to prove that they know a private key without revealing anything about it, such as its corresponding public key. This has been used in the past to allow someone to prove that they own a UTXO without revealing which UTXO (see Newsletters #83 and #131).

  The current BIP is motivated by support for silent payments created using multiple independent signers. If one signer lies or is faulty, it’s possible for funds to be lost. A DLEQ allows each signer to prove that they signed correctly without revealing their private keys to the other signers. See Newsletter #308 for previous discussion.

  The proposal received a reply from Adam Gibson, who previously implemented a DLEQ proof system for the JoinMarket coinjoin implementation. He suggested several changes that would make the BIP’s version of DLEQ more flexible for other uses beyond silent payments.

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.

• ● BTCPay Server 2.0.0 is the latest release of this self-hosted payment processor. Its new features include “improved localization, sidebar navigation, improved onboarding flow, improved branding options, support for pluginable rate providers” and more. The upgrade includes some breaking changes and database migrations; it is recommended to read the announcement before upgrading.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

• ● Bitcoin Core #31130 removes Universal Plug and Play (UPnP) Internet Gateway Device (IGD) support by dropping the miniupnp dependency, which had a history of security vulnerabilities and was already disabled by default (see Newsletter #310). It is now replaced by a Port Control Protocol (PCP) implementation with a Network Address Translation-Port Mapping Protocol (NAT-PMP) fallback (see Newsletter #323), which allows nodes to be reachable without manual configuration, but removes the security risks associated with the miniupnp dependency.

• ● LDK #3007 adds two new variants BlindedForward and BlindedReceive to the OutboundTrampolinePayload enum to introduce support for blinded paths in trampoline routing as a basis for implementing the BOLT12 offers protocol.

• ● BIPs #1676 updates the status of BIP85 to final, as it’s widely deployed and past the point of introducing breaking changes. This was proposed after a recent breaking change was merged and later reverted (see Newsletter #324).