The seventh annual Bitcoin Optech Year-in-Review special summarizes notable developments in Bitcoin during all of 2024. It’s the sequel to our summaries from 2018, 2019, 2020, 2021, 2022, and 2023.

Contents

January

John Law proposed fee-dependent timelocks, a soft fork allowing timelocks to expire only when median block feerates drop below a user-specified level. This prevents high fees near expiration from preventing confirmation, which can lead to funds loss. Instead, the timelock extends until fees fall to a predetermined value, addressing longstanding concerns of forced expiration floods during mass channel closures. The proposal improves security for multi-user setups like channel factories and joinpools while incentivizing participants to avoid fee spikes. Discussions included storing parameters in the taproot annex, feerate commitments for lightweight clients, pruned node support, and the impact of out-of-band fees.

Salvatore Ingala proposed a method to optimize exits from multiparty contracts, like joinpools or channel factories, by enabling users to coordinate a single transaction instead of broadcasting separate ones. This reduces onchain size by at least 50% and up to 99% under ideal circumstances, which is critical when fees are high. A bond mechanism ensures honest execution: one participant constructs the transaction but forfeits the bond if proven fraudulent. Ingala suggests implementing this with OP_CAT and MATT soft fork features, with further efficiency possible using OP_CSFS and 64-bit arithmetic.

Gregory Sanders shared a proof-of-concept implementation of LN-Symmetry using a fork of Core Lightning. LN-Symmetry enables bi-directional payment channels without penalty transactions but relies on a soft fork like SIGHASH_ANYPREVOUT to allow child transactions to spend any parent version. Sanders highlighted its simplicity compared to LN-Penalty, the difficulty of avoiding pinning (inspiring his work on package relay and ephemeral anchors), and the potential for faster payments via emulation of OP_CTV. He confirmed penalties are unnecessary, simplifying channel implementation and avoiding reserved funds. However, LN-Symmetry requires longer CLTV expiry deltas to prevent misuse.

February

Peter Todd proposed Replace by Feerate (RBFr) to address transaction pinning when standard RBF policies fail, with two variations: pure RBFr, allowing unlimited replacements with much higher feerates (e.g., 2x), and one-shot RBFr, enabling a single replacement with moderately higher fees (e.g., 1.25x) if the replacement enters the top of the mempool. Mark Erhardt identified an initial problem and other developers discussed the complexities of fully analyzing the idea with available tools. Todd released an experimental implementation and other developers continued working on alternative solutions to address transaction pinning, including developing the tools necessary to increase confidence in any solution that is adopted.

Matt Corallo proposed a BIP for DNS-based human-readable Bitcoin payment instructions, allowing an email-like string (e.g., example@example.com) to resolve to a DNSSEC-signed TXT record containing a BIP21 URI. This supports onchain addresses, silent payments, and LN offers—and can be easily extended to other payment protocols. A specification of this was added as BIP353. Corallo also drafted a BOLT and BLIP for LN nodes, enabling wildcard DNS records and secure payment resolution using offers. An implementation was merged into LDK in November. Development of this protocol and silent payments led Josie Baker to start a discussion about revising BIP21 payment URIs, which continued later in the year.

Fabian Jahr wrote software that allows multiple developers to independently create equivalent ASMaps, which helps Bitcoin Core diversify peer connections and resist eclipse attacks. If Jahr’s tooling becomes widely accepted, Bitcoin Core may include ASMaps by default, enhancing protection against attacks from parties controlling nodes on multiple subnets.

Support for dual funding was added to the LN specification along with support for the interactive transaction construction protocol. Interactive construction allows two nodes to exchange preferences and UTXO details they can use to construct a funding transaction together. Dual funding allows a transaction to include inputs from either or both parties. For example, Alice may want to open a channel with Bob. Before this specification change, Alice had to provide all the funding for the channel. Now, when using an implementation that supports dual funding, Alice can open a channel with Bob where he provides all of the funding or where each contributes funds to the initial channel state. This can be combined with the experimental liquidity advertisements protocol, which has not yet been added to the specification.

ZmnSCPxj proposed trustless scripts enabling two parties to bet on future block feerates. A user wanting a transaction confirmed by some future block can use this to offset the risk that feerates will be unusually high at the time. A miner expecting to mine a block around the time the user needs their transaction confirmed can use this contract to offset the risk that feerates will be unusually low. The design prevents manipulation seen in centralized markets, as the miner’s decisions rely solely on actual mining conditions. The contract is trustless with a cooperative spend path that minimizes costs for both parties.

Summary 2024: Vulnerability disclosures

In 2024, Optech summarized more than two dozen vulnerability disclosures. The majority were old disclosures from Bitcoin Core which were being published for the first time this year. Vulnerability reports give both developers and users the opportunity to learn from past problems, and responsible disclosures allow us all to thank those who report their discoveries with discretion.

Note: Optech only publishes the names of vulnerability discoverers if we think they made a reasonable effort to minimize the risk of harm to users. We thank all persons named in this section for their insight and clear concern for user safety.

Late in 2023, Niklas Gögge publicly disclosed two vulnerabilities he had reported two years earlier, leading to the release of fixed versions of LND. The first, a DoS vulnerability, could have led to LND running out of memory and crashing. The second, a censorship vulnerability, could allow an attacker to prevent an LND node from learning about updates to targeted channels across the network; an attacker could use this to bias a node towards selecting specific routes for payments it sent, giving the attacker more forwarding fees and more information about the payments the node sent.

