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

Contents

January

In January, LDK merged an implementation of stateless invoices, which allows it to generate an infinite number of invoices without storing any data about them unless payment is successful. Stateless invoices were previously proposed in September 2021 and LDK’s implementation differs from the suggested method, although it accomplishes the same goal and doesn’t require any LN protocol changes. Later that month, an update to the LN specification was merged to allow other types of stateless invoices, with at least partial support for it being added to Eclair, Core Lightning, and LND.

Also in January, a Bitcoin Legal Defense Fund was announced by Jack Dorsey, Alex Morcos, and Martin White. It provides “a nonprofit entity that aims to minimize legal headaches that discourage software developers from actively developing Bitcoin and related projects.”

February

A discussion in January about making it easier to add fees to presigned transactions, lead to renewed discussion in February about Jeremy Rubin’s transaction fee sponsorship idea from 2020. Several challenges to its implementation were mentioned. Although the immediate discussion didn’t make much progress, a technique that accomplished similar goals—but which, unlike sponsorship, didn’t require a soft fork—would be proposed in October.

LDK’s early support for stateless invoices allowed it to add a new and simple method for load balancing an LN node called phantom node payments.

Illustration of phantom node payment path

March

The LN pathfinding algorithm first published in 2021 by René Pickhardt and Stefan Richter received an update in March with Pickhardt noting an improvement that made it much more computationally efficient.

A consistent method for allowing zero-conf channels was specified and began seeing implementation support, starting with LDK’s addition in March of support for the related Short Channel IDentifier (SCID) alias field, followed by Eclair, Core Lightning, and LND.

Illustration of zero-conf channels

2022 summary
Replace-By-Fee

This year saw much discussion, and some significant actions, related to Replace By Fee (RBF). Our January newsletter summarized a proposal by Jeremy Rubin to allow any transaction to be replaced by a higher fee alternative for a brief while after it was first seen by a node. After that time has passed, the existing rules would apply—only allowing replacement of transactions opting in to BIP125. This could allow merchants to accept unconfirmed transactions like they do now after the replacement time elapsed. More importantly, it may allow protocols that depend on replaceability for security to not have to worry about non-opt-in transactions as long as a protocol node or watchtower can reasonably respond soon after first learning of a transaction.

At the end of January, Gloria Zhao started a fresh discussion about RBF by posting background on the current RBF policy, with the enumeration of several problems discovered with it over the years (such as pinning attacks), an examination of how the policy affects wallet user interfaces, and the description of several possible improvements. In early March, Zhao followed up with the summary of two discussions about RBF between many developers, one discussion in person and the other online.

Also in March, Larry Ruane raised questions related to RBF about replacing transaction witnesses without changing other parts of a transaction.

In June, Antoine Riard opened a pull request to Bitcoin Core to add a mempoolfullrbf configuration option to Bitcoin Core. The option defaulted to Bitcoin Core’s previous behavior of only allowing unconfirmed transactions to be replaced if they contained the BIP125 signal. Nodes which were configured with the option set to it’s alternative value would accept transactions for relay and mining even if they replaced transactions that did not contain the BIP125 opt-in signal. Riard also started a thread on the Bitcoin-Dev mailing list to discuss the change. Almost all pull request comments were positive and most mailing list discussion was about unrelated topics, so it was unsurprising that the pull request was merged about a month after it was opened.

In October, the Bitcoin Core project began distributing release candidates for version 24.0, which would be the first to include the mempoolfullrbf configuration option. Dario Sneidermanis saw the draft release notes about the option and posted to the Bitcoin-Dev mailing list that too many users and miners enabling the option would make unsignaled replacement reliable. More reliable unsignaled replacement would also make it more reliable to steal from services that accept unconfirmed transactions as final, requiring those services to change their behavior. Discussion continued the next week and the week after. A month after Sneidermanis raised the initial concern on the mailing list, Suhas Daftuar summarized some of the arguments against the option and opened a pull request to remove it from Bitcoin Core.

