This week’s newsletter announces the release of Eclair 0.3.3, requests help testing a Bitcoin Core maintenance release, links to a new tool for experimenting with taproot and tapscript, summarizes discussion about safely generating schnorr signatures with precomputed public keys, and describes a proposal for interactive construction of LN funding transactions. Also included is our regular section about notable changes to popular Bitcoin infrastructure projects.

Action items

• Upgrade to Eclair 0.3.3: this new release includes support for multipath payments, deterministic builds for eclair-core (see the PR description below), experimental support for trampoline payments, and various minor improvements and bug fixes.

• Help test Bitcoin Core 0.19.1rc1: this upcoming maintenance release includes several bug fixes. Experienced users are encouraged to help test for any regressions or other unexpected behavior.

News

• Taproot and tapscript experimentation tool: Karl-Johan Alm posted to the Bitcoin-Dev list about an experimental branch of his btcdeb tool that supports creating and executing taproot and tapscript outputs using a command line tool named tap. For more information, see his detailed tutorial.

• Alternative x-only pubkey tiebreaker: As the above issue was discussed, Pieter Wuille proposed slightly speeding up derivation of the public key from the private key by changing the algorithm used to choose which variant of a public key to use when only the key’s x-coordinate is known (see previous discussion about 32-byte public keys in Newsletter #59). Because this is a significant change, the proposal also changes the tagged hash used to generate part of the signature.

This change hasn’t yet been announced to the mailing list, probably because developers are evaluating what other changes they might want to make at the same time in order to address the safety of providing precomputed public keys to the signature function.

• Interactive construction of LN funding transactions: in the current LN protocol, the onchain transaction that opens a new channel is created entirely by a single party. This has the advantage of being simple but the disadvantage that payments in the channel can initially only flow in one direction—from the party funding the channel to the other party. Lisa Neigut has been working on a dual-funding protocol where both parties can contribute funds to opening the channel, which may be especially useful for creating channels where payments can initially flow in both directions, improving the liquidity of the network.

However, the dual-funding proposal is complicated, so Neigut started a thread on the Lightning-Dev mailing list this week about splitting out one aspect of the new protocol: the ability for LN nodes to collaboratively construct a funding transaction. This has previously been described as improving security (see Newsletter #78) and Neigut notes that the collaboration mechanism could also help support related work on batched closings (mutually closing multiple channels at the same time) and splicing (moving funds into or out of a channel without affecting the spendability of other funds already in the channel). Replies to Neigut’s proposal included:

• A suggestion to set the nLockTime field’s value to a recent or upcoming block height in order to implement anti-fee sniping which helps disincentivize block chain reorganizations and which will help funding transactions blend in with other wallets that have already implement anti-fee sniping (including LND’s sweeping mode, see Newsletter #18).

• More broadly, a suggestion to implement a common set of values for free parameters in a transaction (such as nVersion, nSequence, nLockTime, input ordering, and output ordering) with other collaborative transaction creation systems (such as coinjoin software). This would avoid producing any obvious indicators that an LN funding transaction is being created (especially if taproot is adopted, as mutual LN close transactions can look like single-sig spends).

• A suggestion to communicate proposed transaction details using BIP174 Partially-Signed Bitcoin Transactions (PSBTs). Though Neigut replied that she thinks PSBT is “a bit overweight for transaction collaboration between two peers.”

• A sub-discussion about how to avoid probing where Mallory starts the process of opening a dual-funded channel with Bob but then aborts after she receives the identity of one of Bob’s UTXOs. By aborting before the funding transaction is complete, Mallory can costlessly learn which network identity (node) owns which UTXOs.

One proposal to fix this would require the person proposing to open the channel (e.g. Mallory) to provide their UTXO(s) in a ready-to-spend state so that probing would cost money (e.g. transaction fees). A downside of this approach is that the construction proposed would be easily identifiable by block chain analysis, making it easy to determine when a dual-funded channel was opened.

Another proposal was to use PoDLE, which was originally developed for JoinMarket based on a suggestion by Gregory Maxwell. This protocol allows an initiating user such as Mallory to commit to a UTXO in a way that prevents anyone from identifying that UTXO. The participating user, such as Bob, publishes the commitment across the network (e.g. the JoinMarket network) so that nobody else will start a session with Mallory while she’s using that particular UTXO. Then Bob asks Mallory to identify her UTXO and, if it’s a valid UTXO that matches her commitment, Bob discloses his UTXO to Mallory so that they can proceed with the protocol (e.g. a coinjoin). If Mallory aborts the protocol before completion, the commitment previously published across the network prevents her from being able to start a new session with any other user and so learn their UTXO. Mallory’s only option is to spend her coins from herself to herself in order to generate a new UTXO—a process that costs her money and so limits her ability to spy on users. (Note, though, that PoDLE as implemented in JoinMarket allows Mallory up to three retries by default so honest users aren’t penalized for occasional accidental failures, such as a loss of network connectivity.) The idea is to adapt this protocol for LN in order to prevent attackers from learning which available UTXOs are controlled by LN users.

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 #16702 allows Bitcoin Core to choose peers based on their Autonomous System Number (ASN) instead of IP address prefix. Differentiating peers based on ASN may make it more difficult for an adversary to successfully execute certain eclipse attacks (such as the Erebus attack). This new feature is disabled by default—to use ASN-based peering, the user must provide an ASN table file, which can be generated using asmap. Future releases may include an ASN table file generated and reviewed by the Bitcoin Core developers. See our summary of an IRC discussion in #bitcoin-core-dev for more details of this approach.

• C-Lightning #3315 adds a dev-sendcustommsg RPC and custommsg plugin hook that allows sending custom network protocol messages from a node to any of its peers. The feature can only be used for messages not already handled internally by the C-Lightning daemon, and also only for messages with an odd-numbered type (following the it’s ok to be odd rule). Note: this feature should not be confused with applications like WhatSat that send chat messages across a network route inside onion-encrypted payments; this merged PR only allows sending protocol messages to a node’s direct peers.