In January, Matt Morehouse announced a vulnerability that affected Core Lightning versions 23.02 through 23.05.2. When re-testing nodes that had implemented fixes for fake funding, which he previously discovered and disclosed, he was able to trigger a race condition that crashed CLN after about 30 seconds. If an LN node is shut down, it can’t defend a user against malicious or broken counterparties, which puts the user’s funds at risk.

Also in January, Gögge returned to announce a consensus failure vulnerability he found in the btcd full node. The code could misinterpret a transaction version number and apply the wrong consensus rules to a transaction using a relative timelock. This could prevent btcd full nodes from showing the same confirmed transactions as Bitcoin Core, putting users at risk of losing money.

February saw Eugene Siegel publish a Bitcoin Core vulnerability report he had initially disclosed almost three years previously. The vulnerability could be used to prevent Bitcoin Core from downloading recent blocks. This could be leveraged to prevent a connected LN node from learning about preimages necessary to resolve HTLCs, potentially leading to loss of money.

Morehouse returned in June to disclose a vulnerability that allowed crashing versions of LND before 0.17.0. As mentioned earlier, a shutdown LN node can’t defend a user against malicious or broken counterparties, which puts the user’s funds at risk.

July saw the first of multiple disclosures of vulnerabilities affecting past versions of Bitcoin Core. Wladimir J. Van Der Laan was investigating a vulnerability discovered by Aleksandar Nikolic in a library used by Bitcoin Core when he discovered a separate vulnerability allowing remote code execution; this was fixed upstream, and the fix was incorporated into Bitcoin Core. Developer Evil-Knievel discovered a vulnerability that could exhaust the memory of many Bitcoin Core nodes, causing them to crash, which could be used as part of other attacks to steal money (e.g., from LN users). John Newbery, citing co-discovery by Amiti Uttarwar, disclosed a vulnerability that could be used to censor unconfirmed transactions, which could also be used as part of attacks to steal money (again, an example case being from LN users). A vulnerability was reported that allowed consuming excessive CPU and memory, potentially leading to a node crash. Developer practicalswift discovered a vulnerability that could cause a node to ignore legitimate blocks for a period of time, delaying reaction to time-sensitive events that could affect contract protocols like LN. Developer sec.eine disclosed a vulnerability that could consume excessive CPU, which could be used to prevent a node from processing new blocks and transactions, potentially leading to multiple problems that could lead to loss of money. John Newbery responsibly disclosed another vulnerability that could exhaust the memory of many nodes, potentially leading to crashes. Cory Fields discovered a separate memory exhaustion vulnerability that could crash Bitcoin Core. John Newbery disclosed a third vulnerability that could waste bandwidth and limit a user’s number of peer connection slots. Michael Ford reported a memory exhaustion vulnerability affecting anyone who clicked on a BIP72 URL, which could crash a node.

More disclosures from Bitcoin Core followed in the subsequent months. Eugene Siegel discovered a method for crashing Bitcoin Core using addr messages. Michael Ford, investigating a report by Ronald Huveneers about the miniupnpc library, discovered a different method for crashing Bitcoin Core using local network connections. David Jaenson, Braydon Fuller, and multiple Bitcoin Core developers discovered a vulnerability that could be used to prevent a newly started full node from syncing to the best block chain; the vulnerability was eliminated with a post-merge bug fix by Niklas Gögge. Another remote crash vulnerability was discovered by Niklas Gögge, exploiting a problem with compact block message handling. Several users reported excessive CPU consumption, leading developers 0xB10C and Anthony Towns to investigate the cause and implement a solution. Several developers, including William Casarin and ghost43, reported problems with their nodes, leading to Suhas Daftuar isolating a vulnerability that could prevent Bitcoin Core from accepting a block for a long time. The final Bitcoin Core vulnerability report of the year described a method for delaying blocks by 10 or more minutes.

Lloyd Fournier, Nick Farrow, and Robin Linus announced Dark Skippy, an improved method for key exfiltration from a Bitcoin signing device which they previously responsibly disclosed to approximately 15 different hardware signing device vendors. Key exfiltration occurs when transaction signing code deliberately creates its signatures in such a way that they leak information about the underlying key material, such as a private key or a BIP32 HD wallet seed. Once an attacker obtains a user’s seed, they can steal any of the user’s funds at any time (including funds spent in the transaction that results in exfiltration, if the attacker acts quickly). This led to renewed discussion of anti-exfiltration signing protocols.

The introduction of a new testnet also saw the discovery of a new timewarp vulnerability. Testnet4 included a fix for the original time warp vulnerability, but developer Zawy discovered in August a new exploit that could reduce difficulty by about 94%. Mark “Murch” Erhardt further developed the attack to allow reducing difficulty to its minimum value. Several solutions were proposed and tradeoffs between them were still being discussed in December.

Illustration of new timewarp vulnerability

In October, Antoine Poinsot and Niklas Gögge disclosed another consensus failure vulnerability affecting the btcd full node. Since the original version of Bitcoin, it has contained an obscure (but critical) function used to extract signatures from scripts before hashing them. The implementation in btcd differed slightly from original version inherited by Bitcoin Core, making it possible for an attacker to create transactions that would be accepted by one node but rejected by the other, which could be used in various ways to cause users to lose money.