Many counterarguments in favor of keeping the mempoolfullrbf option were also made. Those included several wallet developers noting that they sometimes encounter users who want to make replacements even though those users didn’t opt in to BIP125.

By the end of November, Daftuar closed his PR and the Bitcoin Core project released version 24.0 with the mempoolfullrbf option. In December, developer 0xB10C released a website for monitoring transaction replacements which did not contain the BIP125 signal, indicating that any of those transactions which became confirmed may have been processed by a miner using the mempoolfullrbf option to enable full-RBF (or a similar feature in other software). At the end of the year, full-RBF was still being discussed in other Bitcoin Core PRs and on the mailing list.

April

In April, Ruben Somsen proposed the idea of silent payments, which would allow someone to pay a public identifier (“address”) without using that identifier onchain. This would help prevent address reuse. For example, Alice would be able to post a public identifier on her website that Bob can transform into a new unique Bitcoin address from which only Alice will be able to spend. If Carol later goes to Alice’s website and reuses Alice’s public identifier, she would derive a different address to pay Alice, an address which neither Bob nor any other third party could directly determine belonged to Alice. Later, developer W0ltx would implement silent payments for Bitcoin Core as a PR, including updating the implementation later in the year.

Lightning Labs announced Taro, a proposed protocol (based on previous proposals) for allowing users to commit to the creation and transfer of non-bitcoin tokens on Bitcoin’s block chain. Taro is intended to be used with LN for routable offchain transfers. Similar to previous proposals for cross-asset transfers on LN, intermediate nodes that just forward payments won’t need to be aware of the Taro protocol or the details of the assets being transferred—they’ll just transfer bitcoins using the same protocol as any other LN payment.

April also saw discussion about quantum-safe key exchange—allowing users to receive bitcoins secured by keys that are resistant to attacks by fast quantum computers that may exist in the future.

May

The MuSig2 protocol for creating schnorr multisignatures saw several developments in 2022. A proposed BIP received significant feedback in May. Later, in October, researchers discovered a vulnerability in some ways the protocol could be used, which the researchers planned to fix in an updated version.

A draft BIP for package relay was posted by Gloria Zhao in May. Package relay fixes a significant problem with Bitcoin Core’s CPFP fee bumping where individual nodes will only accept a fee-bumping child transaction if its parent transaction pays a feerate above the node’s dynamic minimum mempool fee. This makes CPFP insufficiently reliable for protocols depending on presigned transactions, such as many contract protocols (including the current LN protocol). Package relay allows a parent and child transaction to be evaluated as a single unit, eliminating the problem—although not eliminating other related problems such as transaction pinning. Additional discussion of package relay ocurred in June.

May also saw the first merge for the Bitcoin Kernel Library Project (libbitcoinkernel), an attempt to separate out as much of Bitcoin Core’s consensus code as possible into a separate library, even if that code still has some non-consensus code attached. Long-term, the goal is to trim down libbitcoinkernel until it contains only consensus code, making it easy for other projects to use that code or for auditors to analyze changes to Bitcoin Core’s consensus logic. Several additional libbitcoinkernel PRs would be merged through the year.

June

In June, LN developers met to discuss the future of protocol development. Topics discussed included taproot-based LN channels, tapscript and MuSig2 (including recursive MuSig2), updating the gossip protocol for announcing new and changed channels, onion messages, blinded paths, probing and balance sharing, trampoline routing, and the offers and LNURL protocols.

July

In July, Bastien Teinturier posted a summary of an idea he attributes to Rusty Russell for rate limiting onion messages in order to prevent denial-of-service attacks. However, Olaoluwa Osuntokun suggested reconsideration of his March proposal for preventing abuse of onion messages by charging for data relay. It seemed that most developers in the discussion preferred to attempt rate limiting before adding additional fees to the protocol.

