- Featured summaries
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.”
A discussion in January about making it easier to add fees to presigned transactions led 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.
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.
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 the original transaction was first seen by a node. After that time had 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 has a reasonable opportunity to 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, enumerating 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 the parts of a transaction from which its txid is derived.
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
its 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.
Other similar pull requests were opened previously or subsequently, but
Daftuar’s pull request became the focus for discussion about possibly
permanently removing the option.
Many counterarguments in favor of keeping the
were made on Daftuar’s pull request. 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.
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 create a proposed implementation of silent payments for Bitcoin Core, making significant updates to it 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.
The MuSig2 protocol for creating schnorr multisignatures saw several developments in 2022. A proposed BIP received significant feedback in May. Later, in October, Yannick Seurin, Tim Ruffing, Elliott Jin, and Jonas Nick discovered a vulnerability in some ways the protocol could be used, which the researchers announced that they 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 occurred 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.
Major releases of popular infrastructure projects
● Bitcoin Core 23.0 provided descriptor wallets by default for new wallets and also allowed descriptor wallets to easily support receiving to bech32m addresses using taproot. It also increased its support for using non-default TCP/IP ports and began allowing use of the CJDNS network overlay.
● LND 0.15.0-beta added support for invoice metadata which can be used by other programs (and potentially future versions of LND) for stateless invoices and adds support to the internal wallet for receiving and spending bitcoins to P2TR keyspend outputs, along with experimental MuSig2 support.
● Core Lightning 0.12.0 added a new
commandoplugin, and support for static channel backups, plus explicitly began allowing peers the ability to open zero-conf channels to your node.
● Bitcoin Core 24.0.1 added an option for configuring the node’s Replace-By-Fee (RBF) policy, a new
sendallRPC for easily spending all of a wallet’s funds in a single transaction, a
simulaterawtransactionRPC that can be used to verify how a transaction will affect a wallet, and the ability to create watch-only descriptors containing miniscript expressions for improved forward compatibility with other software.
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.
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).
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 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.
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.
In Optech’s fifth year, we published 51 weekly newsletters and 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.
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.
In October, Gloria 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, along with 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.
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’Connor 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
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
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
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 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.
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.