This special edition of the Optech Newsletter summarizes notable developments in Bitcoin during all of 2021. It’s the sequel to our summaries from 2018, 2019, and 2020.

Contents

January

After years of discussion, January saw the first release of a Bitcoin Core version supporting signets, following prior support by C-Lightning and followed by support in LND. Signets are test networks anyone can use to simulate Bitcoin’s main network (mainnet), either as it exists today or how it might exist with certain changes (such as the activation of a soft fork consensus change). Most software implementing signets also supports a default signet that provides a particularly convenient means for software developed by different teams to be tested in a safe environment that comes as close as possible to the environment they’ll experience when real money is at stake. Also discussed this year was adding deliberate block chain reorganizations to Bitcoin Core’s default signet network to help developers test their software against that class of problems.

A draft BIP for bech32m was also announced in January. Bech32m addresses are a slight modification of bech32 addresses that make them safe for use with taproot and future protocol extensions. Later in the year, a Bitcoin Wiki page was updated to track adoption of bech32m addresses by wallets and services.

Another first release of a new protocol was onion messages and the offers protocol. Onion messages allow an LN node to send a message to another node in a way that minimizes overhead compared to HTLC-based message sending. Offers use onion messages to allow one node to offer to pay another node, allowing the receiving node to return a detailed invoice and other necessary information. Onion messages and offers would continue as draft specifications for the remainder of the year, but they would receive additional development, including a proposal to use them to reduce the impact of stuck payments.

February

Contributors to Bitcoin advanced the state of research into an improved signature creation and verification algorithm, and then used their research to produce a variation with additional improvements. When implemented in libsecp256k1 (1, 2) and later in Bitcoin Core, this reduced the amount of time it takes to verify signatures by about 10%—a significant improvement when verifying the roughly billion signatures in Bitcoin’s block chain. Several cryptographers worked on ensuring the change was mathematically sound and safe to use. The change also provides a significant boost to the speed of securely creating signatures on low-powered hardware signing devices.

Channel jamming attacks, a known problem for LN since 2015, received continued discussion throughout the year, with a variety of possible solutions discussed. Unfortunately no widely accepted solution was found and the problem remained unmitigated by year’s end.

Illustration of jamming attacks

March

Significant discussion in March was devoted to analyzing the risk of quantum computer attacks on Bitcoin, particularly for the case where taproot activated and became widely used. One of Bitcoin’s original features, public key hashing—likely added to make Bitcoin addresses shorter—has also likely made it harder to steal funds from a limited number of users if there’s a sudden major advance in quantum computing. Taproot doesn’t provide this feature and at least one developer was concerned that it created an unreasonable risk. A large number of counterarguments were presented and community support for taproot seemed to be unchanged.

2021 summary
Taproot activation