This month Bitcoin Core also merged a pull request adding watch-only support for output script descriptors written in miniscript. A future PR is expected to allow the wallet to create signatures for spending miniscript-based descriptors. As other wallets and signing devices implement miniscript support, it should become easier for policies to be transferred between wallets or for multiple wallets to cooperate in spending bitcoins, such as multisig policies or policies involving different signers for different occasions (e.g. fallback signers).

August

In August, Eclair merged support for the interactive funding protocol, a dependency for the dual funding protocol that allows either (or both) of two nodes to contribute funds to a new LN channel. Later that month, another merge brought Eclair experimental support for dual funding. An open protocol for dual funding can help ensure merchants have access to channels that allow them to immediately receive payments from customers.

Antoine Riard and Gleb Naumenko published a guide in August to channel jamming attacks and several proposed solutions. For every channel an attacker controls, they can make more than a dozen other channels unusable by sending payments that never complete—meaning the attacker doesn’t need to pay any direct costs. The problem has been known since 2015 but no previously proposed solution has gained widespread acceptance. In November, Clara Shikhelman and Sergei Tikhomirov would publish their own paper with analysis and a proposed solution based on small upfront fees and automated reputation-based referrals. Subsequently, Riard published an alternative solution involving non-tradable node-specific tokens. In December, Joost Jager would announce a “simple but imperfect” utility that could help nodes mitigate some problems with jamming without requiring any changes to the LN protocol.

Illustration of the two types of channel jamming attacks

Lloyd Fournier wrote about the benefits of having DLC oracles make their attestations using Boneh-Lynn-Shacham (BLS) signatures. Bitcoin does not support BLS signatures and a soft fork would be required to add them, but Fournier links to a paper he co-authored that describes how information can be securely extracted from a BLS signature and used with Bitcoin-compatible signature adaptors without any changes to Bitcoin. This would allow “stateless” oracles where the parties to a contract (but not the oracle) could privately agree on what information they wanted the oracle to attest to, e.g. by specifying a program written in any programming language they knew the oracle would run. They could then allocate their deposit funds according to the contract without even telling the oracle that they were planning to use it. When it came time to settle the contract, each of the parties could run the program themselves and, if they all agreed on the outcome, settle the contract cooperatively without involving the oracle at all. If they didn’t agree, any one of them could send the program to the oracle (perhaps with a small payment for its service) and receive back a BLS attestation to the program source code and the value returned by running it. The attestation could be transformed into signatures that would allow settling the DLC on chain. As with current DLC contracts, the oracle would not know which onchain transactions were based on its BLS signatures.

2022 summary
Bitcoin Optech

In Optech’s fifth year, we published 51 weekly newsletters, added 11 new pages to our topics index. Altogether, Optech published over 70,000 words about Bitcoin software research and development this year, the rough equivalent of a 200-page book.

September

Lisa Neigut posted to the Lightning-Dev mailing list a proposal for fee ratecards that would allow a node to advertise four tiered rates for forwarding fees. Better advertisement of forwarding fees, including the ability to set negative fees in some cases, could help ensure forwarding nodes had enough capacity to relay payments towards their ultimate destination. Developer ZmnSCPxj, who had posted his own fee-based solution for improving routing earlier in the year, described a simple way to use ratecards, “you can model a rate card as four separate channels between the same two nodes, with different costs each. If the path at the lowest cost fails, you just try another route that may have more hops but lower effective cost, or else try the same channel at a higher cost.” An alternative method for payment flow control was suggested by René Pickhardt.

October

In October, Glora Zhao proposed allowing transactions that used version number 3 to use a modified set of transaction relay policies. These policies are based on experience using CPFP and RBF, plus ideas for package relay, and are designed to help preventing pinning attacks against two-party contract protocols like LN—ensuring that users can promptly get transactions confirmed for closing channels, settling payments (HTLCs), and enforcing misbehavior penalties. Greg Sanders would follow up later in the month with an additional proposal for ephemeral anchors, a simplified form of the anchor outputs already usable with most LN implementations.