December saw David Harding disclose a vulnerability affecting Eclair, LDK, and LND by default (and Core Lightning with non-default settings). The party who requested to open a channel (opener) and who was responsible for paying any endogenous fees necessary to close the channel could commit to paying 98% of channel value to fees in one state, reduce the commitment to a minimal amount in a subsequent state, move 99% of channel value to the other party, and then close the channel in the 98%-fee state. This would result in the opener forfeiting 1% of channel value for using an old state but the other party losing 98% of channel value. If the opener mined the transaction themselves, they could keep the 98% of channel value paid to fees. This method would allow robbing about 3,000 channels per block.

A deanonymization vulnerability affecting Wasabi and related software was the final disclosure summarized by Optech this year. The vulnerability allows a coinjoin coordinator of the type used by Wasabi and GingerWallet to provide users with credentials that are supposed to be anonymous but which can be made distinct to allow tracking. Although one method of making credentials distinct has been eliminated, a more generalized problem allowing a coordinator to produce distinct credentials was identified in 2021 by Yuval Kogman and remains unfixed as of this writing.

March

Ongoing problems getting BIPs merged led to the creation in January of a new BINANA repository for specifications and other documentation. February and March saw the existing BIPs editor request help and the beginning of a process to add new editors. After extensive public discussion culminating in April, several Bitcoin contributors were made BIP editors.

Abubakar Sadiq Ismail proposed enhancing Bitcoin Core’s feerate estimation by using real-time mempool data. Currently, estimates rely on confirmed transaction data, which updates slowly but resists manipulation. Ismail developed preliminary code comparing the current approach with a new mempool-based algorithm. Discussions highlighted whether mempool data should adjust estimates up and down, or only lower them. Dual-adjustment improves utility, but limiting adjustments to lowering estimates may better prevent manipulation.

Martin Habovštiak proposed a method to boost unrelated transaction priorities using the taproot annex, significantly reducing space requirements compared to earlier fee sponsorship methods. David Harding suggested an even more efficient approach using signature commitment messages, requiring no on-chain space but relying on block ordering. For overlapping sponsor transactions, Harding and Anthony Towns proposed alternatives that use as little as 0.5 vbytes per boost. Towns noted that these sponsorship methods are compatible with the proposed cluster mempool design, although the most efficient versions present mild challenges for transaction validity caching by making it harder for nodes to precompute and store validity information. This sponsorship approach enables dynamic fee bumping at minimal cost, making it attractive for protocols needing exogenous fees, though trustless outsourcing remains an issue. Suhas Daftuar cautioned that sponsorship could create problems for non-participating users, suggesting it be opt-in if adopted to avoid unintended impacts.

April

Antoine Poinsot revisited Matt Corallo’s 2019 consensus cleanup proposal, addressing issues like slow block verification, time warp attacks allowing theft, and fake transaction vulnerabilities affecting light clients and full nodes. Poinsot also highlighted the duplicate transactions problem that will affect full nodes at block 1,983,702. All issues have soft-fork solutions, though one proposed fix for slow-verification blocks faced concerns over potentially invalidating rare presigned transactions. One of the proposed updates received significant discussion in August and September that looked at alternative methods for mitigating merkle tree vulnerabilities that affect lightweight clients and even (sometimes) full nodes. Although Bitcoin Core mitigated vulnerabilities as far as possible, a previous refactor dropped essential protections, so Niklas Gögge wrote code for Bitcoin Core that detects all currently detectable vulnerabilities as early as possible and rejects invalid blocks. In December, discussion turned to using the consensus cleanup soft fork to fix the Zawy-Murch variant of the time warp vulnerability that was discovered after the implementation on testnet4 of rules designed for the original consensus cleanup proposal.

A spin-off of the discussion about adding a new BIPs editor saw a desire to reform BIP2, which specifies the current process for adding new BIPs and updating existing BIPs. Discussion continued the following month, and September saw the publication of a draft BIP for an updated process.

LND introduced support for inbound routing fees, championed by Joost Jager, which allows nodes to charge channel-specific fees for payments received from peers. This helps nodes manage liquidity, such as charging higher fees for inbound payments from poorly managed nodes. Inbound fees are backward-compatible, initially set to negative (e.g., discounts) to work with older nodes. Although proposed years ago, other LN implementations have resisted the feature, citing design concerns and compatibility issues. The feature saw continued development in LND throughout the year.

Greg Sanders proposed using weak blocks—blocks with insufficient proof-of-work (PoW) but valid transactions—to improve compact block relay amid divergent transaction relay and mining policies. Miners naturally produce weak blocks proportional to their PoW percentage, reflecting transactions they attempt to mine. Weak blocks resist abuse due to high creation costs, allowing mempools and caches to be updated without allowing excessive bandwidth waste. This could ensure compact block relay remains effective even when miners include non-standard transactions in blocks. Weak blocks could also address pinning attacks and enhance feerate estimation. Sanders’s proof-of-concept implementation demonstrates the idea.

Jameson Lopp started a discussion in April about problems with the current public Bitcoin testnet (testnet3) and suggested restarting it, potentially with a different set of special-case consensus rules. In May, Fabian Jahr announced a draft BIP and proposed implementation for testnet4. The BIP and Bitcoin Core implementation were merged in August.