By the end of 2020, an implementation of the taproot soft fork containing support for schnorr signatures and tapscript had been merged into Bitcoin Core. This largely completed the work of protocol developers; it was now up to the community to activate taproot if they wished, and for wallet developers to begin adding support for it and related technology like bech32m addresses.

  • ● January began with the release of Bitcoin Core 0.21.0, which was the first release to contain support for signets, including the default signet where taproot had been activated—giving users and developers an easy place to start testing.

  • ● February saw the first of many scheduled meetings in the ##taproot-activation IRC channel, which would become the primary hub for discussion among developers, users, and miners for how to activate taproot.

  • ● March began with many discussion participants tentatively agreeing to try a particular activation approach named speedy trial, which was designed to gather rapid feedback from miners but also still give users sufficient time to upgrade their software for taproot enforcement. Speedy trial would go on to become the actual mechanism used to activate taproot.

    While activation discussions were underway, there was a final discussion about one of its design decisions, using bare public keys, which was argued might put user funds at increased risk of being stolen by future quantum computers. Many developers argued that the concerns were unwarranted or, at least, overblown.

    Also in March, Bitcoin Core merged support for BIP350, allowing it to pay to bech32m addresses. This slight variation on the bech32 addresses that are used for payments to original segwit version addresses fixes a bug which could’ve caused taproot users to lose money in some very rare cases. (Original segwit outputs created from bech32 addresses are safe and unaffected by the bug.)

  • ● April almost saw activation progress derail as protocol developers and some users debated the merits of two slightly different versions of the speedy trial activation mechanism. However, the authors of different implementations of the two different versions came to a compromise that allowed a Bitcoin Core version to be released with an activation mechanism and parameters.

  • ● May was when miners were able to begin signalling their readiness to enforce taproot and a website for tracking signaling progress became popular.

  • ● June saw miners lock-in taproot, committing to enforcing its activation an estimated six months later at block 709,632. This meant it was time for wallet developers and other infrastructure developers to put more attention to adapting their software for taproot, which many of them did. Additionally, a proposal was made that would allow onchain taproot wallets to easily contribute towards the privacy of wallets using various contract protocols like LN and coinswaps. Optech also began its Preparing for Taproot series.

  • ● July met with a Bitcoin Wiki page devoted to tracking support for the bech32m address format needed for wallets to be able to use taproot after its activation. Many wallet and service developers rose to the occasion and ensured they would be ready to allow anyone to use taproot upon activation. Other soft fork proposals were updated to use taproot or lessons learned from its activation.

  • ● August was quiet for taproot development, although some documentation related to taproot was written.

  • ● September saw Bitcoin’s most popular open source merchant software add support for taproot in advance of its planned activation. It also saw the proposal for a new opcode that would make special use of taproot features to enable script-based covenants.

  • ● October began with renewed development activity as taproot activation approached. Taproot’s BIP was updated with expanded test vectors to help wallet and infrastructure developers verify their implementations.

  • ● November celebrated taproot activation. There was some initial confusion as the miners of block 709,632 and several subsequent blocks didn’t include any taproot-spending transactions. However, thanks to the work of several developers and mining pool administrators, most blocks mined in subsequent days were ready to contain taproot-spending transactions. Development and testing of taproot-ready software continued.

  • ● December saw Bitcoin Core merge a PR that would allow descriptor wallets to create bech32m addresses for receiving taproot payments. LN developers also further discussed making use of taproot’s features.

Despite complications choosing an activation mechanism for taproot and some minor confusion immediately after its activation, the final steps of adding support for the taproot soft fork to Bitcoin overall seemed to go well. This is hardly the end of the story for taproot. Optech expects to continue to spend a significant amount of time writing about it in the coming years as wallet and infrastructure developers begin making use of its many features.

April

LND added support in April for making Atomic Multipath Payments (AMP), also called original AMPs due to being described earlier than the Simplified Multipath Payments (SMPs) all major LN implementations currently support. AMPs have a privacy advantage over SMPs and also ensure that the receiver has received all parts before they claim the payment. Their downside is that they don’t produce cryptographic proof of payment. LND implemented them for use with spontaneous payments which fundamentally can’t provide a proof of payment, eliminating from consideration the one significant downside of AMPs.

May

A discrepancy between the specification of BIP125 transaction replacement and the implementation in Bitcoin Core was disclosed in May. This didn’t put any bitcoins at risk, as far as we know, but it did spawn several discussions about the risks to users of contract protocols (such as LN) from unexpected transaction relay behavior.

Also in May, the C-Lightning project merged a plugin for managing dual-funded channels—channels where both parties can provide some amount of the initial funding. In addition to prior dual-funding work merged this year, this allows the party initiating the channel open to not only spend funds through the channel but also receive them in the channel’s initial state. That initial ability to receive funds makes dual-funding particularly useful for merchants whose primary use of LN is receiving payments instead of sending them.

June

A new analysis discussed in June described an alternative way for miners to select which transactions they want to include in the blocks they create. The new method is predicted to slightly increase miner revenue in the short term. In the long-term, if the technique is adopted by miners, wallets aware of it will be able to collaborate when CPFP fee bumping transactions, increasing the effectiveness of that technique.

Another attempt to make fee bumping more effective was a proposal to allow any unconfirmed transaction to be replaced by fee (RBF) in Bitcoin Core—not just those that opt-in to allowing replacement using BIP125. This could help resolve some issues with fee bumping in multiparty protocols and also improve privacy by allowing more transactions to use uniform settings. Related to privacy, a separate proposal suggested that wallets creating taproot spends should set a default nSequence value even when they don’t need the features offered by BIP68’s consensus enforced sequence values; this would allow transactions created by software that does need to use BIP68 to blend in with more common transactions. Neither proposal seemed to make much progress despite few significant objections.

