This week’s newsletter includes our regular sections with the best questions and answers of the past month from the Bitcoin Stack Exchange, our latest column about preparing for taproot, a list of new software releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.


No significant news this week.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Preparing for taproot #6: learn taproot by using it

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Almost two years ago, James Chiang and Elichai Turkel produced an open source repository of Jupyter notebooks for a series of Optech workshops to train developers on taproot technology. Workshops held in San Francisco, New York City, and London received positive reviews, but travel restrictions prevented subsequent in-person workshops.

Since the publication of the Jupyter notebooks, taproot underwent several changes. However, taproot support was also merged into Bitcoin Core, allowing the notebooks to drop their dependency on a custom branch of Bitcoin Core. Developer Elle Mouton has kindly updated the notebooks for all those changes, making them again a great way to quickly build hands-on experience working with taproot’s algorithms and data types.

The notebooks are divided into four sections:

  • Section 0 contains a notebook that helps you set up your environment, covers the basics of elliptic curve cryptography, and teaches you about the tagged hashes used throughout BIPs 340, 341, and 342.

  • Section 1 walks you through creating schnorr signatures. Once you’ve mastered them, you learn how to create multisignatures with the MuSig protocol.

  • Section 2 gives you experience with every aspect of taproot. It starts with a review of the principles of segwit v0 transactions and then helps you create and send segwit v1 (taproot) transactions. Applying the knowledge from section 1, you then create and spend a taproot output using MuSig. The concept of key tweaking is introduced and you learn how taproot allows you to use its public key to commit to data. Now that you can create commitments, you learn about tapscripts—how they differ from legacy and segwit v0 script, and how to commit to a tree of tapscripts. Finally, a short notebook introduces huffman encoding for creating optimal script trees.

  • Section 3 provides an optional exercise in creating a taproot output that changes which signatures are required the longer the output goes unspent—allowing the output to be efficiently spent under normal circumstances but also providing for a robust backup in case of problems.

The notebooks include numerous programming exercises that are relatively easy but which will ensure that you actually learned the material presented. The author of this column, who is no great coder, was able to complete the notebooks in six hours and only regretted that he had not taken the time to learn from them earlier.

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.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #22387 limits the average number of announced addresses it’ll process from each peer to one per 10 seconds. Any addresses in excess of the limit will be ignored. It’s possible to whitelist peers to allow them to exceed this limit, and any address announcements the node explicitly requests from its peers are also excluded from the limit. The limit is estimated to be about four times higher than the current rate at which a Bitcoin Core node announces addresses.

  • C-Lightning #4669 fixes several bugs in its LN offers parsing and validation logic. It also returns a previously created offer that hasn’t yet expired if the user attempts to create a new offer with the same parameters; this may be especially useful since offers aren’t created by default with an expiration date.

  • C-Lightning #4639 adds experimental support for the liquidity advertisements proposed in BOLTs #878. This allows a node to use the LN gossip protocol to advertise its willingness to lease out its funds for a period of time, giving other nodes the ability to buy incoming capacity that allows them to receive instant payments. A node that sees the advertisement can simultaneously pay for and receive the incoming capacity using a dual funded channel open. Although there’s no way to enforce that the advertising node actually routes payments, the proposal does incorporate an earlier proposal also planned to be used in Lightning Pool that prevents the advertiser from using their money for other purposes until the agreed upon lease period has concluded, so refusing to route would only deny them the opportunity to earn routing fees. The following table compares liquidity advertisements to the similar Lightning Pool marketplace described in Newsletter #123.

    Lightning Pool Liquidity advertisements
    Control over listings Centralized: allows curation to ensure high-quality listings, but also allows censoring listings Decentralized: listings can’t be censored, but users need to do their own research before buying a lease
    Licensing Open source client, proprietary server, open protocol All open source
    Price information Actual prices paid are public information via public auction results Advertised prices are public information via public gossip network
    Third-party purchased liquidity (“sidecar channels”) Yes, Alice can pay Bob to fund a channel to Carol Maybe.
  • BIPs #1072 merges the informational BIP48 titled “Multi-Script Hierarchy for Multi-Sig Wallets”. The document describes a widely deployed derivation standard for wallets participating in multisignature setups based on the m/48' prefix, and elaborates on the six derivation levels used by the scheme.

  • BIPs #1139 adds BIP371 with a specification of new fields for using PSBTs (both version 0 and version 2) with taproot transactions. See Newsletter #155 for previous discussion.

Acknowledgments and edits

Our original description of Bitcoin Core PR #22387 claimed the new rate limit was about 40x higher than the measured rate. The correct figure is about 4x. We thank Amiti Uttarwar for reporting this error.