This week’s newsletter provides an overview of the new MuSig2 paper, summarizes additional discussion about upfront fees in LN, and describes a proposal to simplify management of LN payments. Also included are our regular sections with summaries of notable improvements to clients and services, announcements of releases and release candidates, and changes to popular Bitcoin infrastructure software.

Action items

None this week.

News

  • ● MuSig2 paper published: Jonas Nick, Tim Ruffing, and Yannick Seurin published the MuSig2 paper describing a new variant of the MuSig signature scheme with a two round signing protocol.

    MuSig is a signature scheme that allows multiple signers to create an aggregate public key derived from their individual private keys, and then collaborate to create a single valid signature for that public key. The aggregate public key and signature are indistinguishable from any other schnorr public key and signature.

    The original version of MuSig required a three round signing protocol: first, the co-signers exchange commitments to nonce values, then they exchange the nonce values themselves, and finally, they exchange the partial signatures. Without this three round protocol, an attacker could interact with an honest signer in multiple concurrent signing sessions to obtain a signature on a message that the honest signer did not want to sign.

    Using deterministic nonces, which is very common practice in single-signer schemes, is unsafe for multi-signer schemes, as described in the original MuSig blog post. Precomputing the nonces in advance and exchanging them at key setup time is also unsafe, as described in a blog post by Jonas Nick. It is, however, safe to precompute the nonces and exchange the nonce commitments early, moving one of the three rounds to the key setup stage.

    Removing the requirement to exchange nonce commitments has been an active area of research, and last month the MuSig-DN paper was published, demonstrating how nonce commitment exchange could be removed by generating the nonce deterministically from the signers’ public keys and the message, and providing a non-interactive zero-knowledge proof that the nonce was generated deterministically along with the nonce. This removed the requirement of exchanging nonce commitments at the cost of a more expensive signing operation.

    The new MuSig2 scheme achieves a simple two round signing protocol without the need for a zero-knowledge proof. What’s more, the first round (nonce exchange) can be done at key setup time, allowing two different variants:

    • interactive setup (key setup and nonce exchange) and non-interactive signing

    • non-interactive setup (address computed from public keys) and interactive signing (nonce exchange followed partial signature exchange)

    The non-interactive signing variant could be particularly useful for cold storage schemes and offline signers, and also for offchain contract protocols such as LN, where the nonces could be exchanged at channel setup time.

  • ● More LN upfront fees discussion: after last week’s discussion, Joost Jager asked developers on the Lightning-Dev mailing list to again consider how to charge fees for attempting to route payments—fees that would have to be paid even if the attempt failed. This could help mitigate both jamming attacks that can prevent nodes from earning routing fees and probing attacks that allow third parties to track other people’s channel balances. Unfortunately, developers have not yet found a satisfactory way to trustlessly charge upfront fees, so recent discussion has focused on trust-based methods that may involve such small amounts of fee that users will find them acceptable.

    Unfortunately, none of the methods discussed this week seemed to meet with widespread acceptance. Several developers expressed concern that methods could be abused to penalize small honest nodes. Other developers noted that the alternative to upfront payment is an increased reliance on reputation—which likely disproportionately benefits larger nodes. We’re sure developers will continue working on this important issue and we’ll report on any notable progress in future newsletters.

  • ● Simplified HTLC negotiation: Rusty Russell posted to the Lightning-Dev mailing list about simplifying how payments are made and resolved in LN channels. Currently, both sides of a channel can each propose relaying or settling a payment, which requires creating or removing an HTLC from the offchain commitment transaction. Sometimes both sides propose a change at the same time and so there are conflicting commitment transactions. These potential conflicts may get more complicated if dynamic changes to the commitment transaction format and settings are allowed (see Newsletter #108). One proposal to eliminate that complication is to only allow dynamic changes when all HTLCs have been resolved and the channel is quiet—that improves safety but is more restrictive than desired.

    Russell’s proposal this week was to allow only one party in a channel to propose HTLC changes. This eliminates the risk of conflicting proposals but it increases the average network communication overhead by half a round trip (assuming each party proposes an equal number of HTLC changes). Responsibility for proposing changes can be transferred from one party to the other as needed, allowing each party to propose channel updates at different times.

    As of this writing, the proposal received only a small amount of discussion from other LN implementation maintainers, so its future remains uncertain.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

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 #19953 implements schnorr signature verification (BIP340), taproot verification (BIP341), and tapscript verification (BIP342). The new soft fork rules are currently only used in the private test mode (“regtest”); they are not enforced in mainnet, testnet, or the default signet. The plan is to release the code in Bitcoin Core 0.21.0 and then prepare a subsequent release (e.g. 0.21.1) that can begin enforcing the soft fork’s new rules when an activation signal is detected. The particular activation signal or signals to use are still being discussed in the ##taproot-activation IRC chatroom (logs).

    The code consists of about 700 lines of consensus-related changes (500 excluding comments and whitespace) and 2,100 lines of tests. Over 30 people directly reviewed this PR and its predecessor, and many others participated in developing and reviewing the underlying research, the BIPs, the related code in libsecp256k1, and other parts of the system. There is still more work to do, but getting the code properly reviewed was arguably the most critical step—so we extend our most grateful appreciation to everyone who helped achieve this milestone.

  • ● Bitcoin Core #19988 redesigns the logic Bitcoin Core uses to request transactions from its peers. The major changes described by the PR description include: Bitcoin Core will now more strongly prefer requesting transactions from outbound peers—peers where the connection was opened by the local node; Bitcoin Core will now request an unlimited number of transactions from a peer rather than stopping at 100 (though slow responders won’t be preferred); and Bitcoin Core won’t keep track of as many pending transaction requests as before, the previous limit being seen as excessive. The change also greatly improves the readability of the code and the ability to test that the transaction request logic is working as expected. This testing may help reduce the chance that a flaw can be exploited against users of time-sensitive transactions (such as in LN and many other contract protocols).

  • ● Bitcoin Core #19077 adds a new SQLite database backend for wallet records. Unlike the existing Berkeley DB database backend, SQLite is designed and tested to be resilient against corruption from crashes and power losses. In the upcoming v0.21 release, legacy wallets will keep using the Berkeley DB backend, whereas the newly introduced descriptor wallets will default to using this new SQLite backend. Work on developing a migration path and tentative timelines to deprecate and remove legacy wallets and the Berkeley DB wallet backend are being discussed in Bitcoin Core #20160.

  • ● Bitcoin Core #19770 deprecates the whitelisted field returned from the getpeerinfo RPC, which previously had its scope expanded by more granular permissioning (see Newsletter #60). whitelisted is set to be deprecated in v0.21 and is planned to be removed in v0.22.

  • ● Bitcoin Core #17428 writes a file at shutdown with the network addresses of the node’s two outbound block-relay-only peers. The next time the node starts, it reads this file and attempts to reconnect to those same two peers. This prevents an attacker from using node restarts to trigger a complete change in peers, which would be something they could use as part of an eclipse attack that could potentially trick the node into accepting invalid bitcoins.

  • ● LND #4688 adds a new --duration parameter that can be used to indicate how long until LND stops making additional attempts to send a payment. The default remains 60 seconds.

  • ● Libsecp256k1 #830 enables GLV endomorphism, which allows verifying signatures with up to 33% fewer operations (see a comment to the PR with actual performance test results). The PR also removes the slower code for operating without endomorphism as there’s no reason to use it now that the patent on the GLV technique has expired (see Newsletter #117). This PR also implements an independent memcmp (memory compare) function to avoid the problems with GCC’s internal version of that function (see another section in Newsletter #117). These changes were subsequently pulled into Bitcoin Core.