Eclair added support for a basic form of async payments when trampoline relay is used. Async payments would allow paying an offline node (such as a mobile wallet) without trusting a third-party with the funds. The ideal mechanism for async payments depends on PTLCs, but a partial implementation just requires a third party to delay forwarding the funds until the offline node comes back online. Trampoline nodes can provide that delay and so this PR makes use of them to allow experimentation with async payments

October also saw the first of two block parsing bugs that affected multiple applications. An accidentally triggered bug in BTCD prevented it and downstream program LND from processing the latest blocks. This could have led to users losing funds, although no such problems were reported. A second related bug, this time deliberately triggered, affected BTCD and LND again, plus users of some versions of Rust-Bitcoin. Again, there was a potential for users to lose money, although we are unaware of any reported incidents.

John Light posted a research report he prepared about validity rollups—a type of sidechain where the current sidechain state is compactly stored on the mainchain. An owner of sidechain bitcoins can use the state stored on the mainchain to prove how many sidechain bitcoins they control. By submitting a mainchain transaction with a validity proof, they can withdraw bitcoins they own from the sidechain even if the operators or miners of the sidechain try to prevent the withdrawal. Light’s research describes validity rollups in depth, looks at how support for them could be added to Bitcoin, and examines various concerns with their implementation.

The BIP324 proposal for an encrypted v2 P2P transport protocol received an update and mailing list discussion for the first time in three years. Encrypting the transport of unconfirmed transactions can help hide their origin from eavesdroppers who control many internet relays (e.g. large ISPs and governments). It can also help detect tampering and possibly make eclipse attacks more difficult.

A meeting of Bitcoin protocol developers had several sessions transcribed by Bryan Bishop, including discussions about transport encryption, transaction fees and economic security, the FROST threshold signature scheme, the sustainability of using GitHub for source code and development discussion hosting, including provable specifications in BIPs, package relay and v3 transaction relay, the Stratum version 2 mining protocol, and getting code merged into Bitcoin Core and other free software projects.

2022 summary
Soft fork proposals

January began with Jeremy Rubin holding the first of several IRC meetings to review and discuss the OP_CHECKTEMPLATEVERIFY (CTV) soft fork proposal. Meanwhile, Peter Todd posted several concerns with the proposal to the Bitcoin-Dev mailing list, most notably expressing concern that it didn’t seem to benefit nearly all Bitcoin users, as he believes previously soft forks have done.

Lloyd Fournier posted to the DLC-Dev and Bitcoin-Dev mailing lists about how the CTV opcode could radically reduce the number of signatures required to create certain Discreet Log Contracts (DLCs), as well as reduce the number of some other operations. Jonas Nick noted that a similar optimization is also possible using the proposed SIGHASH_ANYPREVOUT (APO) signature hash mode.

Russell O’Connorr proposed an alternative to both CTV and APO—a soft fork adding an OP_TXHASH opcode and an OP_CHECKSIGFROMSTACK (CSFS) opcode. The TXHASH opcode would specify which parts of a spending transaction should be serialized and hashed, with the hash digest being put on the evaluation stack for later opcodes to use. The CSFS opcode would specify a public key and require a corresponding signature over particular data on the stack—such as the computed digest of the transaction created by TXHASH. This would allow emulation of CTV and APO in a way that might be simpler, more flexible, and easier to extend through other subsequent soft forks.

In February, Rusty Russell would propose OP_TX, an even simpler version of OP_TXHASH. Meanwhile, Jeremy Rubin published parameters and code for a signet with CTV activated. This simplifies public experimentation with the proposed opcode and makes it much easier to test compatibility between different software using the code. Also in February, developer ZmnSCPxj proposed a new OP_EVICT opcode as an alternative to the OP_TAPLEAF_UPDATE_VERIFY (TLUV) opcode proposed in 2021. Like TLUV, EVICT is focused on use cases where more than two users share ownership of a single UTXO, such as joinpools, channel factories, and certain covenants. ZmnSCPxj would later propose a different new opcode, OP_FOLD, as a more general construct from which EVICT-like behavior could be built (though that would require some other Script language changes).

