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.
None this week.
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.
● Esplora C-Lightning plugin released:
Luca Vaccaro has released an initial version of
an Esplora C-Lightning plugin that fetches Bitcoin data from the block
explorer instead of a local
Notable code and documentation changes
● 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
● 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
whitelistedfield returned from the
getpeerinfoRPC, which previously had its scope expanded by more granular permissioning
(see Newsletter #60).
whitelistedis 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.
● 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.