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.

News

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.

• ● What is this unusual transaction in the Bitcoin blockchain? Murch describes an output labeled “UNKNOWN” in a block explorer. The output is a segwit version 1 output with a contrived pubkey. As pointed out by 0xb10c, the 2019 transaction creating this output was for the purpose of testing segwit v1 support for Optech’s Compatibility Matrix. As warned previously (see Newsletter #158), P2TR outputs are anyone-can-spend before the activation of taproot, as 0xb10c demonstrated and elaborates in a blog post.

• ● What are miners signalling for when the block header nversion field ends in 4 i.e. 0x3fffe004? While researching the overt form of ASICBoost, user shikaridota wonders why recently mined blocks have bit 2 being set in the nVersion field. Andrew Chow points out that taproot used bit 2 to signal for activation as specified in BIP341’s deployment section.

• ● Where can I find Bitcoin’s alpha version with 15 minute block time intervals? Andrew Chow points to a selection of source code, allegedly from Satoshi, which contains 15 minute block times as well as 30 day retargeting periods.

• ● What’s the purpose of using Guix within Gitian? Doesn’t that reintroduce dependencies and security concerns? Andrew Chow and fanquake describe the benefits of reproducible builds, including using Gitian builds and bootstrappable builds using Guix and comment on using them together.

• ● Why are there several round number transactions with no change? Shm asks about a series of related transactions that have many inputs with a single round-number output with no change. Murch answers by describing change avoidance in the context of a wallet with a large number of UTXOs. Change avoidance allows for smaller transactions, reduced future fees, UTXO consolidation, and privacy improvements.

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.

• ● Rust Bitcoin 0.27.0 (bech32m support) is a new release. Most notably, it adds support for handling bech32m addresses.

• ● C-Lightning 0.10.1rc1 is a release candidate for an upgrade that contains a number of new features, several bug fixes, and a few updates to developing protocols (including dual funding and offers).

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.