June also saw the merge of the first PR in a series implemeting mempool package acceptance in Bitcoin Core, the first step towards package relay. Package relay will allow relay nodes and miners to treat packages of related transactions as if they were a single transaction for feerate purposes. A package might contain a parent transaction with a low feerate and a child transaction with a high feerate; the profitability of mining the child transaction would incentivize miners to also mine the parent transaction. Although package mining has been implemented in Bitcoin Core since 2016, there has so far been no way for nodes to relay transactions as packages, meaning low-feerate parent transactions might not reach miners during high-feerate periods even if they have high-feerate children. This makes CPFP fee bumping unreliable for contract protocols using presigned transactions, such as LN. Package relay hopes to solve this key safety issue.

An idea originally proposed in 2019 for LN saw renewed life in June. The original fast forwards idea described how an LN wallet could receive or relay a payment with fewer network round-trips, reducing network bandwidth and payment latency. The idea was expanded this year to describe how an LN wallet could receive multiple payments without bringing its signing key online for every payment, making it easier to keep that signing key secured.

July

After years of discussion and development, the first implementation of a decentralized liquidity advertisements system was merged into an LN implementation. The still-draft liquidity ads proposal 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 inbound capacity that allows them to receive instant payments. A node that sees the advertisement can simultaneously pay for and receive the inbound 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 later used in Lightning Pool) that prevents the advertiser from using their money for other purposes until the agreed upon lease period has concluded. That means refusing to route payments would provide no advantages but would deny the advertising node the opportunity to earn routing fees.

Three years after first being proposed for Bitcoin Core, draft BIPs were created for output script descriptors. Descriptors are strings that contain all the information necessary to allow a wallet or other program to track payments made to or spent from a particular script or set of related scripts (i.e. an address or a set of related addresses such as in an HD wallet). Descriptors combine well with miniscript in allowing a wallet to handle tracking and signing for a larger variety of scripts. They also combine well with PSBTs in allowing the wallet to determine which keys it controls in a multisig script. By the end of the year, Bitcoin Core had made descriptor-based wallets its default for newly-created wallets.

A common way of opening LN channels that had never before been part of the LN protocol began to be specified in July. Zero-conf channel opens, also called turbo channels, are new single-funded channels where the funder gives some or all of their initial funds to the acceptor. Those funds are not secure until the channel open transaction receives a sufficient number of confirmations, so there’s no risk to the acceptor spending some of those funds back through the funder using the standard LN protocol. For example, Alice has several BTC in an account at Bob’s custodial exchange. Alice asks Bob to open a new channel paying her 1.0 BTC. Because Bob trusts himself not to double-spend the channel he just opened, he can allow Alice to send 0.1 BTC through his node to third-party Carol even before the channel open transaction has received a single confirmation. Specifying the behavior should help improve interoperability between LN nodes and the merchants who offer this service.

Zero-conf channel illustration

Two related proposals for new signature hash (sighash) types were combined into BIP118. SIGHASH_NOINPUT, proposed in 2017 and partly based on previous proposals going back a decade, was superseded by SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT first proposed in 2019. The new sighash types will allow offchain protocols such as LN and vaults to reduce the number of intermediate states they need to retain, greatly reducing storage requirements and complexity. For multiparty protocols, the benefits may be even more significant by eliminating the number of different states that need to be generated in the first place.

August

Fidelity bonds is an idea described at least as early as 2010 for locking up bitcoins for a period of time in order to create a cost for misbehavior in third-party systems. Because the bitcoins can’t be used again until their time lock expires, users in the other system who are banned or otherwise penalized during the locking period are prevented from using the same bitcoins to create a new virtual identity. In August, JoinMarket put into production the first large scale and decentralized use of fidelity bonds. Within days of release, over 50 BTC had been timelocked (worth over $2 million USD at the time).

A new variation of pathfinding for LN was discussed in August. Proponents of the technique thought that it would be most effective if routing nodes only charged a percentage of the amount routed without charging a minimum base fee on every payment. Others felt differently. By the end of the year, a variation on the technique would be implemented in C-Lightning.

