This week’s newsletter announces the newest release of LND, requests testing of release candidates for Bitcoin Core and C-Lightning, relays an update on the taproot proposal, describes a proposed increase in the default LN routing fees, and summarizes three talks from the recent Cryptoeconomic Systems Summit. Also included is our regular section on notable changes to popular Bitcoin infrastructure projects.

Action items

• ● Upgrade LND to version 0.8.0-beta: LND’s newest release uses a more extensible packet format, improves backup safety, increases watchtower client integration, makes routing more likely to succeed, and includes many other new features and bug fixes.

• ● Upgrade to Eclair 0.3.2: Eclair’s newest release improves backups, makes syncing gossip data more bandwidth efficient (especially for non-routing nodes, such as nodes on mobile devices), and includes many other new features and bug fixes.

• ● Review RCs: two popular Bitcoin infrastructure projects have issued Release Candidates (RCs) for the next version of their software. We encourage developers and experienced users to help test these RCs so that any problems can be found and fixed before their general public release:

  • ● Bitcoin Core 0.19.0rc1
  • ● C-Lightning 0.7.3-rc2

News

• ● Taproot update: Pieter Wuille sent an email to the Bitcoin-Dev mailing list with a summary of recent changes to the proposal. Changes include:

  • 32-byte public keys instead of 33-byte keys (mentioned in Newsletter #59).

  • No support for P2SH-wrapped taproot addresses (mentioned in #65).

  • 32-bit txin positions in the signature hash data rather than 16-bit indexes.

  • Tagged hashes are now used in bip-schnorr. They were previously only used in bip-taproot and bip-tapscript.

  • The 10,000-byte and 201 non-push opcode limits have been dropped from bip-tapscript (mentioned in #65).

  • The maximum depth of the merkle tree has been increased from 32 levels to 128 levels.

  Wuille’s email and the updated BIPs provide rationales for each of these decisions as well as links to previous discussions about them.

• ● Proposed default LN fee increase: Rusty Russell proposed an increase in the default in-channel fees to be used by nodes, going from 1,000 millisatoshis (msat) plus 1 part-per-million (ppm) to 5,000 msat plus 500 ppm. He notes that the current defaults don’t provide much room for allowing users to lower fees and the popularity of nodes currently charging higher fees indicates many users are currently not sensitive to fees. His email provides a chart estimating the old and new costs of transferring various amounts of money in USD terms at $10,000 USD/BTC:

  Amount	Before	After
  0.1c	0.0100001c	0.05005c
  1c	0.010001c	0.0505c
  10c	0.01001c	0.055c
  $1	0.0101c	0.1c
  $10	0.011c	0.55c
  $100	0.02c	5.05c
  $1000	0.11c	50.05c

  Fellow C-Lightning maintainer ZmnSCPxj and Eclair maintainer Pierre-Marie Padiou indicated support for the proposal. LND maintainer Olaoluwa Osuntokun believed the reasoning behind the proposal had several flaws and advocated instead to “educate prospective routing node operators on best practices, provide analysis tools […], and leave it up to the market participants to converge on steady state economically rational fees.” As of this writing, discussion about the topic remains ongoing.

• ● Conference summary: Cryptoeconomic Systems Summit: this conference held last weekend on the MIT campus covered a variety of topics about ensuring cryptocurrencies are both useful and secure. Videos are now available courtesy of the DCI’s YouTube channel and transcripts for several of the talks have been provided by Bryan Bishop and others. Out of the subset of talks that were transcribed, we thought the following three topics might be of particular technical interest to the readers of this newsletter:

  • ● Everything is broken by Cory Fields (transcript, video), a talk that describes how Bitcoin is at risk not just from its own software bugs but also from the bugs introduced into the libraries, operating systems, and even hardware that it depends upon. Fields then looks back in time when a large number of certain classes of bugs were affecting another major open source project, Mozilla Firefox, and at that project’s foresight for attempting to categorically eliminate some of those problems by starting the development ten years ago of a new programming language (Rust) that could provide stronger automatic guarantees. Finally, Fields asks the audience to contemplate initiates we could start now that would, over the course of the next ten years, help categorically eliminate some types of problems that Bitcoin users and developers currently need to worry about.

  • ● Near misses: What could have gone wrong by Ethan Heilman (transcript, video), a survey of five problems in Bitcoin’s past that could’ve lead to significant losses in user funds or user confidence. Following the survey, Heilman asks the audience to consider what a worst-case software failure in Bitcoin would look like today, or what would’ve happened if one of the previously-encountered problems had been exploited by an attacker to its worst extent. We recommend attempting this exercise: it can obviously emphasize the dangers that remain in Bitcoin—but it may also help highlight the ways in which Bitcoin is more secure than you initially expect.

  • ● The quest for practical threshold Schnorr signatures by Tim Ruffing (transcript, video), a description of the research performed by the speaker and his colleagues into trying to find a secure, compact, practical, and flexible scheme for threshold-based schnorr signatures. Ruffing first describes the difference between generalized threshold signatures and the specific case of multi-signatures. A threshold signature allows a subset of a group to sign (e.g. k-of-n); multi-signatures are a special case of threshold signatures where the whole group signs (n-of-n). Protocols like MuSig (see Newsletter #35) and MSDL provide multi-signature signing compatible with bip-schnorr, but threshold signatures for a subset of signers have not been solved to the same degree.

    As an example of outstanding problems, Ruffing notes that the security proofs for existing Discrete Log Problem (DLP) based threshold signature schemes assume that the majority of potential signers are honest. So a 2-of-3 arrangement is secure because the worst case you planned for would be one dishonest signer (which is less than a majority). In a 6-of-9 arrangement, you want the scheme to be secure against up to five dishonest signers—but five signers would constitute a majority and undermine the expectations in the security proof.

    Another potential problem is that previously-described protocols expect each participant has a secure and reliable method of communicating with all other participants. Someone who can eavesdrop or manipulate the communication may be able to recover the ultimate private key that would allow them to sign any spend they want. This seems solvable, but the proposed solution doesn’t have a security proof yet.

    Ruffing concludes with a wishlist for what he’d like to see in a schnorr-based threshold signature scheme, including several stretch goals.

Notable code and documentation changes

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

• ● Bitcoin Core #15437 removes support for BIP61 P2P protocol reject messages. These were previously announced as deprecated in Bitcoin Core 0.18.0 (May 2019) and will be disabled by default in the upcoming 0.19.0 release. This change to remove them is part of the master development branch and is expected to be released in 0.20.0, more than a year after the initial announcement of deprecation covered in Newsletter #13 and followed up in Newsletters #37 and #38.

• ● Bitcoin Core #17056 adds a sortedmulti output script descriptor that sorts the pubkeys provided to it using the lexicographic order described in BIP67. This makes it possible to import xpub-based descriptors for wallets that require using BIP67, such as the Coldcard hardware wallet in multisig mode.

• ● LND #3561 adds a new channel validation package that unifies the logic used to verify channels both when channel-open data is received from a third-party peer or when it’s received from a first-party data source like the local Bitcoin node. This helps address an underlying cause in LND of the recent vulnerabilities that affected multiple LN implementations (see Newsletter #66).

• ● C-Lightning #3129 adds a new startup option --encrypted-hsm that will prompt the user to provide a passphrase that will be used to either encrypt the HD wallet’s seed (if it’s currently unencrypted) or decrypt it (if it’s encrypted).