By March, the discussion about CTV and newer opcode proposals led to a discussion about limiting the expressiveness of Bitcoin’s Script language, mainly to prevent recursive covenants—conditions that would need to be fulfilled in every transaction re-spending those bitcoins or any bitcoins merged with it for perpetuity. Concerns included a loss of censorship resistance, enabling drivechains, encouraging unnecessary computation, and making it possible for users to accidentally lose coins to recursive covenants.

March also saw yet another idea for a soft fork change to Bitcoin’s Script language, this time to allow future transactions to opt-in to a completely different language based on Lisp. Anthony Towns proposed the idea and described how it might be better than both Script and a previously-proposed replacement: Simplicity.

In April, Jeremy Rubin posted to the Bitcoin-Dev mailing list his plan to release software that will allow miners to begin signaling whether they intend to enforce the BIP119 rules for the proposed CTV opcode. This spurred discussion about CTV and similar proposals, such as APO. Rubin later announced he wouldn’t be releasing compiled software for activating CTV at the present time as he and other CTV supporters evaluated the feedback they’d received.

In May, Rusty Russell updated his OP_TX proposal. The original proposal would allow recursive covenants, which elicited the concerns mentioned earlier in this section. Instead, Russell proposed an initial version of TX that was limited to permitting the behavior of CTV, which had been specifically designed to prevent recursive covenants. This new version of TX could be incrementally updated in the future to provide additional features, making it more powerful but also allowing those new features to be independently analyzed. Additional discussion in May examined the OP_CAT opcode (removed from Bitcoin in 2010), which some developers occasionally suggest might be a candidate for adding back in the future.

In September, Jeremy Rubin described how a trusted setup procedure could be combined with the proposed APO feature to implement behavior similar to that proposed by drivechains. Preventing the implementation of drivechains on Bitcoin was one of the reasons developer ZmnSCPxj suggested earlier in the year that full node operators might want to oppose soft forks that enable recursive covenants.

Also in September, Anthony Towns announced a Bitcoin implementation designed specifically for testing soft forks on signet. Based on Bitcoin Core, Towns’s code will enforce rules for soft fork proposals with high-quality specifications and implementations, making it simpler for users to experiment with the proposed changes—including comparing changes to each other or seeing how they interact. Towns also plans to include proposed major changes to transaction relay policy (such as package relay).

In November, Salvatore Ingala posted to the Bitcoin-Dev mailing list a proposal for a new type of covenant (requiring a soft fork) that would allow using merkle trees to create smart contracts that can carry state from one onchain transaction to another. This would be similar in capability to smart contracts used on some other cryptocurrency systems but would be compatible with Bitcoin’s existing UTXO-based system.

November

November saw Joost Jager update a proposal from 2019 to improve error reporting in LN for failed payments. The error would report the identity of a channel where a payment failed to be forwarded by a node so that the spender could avoid using channels involving that node for a limited time. Several LN implementations would update their code to support the proposal, even if they didn’t immediately begin using it themselves, including Eclair and Core Lightning.

December

In December, protocol developer John Law posted to the Lightning-Dev mailing list his third major proposal for the year. Like his previous two proposals, he suggested new ways LN offchain transactions could be designed to enable new features without requiring any changes to Bitcoin’s consensus code. Altogether, Law proposed ways casual LN users could remain offline for potentially months at a time, separating the enforcement for specific payments from the management of all settled funds to improve compatibility with watchtowers, and optimizing LN channels for use in channel factories that could significantly decrease the onchain costs to use LN.

We thank all of the Bitcoin contributors named above, plus the many others whose work was just as important, for another incredible year of Bitcoin development. The Optech newsletter will return to its regular Wednesday publication schedule on January 4th.