2021 summary
Bitcoin Optech

In Optech’s fourth year, we published 51 weekly newsletters, added 30 new pages to our topics index, published a contributed blog post, and wrote (with the help of two guest posters) a 21-part series about preparing for taproot. Altogether, Optech published over 80,000 words about Bitcoin software research and development this year, the rough equivalent of a 250-page book.

September

One feature Bitcoin developers have long discussed is the ability to send bitcoins to a script which could limit which other scripts could later receive those bitcoins, a mechanism called covenants. For example, Alice receives bitcoins to a script that can be spent by her hot wallet—but only by sending it to a second script that time delays any further spend by her hot wallet. During the time delay, her cold wallet can claim the funds. If it doesn’t, and the time delay passes, Alice’s hot wallet can spend the funds freely. In September, a new OP_TAPLEAF_UPDATE_VERIFY opcode was proposed for creating these sort of covenants in a way that takes particular advantage of taproot’s ability to spend funds either using just a signature (keypath spending) or a MAST-like tree of scripts (scriptpath spending). The new opcode would be especially useful for creating joinpools that could significantly increase privacy by allowing multiple users to easily and trustlessly share ownership of a UTXO.

October

In October, Bitcoin developers discussed a new way for a transaction to identify which set of bitcoins it wanted to spend. Currently, bitcoins are identified by their location in the transaction that last spent them; for example “transaction foo, output zero”. A new proposal would allow identifying bitcoins using a previous transaction that spent them plus their placement in the descent hierarchy and their location; for example, “transaction bar’s second child, output zero”. It was suggested that this would provide advantages for designs such as eltoo, channel factories, and watchtowers, all of which benefit contract protocols such as LN.

Also in October, a combination of existing ideas for improving LN were bundled into a single proposal that would bring some of the same benefits of eltoo but without requiring the SIGHASH_ANYPREVOUT soft fork or any other consensus changes. The proposal would reduce payment latency to nearly as fast as data could travel one way between all the routing nodes on a particular path. It would also increase resiliency by allowing a node to back up all of the information it needs at the time a channel is created and obtain any other information in most cases during a data restore. It would also allow receiving payments with an offline key, allowing merchant nodes in particular to limit the amount of time their keys needed to be used by online computers.

November

LN developers held the first general LN summit since 2018 and discussed topics including using taproot in LN, including PTLCs, MuSig2 for multisignatures, and eltoo; moving specification discussion from IRC to video chats; changes to the current BOLTs specification model; onion messages and offers; stuckless payments; channel jamming attacks and various mitigations; and trampoline routing.

December

For single-sig onchain transactions, fee bumping a transaction’s feerate to encourage miners to confirm it sooner is a relatively straightforward operation. But for contract protocols such as LN and vaults, not all the signers who authorized a spend may be available when fee bumping is needed. Worse, contract protocols often require certain transactions to be confirmed by a deadline—or an honest user could lose money. December saw the publication of research related to choosing effective fee bumping mechanisms for contract protocols, helping spur discussion of solutions to this important long-term problem.

Conclusion

We tried something new in this year’s summary—describing two dozen noteworthy developments in 2021 without mentioning even a single contributor’s name. We’re indebted to all of those contributors and very much want to see them credited for their incredible work, but we also want to recognize all of the contributors who we wouldn’t normally mention.

They’re the people spending hours on code reviews, or who are writing tests for established behavior to ensure it doesn’t unexpectedly change, or who put effort into debugging mysterious issues to fix problems before money is put at risk, or who are working on a hundred other tasks that would only make the news if they weren’t being done.

This final newsletter of 2021 is dedicated to them. We don’t have an easy way to make a list of the names of these underacknowledged contributors. Instead we’ve omitted all names from this newsletter to make the point that developing Bitcoin is a team effort where some of the most important work is being done by people whose names have never appeared in any issue of this newsletter.

We thank them and all contributors to Bitcoin in 2021. We can’t wait to see what exciting new developments they will deliver in 2022.

The Optech newsletter will return to its regular Wednesday publication schedule on January 5th.