April came to an unfortunate close with news of the arrest of two Bitcoin developers focused on privacy software, along with at least two other companies announcing their intention to stop serving U.S. customers due to the legal risks.

Summary 2024: Cluster mempool

An idea for a mempool redesign from 2023 became a particular focus for several Bitcoin Core developers throughout 2024. Cluster mempool makes it much easier to reason about the effect of transactions on all the blocks a miner would create if it has an identical mempool to the local node’s mempool. This can make transaction eviction more rational and help in determining whether a replacement transaction (or set of transactions) is better than the transactions it replaces. This can help address various mempool limitations that are implicated in multiple problems affecting contract protocols such as LN (including sometimes putting funds at risk).

Additionally, as seen in a January post by Abubakar Sadiq Ismail, the tools and insights from the design of cluster mempool may allow improving fee estimation in Bitcoin Core. Today, Bitcoin Core implements ancestor feerate mining as an incentive compatible way to support CPFP fee-bumping, but fee estimation operates on individual transactions, so CPFP fee bumps aren’t considered. Cluster mempool divides groups of transactions into chunks that can be tracked together in the mempool and then potentially located within mined blocks, allowing improved fee estimation (especially if there is an increased use of CPFP-related technology like package relay, P2A, and exogenous fee sourcing.

As the cluster mempool project matured, multiple explanations and overviews were made by its architects. Suhas Daftuar gave an overview in January, which revealed one of the challenges of the proposal: its incompatibility with the existing CPFP carve-out policy. A solution to the dilemma would be for existing users of carve-out to opt in to TRUC transactions, which provides an improved feature set. Another detailed description of cluster mempool was posted in July by Pieter Wuille. It described fundamental principles, proposed algorithms, and linked to several pull requests. Several of those pull requests and others were subsequently merged.

Daftuar engaged in further thinking and research behind cluster mempool and related proposals like TRUC transactions. In February, he considered incentive compatibility of ideas such as replace-by-feerate, the differing incentives of miners with disproportionate amounts of hashrate, and looked for incentive compatible behavior that wasn’t DoS resistant. In April, he researched what would have happened if cluster mempool had been deployed a year earlier, finding that it allowed slightly more transactions into the mempool, didn’t significantly affect transaction replacement in the data, and may help miners to capture more fees in the short term. Pieter Wuille built on the final point in August by describing principles and an efficient algorithm for nearly optimal transaction selection for miners building blocks.

May

Work continued this year on making silent payments more broadly accessible. Josie Baker started a discussion about PSBT extensions for silent payments (SPs), based on a draft specification by Andrew Toth. That discussion continued into June with an examination of using ECDH shares for trustless coordination. Separately, Setor Blagogee posted a draft specification for a protocol to help lightweight clients receive silent payments. A few tweaks were made to the base SP specification in June and two draft BIPs for the proposed PSBT features were posted.

Sergio Demian Lerner and several co-authors published a paper about a new virtual CPU architecture based in part on the ideas behind BitVM. The goal of their project, BitVMX, is to be able to efficiently prove the proper execution of any program that can be compiled to run on an established CPU architecture, such as RISC-V. Like BitVM, BitVMX does not require any consensus changes, but it does require one or more designated parties to act as a trusted verifier. That means multiple users interactively participating in a contract protocol can prevent any one (or more) of the parties from withdrawing money from the contract unless that party successfully executes an arbitrary program specified by the contract.

Adam Gibson described an anonymous usage token scheme he developed to allow anyone who can keypath-spend a UTXO to prove they could spend it without revealing which UTXO it is. One use he highlights is allowing LN channels to be announced without requiring owners identify the specific UTXOs backing those channels, which is required now to prevent bandwidth-wasting denial-of-service attacks. Gibson also created a proof-of-concept forum that requires providing an anonymous proof to sign up—creating an environment where everyone is known to be a holder of bitcoins but no one needs to provide any identifying information about themselves or their bitcoins. Later in the year, Johan Halseth announced a proof-of-concept implementation that accomplishes most of the same goals using a different mechanism.

For years, LN developers have discussed modifying the LN protocol to allow existing channels to be upgraded in various ways. In May, Carla Kirk-Cohen examined some of these cases and compared three different proposals for upgrades. A quiescence protocol was added to the LN specification in June to help support upgrades and other sensitive operations. October saw renewed development of a proposed updated channel announcements protocol that would support new taproot-based funding transactions.

Ethan Tuttle posted to Delving Bitcoin to suggest that mining pools could reward miners with ecash tokens proportionate to the number of shares they mined. The miners could then immediately sell or transfer the tokens, or they could wait for the pool to mine a block, at which point the pool would exchange the tokens for satoshis. However, a concern was raised by Matt Corallo that there are no standardized payment methods implemented by large pools that allow pool miners to calculate how much they’re supposed to be paid over short intervals. This means miners won’t quickly switch to a different pool if their main pool begins cheating them of payments, whether those payments are made with ecash or any other mechanism.

Ava Chow proposed a BIP for miniscript in May, which became BIP379 in July.

Also in May, a beta release of utreexod was published, allowing users to experiment with this full node design that minimizes disk space requirements.

June

René Pickhardt researched estimating the likelihood of LN payment feasibility by analyzing possible wealth distributions within channel capacities. For example, if Alice wants to send 1 BTC to Carol via Bob, the likelihood of success depends on whether the Alice-Bob and Bob-Carol channels can support the transfer. This metric highlights practical payment constraints and could help wallets and business software make smarter routing decisions, improving success rates for LN payments. Later in the year, Pickhardt’s research provided insights into the cause and likelihood of channel depletion—a channel becoming unable to forward funds in a particular direction. It also pointed to k>2 multiparty channel management protocols, such as channel factories, being able to greatly increase the number of feasible payments and reduce the rate of channel depletion.

Example of channel depletion

Developer Hunter Beast posted a “rough draft” BIP for assigning version 3 segwit addresses to a quantum-resistant signature algorithm. The draft BIP describes the problem and links to several potential algorithms along with their expected onchain size. The choice of algorithms and the specific implementation details was left for future discussion.

Summary 2024: P2P transaction relay

Fee management has always been a challenge in the decentralized Bitcoin protocol, but widespread use of contract protocols such as LN-Penalty and ongoing research into newer and more complex protocols has made it more important than ever to ensure users can pay and increase fees on demand. Bitcoin Core contributors have been working on this problem for years, and 2024 saw the public release of several new features that significantly improve the situation.

January began with a discussion of the worst-case pinning costs for the TRUC proposal that provides a more robust alternative to the previously deployed CPFP carve-out policy. Although the worst-case costs are much lower for TRUC, developers considered whether tweaking a few parameters might be able to lower costs further. Another discussion in January examined the theoretical risk that increased use of exogenous fee sourcing would make it more efficient onchain (and thus cheaper) to use out-of-band fee payments to miners, which puts mining decentralization at risk. Peter Todd suggested addressing this concern with an alternative fee management method: keep fees entirely endogenous by presigning multiple variations of each settlement transaction at varying feerates. However, multiple problems were identified with this approach.

Additional discussion in January by Gregory Sanders looked at whether there was any risk of the LN protocol putting trimmed HTLC value into P2A outputs, which would potentially allow miner extractable value (MEV) for miners who ran special software beyond what was necessary to mine mempool transactions. Bastien Teinturier started a discussion about what changes would be necessary to the LN protocol to handle commitment transactions that used TRUC and P2A outputs; this included the trimmed HTLC proposal considered by Sanders, eliminating no-longer-necessary one-block delays, and a reduction in onchain transaction size. The discussion also led to an imbued TRUC proposal that would automatically apply TRUC rules to transactions that looked like LN’s existing use of CPFP carve-out, providing the benefits of TRUC without LN software needing to be upgraded.

January came to an end with a proposal by Gloria Zhao for sibling replace by fee. The normal RBF rules only apply to conflicting transactions where a node accepts just one version of the transaction into its mempool because only one version is permitted to exist in a valid blockchain. However, with TRUC, a node accepts only one descendant of an unconfirmed version 3 parent transaction, a very similar situation to a conflicting transaction. Allowing one descendant to replace another descendant of the same transaction—i.e., sibling eviction—would improve fee-bumping of TRUC transaction and be especially beneficial if imbued TRUC is adopted.

February began with additional discussions of the consequences of moving the LN protocol from CPFP carve-out to TRUC. Matt Corallo found challenges in adapting existing zero-conf channel opens to using TRUC due to both the funding transaction and an immediate close transaction potentially being unconfirmed, preventing a third transaction containing a CPFP fee bump from being used due to TRUC’s limit of two unconfirmed transactions. Teinturier identified a similar problem if a chain of splices was used. The discussion never reached a clear conclusion, but a workaround solution of ensuring each transaction contained its own anchor for CPFP fee-bumping (as is required before TRUC) seemed satisfactory, with everyone hoping that cluster mempool could allow relaxing some TRUC rules in the future to allow more flexible CPFP fee-bumping.

On the topic of TRUC policy changes powered by cluster mempool advancements, Gregory Sanders described several ideas for future policy changes. By contrast, Suhas Daftuar analyzed all transactions received by his node from the prior year to see how an imbued TRUC policy would have affected the acceptance of those transactions. Most transactions previously accepted under the CPFP carve-out policy would also have been accepted under an imbued TRUC policy, but there were a few exceptions that might require changes to software before an imbued policy could be adopted.

After the flurry of discussion early in the year, May and June saw a series of merges adding support for new relay features to Bitcoin Core. A limited form of one-parent-one-child (1p1c) package relay not requiring any changes to the P2P protocol was added. A subsequent merge increased the reliability of 1p1c package relay by enhancing Bitcoin Core’s orphan transaction handling. The specification for TRUC was merged into the BIPs repository as BIP431. TRUC transactions became relayable by default with another merge. Support was also added for RBF of 1p1c clusters (including TRUC packages).

Two long-term developers wrote extended criticisms of TRUC in July, although other developers responded to their concerns. Further criticism by the same two developers was published in August.

Bitcoin Core developers continued working on relay improvements, merging support for pay-to-anchors (P2A) in August and releasing Bitcoin Core 28.0 in October with support for 1p1c package relay, TRUC transaction relay, package RBF and sibling replacement, and a standard P2A output script type. Gregory Sanders, who contributed to the development of all those features, described how developers of wallets and other software that uses Bitcoin Core to create or broadcast transactions can take advantage of the new capabilities.

Later in the year, support for ephemeral dust outputs using P2A were made standard in a merge. This allows a transaction paying zero fee to be bumped by a child transaction paying all the relevant fee—a purely exogenous type of fee sourcing.

Optech’s final regular newsletter for the year summarized a Bitcoin Core Pull Request Review Club meeting that discussed further improvements for 1p1c package relay.

July

Elle Mouton proposed a BLIP to add a blinded path field to BOLT11 invoices, allowing payment recipients to hide their node identity and channel peers. For example, Bob could add a blinded path to his invoice, enabling Alice to pay privately if her software supports it; otherwise, she would receive an error. Mouton sees this as a temporary solution until offers, which natively support blinded paths, are widely adopted. The proposal became BLIP39 in August.

Tim Ruffing and Jonas Nick proposed ChillDKG, a BIP draft and reference implementation for securely generating keys for FROST-style scriptless threshold signatures compatible with Bitcoin’s schnorr signatures. ChillDKG combines a well-known key generation algorithm for FROST with modern cryptographic primitives to securely share random key components among participants while ensuring integrity and non-censorship. It uses elliptic curve Diffie-Hellman (ECDH) for encryption and authenticated broadcast for verifying signed session transcripts. Participants confirm session integrity before accepting the final public key. This protocol simplifies key management, requiring users to back up only their private seed and some non-sensitive recovery data. Plans to encrypt recovery data using the seed aim to enhance privacy and further simplify user backups.

July saw the merge of several BIPs that will help different software interact to create MuSig2 signatures. Later in the month, Sivaram Dhakshinamoorthy announced a proposed BIP for creating scriptless threshold signatures for Bitcoin’s implementation of schnorr signatures. This allows a set of signers that have already performed a setup procedure (e.g. using ChillDKG) to securely create signatures that only require interaction from a dynamic subset of those signers. The signatures are indistinguishable onchain from schnorr signatures created by single-sig users and scriptless multisignature users, improving privacy and fungibility.

August

Sergi Delgado released Hyperion, a network simulator that tracks how data propagates through a simulated Bitcoin network. The work is initially motivated by a desire to compare Bitcoin’s current method for relaying transaction announcements with the proposed Erlay method.

Developer 0xB10C investigated the recent reliability of compact block reconstruction. Sometimes new blocks include transactions that a node has not seen before. In that case, the node receiving a compact block usually needs to request those transactions from the sending peer and then wait for the peer to respond. This slows down block propagation. The research helped motivate consideration of a pull request to enable mempoolfullrbf by default in Bitcoin Core, which was later merged.

2024 summary: Covenants and script upgrades

Several developers devoted much of their time in 2024 towards advancing proposals for covenants, scripting upgrades, and other changes that would support advanced contract protocols such as joinpools and channel factories.

In late December 2023, Johan Torås Halseth announced a proof of concept program that can use the OP_CHECKCONTRACTVERIFY opcode from the MATT soft fork proposal to allow a party in a contract protocol to claim money if an arbitrary program executed successfully. It is similar in concept to BitVM but simpler in its Bitcoin implementation due to using an opcode specifically designed for program execution verification. Elftrace works with programs compiled for the RISC-V architecture using Linux’s ELF format; almost any programmer can easily create programs for that target, making using elftrace highly accessible. Halseth provided an update on Elftrace in August when it gained the ability to verify zero-knowledge proofs in combination with the OP_CAT opcode.

January saw the announcement of the LNHANCE combination soft fork proposal that includes previous proposals for OP_CHECKTEMPLATEVERIFY (CTV) and OP_CHECKSIGFROMSTACK (CSFS) along with a new proposal for an OP_INTERNALKEY that places the taproot internal key on the stack. Later in the year, the proposal would be updated to also include an OP_PAIRCOMMIT opcode that provides a capability that’s similar to OP_CAT but deliberately limited in its composability. The proposal aims to allow the deployment of LN-Symmetry, Ark-style joinpools, reduced-signature DLCs, and vaults, among other described benefits of the underlying proposals, such as CTV-style congestion control and CSFS-style signature delegation.

Chris Stewart posted a draft BIP for enabling 64-bit arithmetic operations in Bitcoin Script in a future soft fork. Bitcoin currently only allows 32-bit operations (using signed integers, so numbers over about 2 billion can’t be used). Support for 64-bit values would be especially useful in any construction that needs to operate on the number of satoshis paid in an output, as that is specified using a 64-bit integer. The proposal received additional discussion in both February and June.

Also in February, developer Rijndael created a proof-of-concept implementation for a vault that only depends on the current consensus rules plus the proposed OP_CAT opcode. Optech compared the OP_CAT vault against vaults possible today with presigned transactions and vaults possible if BIP345 OP_VAULT was added to Bitcoin.

Presigned BIP345 OP_VAULT OP_CAT with schnorr
Availability Now Requires soft fork of OP_VAULT and OP_CTV Requires soft fork of OP_CAT
Last-minute address replacement attack Vulnerable Not vulnerable Not vulnerable
Partial amount withdrawals Only if prearranged Yes No
Static and non-interactive computable deposit addresses No Yes Yes
Batched re-vaulting/quarantining for fee savings No Yes No
Operational efficiency in best case, i.e. only legitimate spends
(only very roughly estimated by Optech) 		2x size of regular single-sig 3x size of regular single-sig 4x size of regular single-sig

In March, developer ZmnSCPxj described a protocol for giving control over a UTXO to a party that correctly predicts whether or not a particular soft fork will activate. Others have proposed this basic idea before but ZmnSCPxj’s version deals with the specifics expected for at least one potential future soft fork, OP_CHECKTEMPLATEVERIFY.

March also saw Anthony Towns begin working on an alternative scripting language for Bitcoin based on the Lisp language. He provided an overview of the Lisp-style language already used by the Chia altcoin and proposed a BTC Lisp language. Later in the year, inspired by the relationship between Bitcoin Script and miniscript, he split his Lisp project into two parts: a low-level bitcoin lisp language (bll) that could be added to Bitcoin in a soft fork and a symbolic bll (symbll) high-level language that is converted into bll. He also described a generic construction compatible with symbll (and probably Simplicity) that allows partitioning a UTXO into specific amounts and spending conditions. He showed how these flexible coin earmarks can be used, including improvements in the security and usability of LN channels (including LN-Symmetry-based channels), an alternative to the BIP345 version of vaults, and a payment pool design.

Jeremy Rubin proposed two updates to the OP_CHECKTEMPLATEVERIFY design in May: optional support for a shorter hash digest and support for additional commitments. These helped optimize CTV for use in data publication schemes that might be useful for recovering critical data in LN-Symmetry and similar protocols.

Pierre Rochard asked if proposed soft forks that can provide many of the same features at a similar cost should be considered mutually exclusive, or whether it would make sense to activate multiple proposals and let developers use whichever alternative they prefer.

Jeremy Rubin published a paper about theoretically using functional encryption to add a full range of covenant behavior to Bitcoin with no required consensus changes. In essence, functional encryption would allow the creation of a public key that would correspond to a particular program. A party who could satisfy the program would be able to create a signature that corresponded to the public key (without ever learning a corresponding private key). This is always more private and will often save space compared to previously proposed covenants. Unfortunately, a major downside of functional encryption, according to Rubin, is that it is “under-developed cryptography that makes it impractical to use presently”.

Anthony Towns posted a script for signet that uses OP_CAT to allow anyone to spend coins sent to the script using proof of work (PoW). This can be used as a decentralized signet-bitcoin faucet: when a miner or a user obtains excess signet bitcoins, they send them to the script. When a user wants more signet bitcoins, they search the UTXO set for payments to the script, generate PoW, and create a transaction that uses their PoW to claim the coins.

Victor Kolobov announced a $1 million fund for research into a proposed soft fork to add an OP_CAT opcode. Submissions must be received by 1 January 2025.

In November, Towns summarized activity on the default signet related to proposed soft forks available through Bitcoin Inquisition. Vojtěch Strnad was inspired by Towns’s post and created a website that lists “every transaction made on the Bitcoin signet that uses one of the deployed soft forks.”

Ethan Heilman posted a paper he coauthored with Victor Kolobov, Avihu Levy, and Andrew Poelstra about how covenants can be created easily without consensus changes, although spending from those covenants would require non-standard transactions and millions (or billions) of dollars worth of specialized hardware and electricity. Heilman notes that one application of the work is allowing users today to easily include a backup taproot spending path that can be securely used if quantum resistance is suddenly needed and elliptic curve signature operations on Bitcoin are disabled. The work appeared to be inspired in part by several of the authors’ previous research into lamport signatures for Bitcoin.

December concluded with a poll of developer opinions about selected covenant proposals.

Starting in January 2025, Optech will begin summarizing notable research and developments related to covenants, script upgrades, and related changes in a special section published in the first newsletter of each month. We encourage everyone working on these proposals to publish anything of interest to our usual sources so that we can write about it.

September

Carla Kirk-Cohen described testing and adjustments to a hybrid channel jamming mitigation originally proposed by Clara Shikhelman and Sergei Tikhomirov. Attempts to jam a channel for an hour mostly failed, as attackers either spent more than using known attacks or unintentionally increased the target’s income. However, a sink attack effectively undermined a node’s reputation by sabotaging payments through shorter routes. To counter this, bidirectional reputation was added to HTLC endorsement, bringing the proposal closer to an idea originally proposed in 2018 by Jim Posen. Nodes now assess both the sender’s and receiver’s reliability when deciding to forward payments. Reliable nodes receive endorsed HTLCs, while less reliable senders or receivers face rejection or non-endorsed forwarding. This testing followed a specification of HTLC endorsement and an implementation in Eclair. An implementation for LND was also be added shortly before the end of the year.

Jonas Nick, Liam Eagen, and Robin Linus introduced a new client-side validation (CSV) protocol, Shielded CSV, which enables token transfers secured by Bitcoin’s proof-of-work without revealing token details or transfer histories. Unlike existing protocols, where clients must validate extensive token histories, Shielded CSV uses zero-knowledge proofs to ensure verification requires fixed resources while preserving privacy. Additionally, Shielded CSV reduces on-chain data requirements by bundling thousands of token transfers into a single 64-byte update per Bitcoin transaction, enhancing scalability. The paper explores trustless Bitcoin-to-CSV bridging via BitVM, account-based structures, handling blockchain reorganizations, unconfirmed transactions, and potential extensions. This protocol promises significant efficiency and privacy improvements over other token systems.

Andy Schroder outlined a process for enabling LN offline payments by generating authentication tokens while online, allowing the spender’s wallet to authorize payments through their always-online node or LSP when offline. Tokens can be transferred to the receiver via NFC or other simple protocols, enabling payments without internet access. Developer ZmnSCPxj proposed an alternative, and Bastien Teinturier referenced his remote node control method for similar use cases, enhancing offline payment solutions for limited-resource devices like smart cards.

October

The BOLT12 specification of offers was merged. Initially proposed in 2019, offers allows two nodes to negotiate invoices and payments over LN using onion messages. Both onion messages and offer-compatible payments can use blinded paths to prevent the spender from learning the identity of the receiver’s node.

A new mining interface for Bitcoin Core saw development with the goal of supporting miners using the Stratum v2 protocol that can be set to allow each miner to select their own transactions. However, Anthony Towns noted earlier in the year that independent transaction selection could raise share validation costs for mining pools. If those pools responded by limiting validation, it could allow an invalid shares attack that’s similar to the well-known block withholding attack. A 2011 proposed solution to withholding attacks was discussed, although it would require a challenging consensus change.

November

ZmnSCPxj proposed the SuperScalar design for a channel factory using timeout trees to enable LN users to open channels and access liquidity more affordably while maintaining trustlessness. The design uses a layered timeout tree that requires the service provider to pay any costs of putting the tree onchain or lose any funds remaining in the tree. This encourages the service provider to incentivize users to cooperatively close their channels to avoid the need to go onchain. The design uses both duplex micropayment channels and LN-Penalty payment channels, both of which are possible without any consensus changes. Despite its complexity—combining multiple channel types and managing offchain state—the design can be implemented by a single vendor without requiring large protocol changes. To support the design, ZmnSCPxj later proposed a pluggable channel factory tweak to the LN specification.

John Law proposed an offchain payment resolution (OPR) micropayment protocol that requires both participants to contribute funds to a bond that can be effectively destroyed at any time by either participant. This creates an incentive for both parties to appease the other or risk mutually assured destruction (MAD) of the bonded funds. The protocol isn’t trustless, but it is more scalable than alternatives, provides fast resolution, and doesn’t force parties to publish data onchain before timelocks expire. This can make OPR much more efficient inside a channel factory, timeout tree, or other nested structure that would ideally keep the nested portions offchain.

Summary 2024: Bitcoin Optech

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

Each newsletter and blog post was translated into Chinese, Czech, French, and Japanese, totaling over 200 translations in 2024.

In addition, every newsletter this year was accompanied by a podcast episode, totaling over 59 hours in audio form and 488,000 words in transcript form. Many of Bitcoin’s top contributors were guests on the show—some of them on more than one episode—with a total of 75 different unique guests in 2024:

  • Abubakar Sadiq Ismail (x2)
  • Adam Gibson
  • Alex Bosworth
  • Andrew Toth (x3)
  • Andy Schroder
  • Anthony Towns (x5)
  • Antoine Poinsot (x5)
  • Antoine Riard (x2)
  • Armin Sabouri
  • Bastien Teinturier (x4)
  • Bob McElrath
  • Brandon Black (x3)
  • Bruno Garcia
  • callebtc
  • Calvin Kim
  • Chris Stewart (x3)
  • Christian Decker
  • Dave Harding (x3)
  • David Gumberg
  • /dev/fd0
  • Dusty Daemon
  • Elle Mouton (x2)
  • Eric Voskuil
  • Ethan Heilman (x2)
  • Eugene Siegel
  • Fabian Jahr (x5)
  • Filippo Merli
  • Gloria Zhao (x10)
  • Gregory Sanders (x7)
  • Hennadii Stepanov
  • Hunter Beast
  • Jameson Lopp (x2)
  • Jason Hughes
  • Jay Beddict
  • Jeffrey Czyz
  • Johan Torås Halseth
  • Jonas Nick (x2)
  • Joost Jager
  • Josie Baker
  • Kulpreet Singh
  • Lorenzo Bonazzi
  • Luke Dashjr
  • Matt Corallo (x3)
  • Moonsettler (x2)
  • Nicholas Gregory
  • Niklas Gögge (x2)
  • Oghenovo Usiwoma
  • Olaoluwa Osuntokun
  • Oliver Gugger
  • Peter Todd
  • Pierre Corbin
  • Pierre Rochard
  • Pieter Wuille
  • René Pickhardt (x2)
  • Richard Myers
  • Rijndael
  • rkrux
  • Russell O’Connor
  • Salvatore Ingala (x2)
  • Sebastian Falbesoner
  • SeedHammer Team
  • Sergi Delgado
  • Setor Blagogee
  • Shehzan Maredia
  • Sivaram Dhakshinamoorthy
  • Stéphan Vuylsteke
  • Steven Roose
  • Tadge Dryja
  • TheCharlatan
  • Tom Trevethan
  • Tony Klausing
  • Valentine Wallace
  • Virtu
  • Vojtěch Strnad (x2)
  • ZmnSCPxj (x3)

Optech was the fortunate and grateful recipient of a $20,000 USD contribution to our work from the Human Rights Foundation. The funds will be used to pay for web hosting, email services, podcast transcriptions, and other expenses that allow us to continue and improve our delivery of technical content to the Bitcoin community.

December

December saw the continuation of several discussions and the announcements of multiple vulnerabilities, all which were summarized earlier in this newsletter.

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 Friday publication schedule on January 3rd.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 15:30 UTC on December 23. The discussion is also recorded and will be available from our podcasts page.