Bitcoin Optech Newsletter #393

By Bitcoin Optech February 20, 2026 · Edited February 20, 2026

This week’s newsletter summarizes a discussion about recent OP_RETURN usage and describes a protocol to enforce covenant-like spending conditions without consensus changes. Also included are our

This week’s newsletter summarizes a discussion about recent OP_RETURN usage and describes a protocol to enforce covenant-like spending conditions without consensus changes. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing recent merges to popular Bitcoin infrastructure software.

News

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#recent-op-return-output-statistics) Recent OP_RETURN output statistics: Anthony Towns posted to Delving (https://delvingbitcoin.org/t/recent-op-return-output-statistics/2248) about the recent OP_RETURN statistics since the release of Bitcoin Core v30.0 on October 10, which included changes to the mempool policy limits for OP_RETURN outputs (allowing multiple OP_RETURN outputs and allowing up to 100kB of data in OP_RETURN outputs). The range of blocks he looked at was heights 915800 to 936000, with the following results:

  • 
    24,362,310 txs with OP_RETURN outputs

  

  • 
    61 txs with multiple OP_RETURN outputs

  

  • 
    396 txs with total OP_RETURN output script sizes greater than 83 bytes

  

  • 
    Total OP_RETURN output script data over the period was 473,815,552 bytes (of

which large OP_RETURNS accounted for 0.44%)

  • 
    There are 34,283 txs burning sats to OP_RETURN outputs, for a total of

1,463,488 sats burnt

  • 
    There are 949,003 txs with between 43 and 83 bytes of OP_RETURN data, and

23,412,911 txs with OP_RETURN data of 42 bytes or less

Towns also included a chart showing the frequency of sizes for the 396

transactions with large OP_RETURN outputs. 50% of these transactions had less than 210 bytes of OP_RETURN data. Also, 10% had more than 10KB of OP_RETURN data.

He later added that Murch subsequently published a similar analysis (https://x.com/murchandamus/status/2022930707820269670) on

X and a dashboard (https://dune.com/murchandamus/opreturn-counts) of OP_RETURN statistics, and that orangesurf published a report (https://research.mempool.space/opreturn-report/) on OP_RETURN for mempool research.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#bitcoin-pipes-v2) Bitcoin PIPEs v2: Misha Komarov posted (https://delvingbitcoin.org/t/bitcoin-pipes-v2/2249) to Delving Bitcoin about Bitcoin PIPEs, a protocol that allows enforcement of spending conditions without the need for consensus changes or optimistic challenge mechanisms.

The Bitcoin protocol is based on a minimal transaction validation model, which

consists of verifying that a UTXO being spent is authorized by a valid digital signature. Thus, instead of relying on spending conditions expressed by Bitcoin Script, Bitcoin PIPEs adds prerequisites on whether a valid signature can be produced or not. In other words, a private key is cryptographically locked behind a predetermined condition. If and only if the condition is fulfilled, the private key is revealed, allowing for a valid signature. While the Bitcoin protocol only has to validate a single schnorr signature (https://bitcoinops.org/en/topics/schnorr-signatures/), all the conditional logic is processed off-chain.

On a formal level, Bitcoin PIPEs consists of two main phases:



  • 
    ● (https://bitcoinops.org/en/newsletters/2026/02/20/#setup) Setup: A standard Bitcoin keypair (sk, pk) is generated. sk is then

encrypted behind a spending condition statement using witness encryption.

  • 
    ● (https://bitcoinops.org/en/newsletters/2026/02/20/#signing) Signing: A witness w is provided for the statement. If w is valid, sk is

revealed and a schnorr signature can be produced. Otherwise, recovering sk becomes computationally infeasible.

According to Komarov, Bitcoin PIPEs can be used to reproduce covenant (https://bitcoinops.org/en/topics/covenants/) semantics. In

particular, Bitcoin PIPEs v2 (https://eprint.iacr.org/2026/186) focuses on a limited set of spending conditions, enforcing binary covenants. This model naturally captures a wide range of useful conditions whose outcomes are binary, such as providing a valid zk-proof, satisfying an exit condition, or existence of a fraud proof. Basically, it all comes down to a single question: “Is the condition satisfied or not?”.

Finally, Komarov provided real-world examples of how PIPEs could be leveraged instead

of new opcodes, and how it could be used to improve the optimistic verification flow of the BitVM (https://bitcoinops.org/en/topics/acc/) protocol.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#second-releases-hark-based-ark-software) Second releases hArk-based Ark software: Second’s Ark (https://bitcoinops.org/en/topics/ark/) libraries were updated to use hArk, hash-lock Ark, in version 0.1.0-beta.6 (https://docs.second.tech/changelog/changelog/#010-beta6). The new protocol eliminates the synchronous interactivity requirement for users during rounds, with its own set of tradeoffs. The release includes various other updates, including breaking changes.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#amboss-announces-railsx) Amboss announces RailsX: The RailsX announcement (https://amboss.tech/blog/railsx-first-lightning-native-dex) outlines a platform using LN and Taproot Assets (https://bitcoinops.org/en/topics/client-side-validation/) to support swaps and various other financial services.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#nunchuk-adds-silent-payment-support) Nunchuk adds silent payment support: Nunchuk announced (https://x.com/nunchuk_io/status/2021588854969414119) support for sending to silent payment (https://bitcoinops.org/en/topics/silent-payments/) addresses.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#electrum-adds-submarine-swap-features) Electrum adds submarine swap features: Electrum 4.7.0 (https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES) allows users to pay onchain using their Lightning balance (see submarine swaps (https://bitcoinops.org/en/topics/submarine-swaps/)), among other features and fixes.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#sigbash-v2-announced) Sigbash v2 announced: Sigbash v2 (https://x.com/arbedout/status/2020885323778044259) now uses MuSig2 (https://bitcoinops.org/en/topics/musig/), WebAssembly (WASM), and zero-knowledge proofs to achieve better cosigning-service privacy. See our previous coverage (https://bitcoinops.org/en/newsletters/2024/04/17/#key-agent-sigbash-launches) on Sigbash for more.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#btcpay-server-2-3-5) BTCPay Server 2.3.5 (https://github.com/btcpayserver/btcpayserver/releases/tag/v2.3.5) is a minor release of this self-hosted payment solution that adds multi-crypto wallet balance widgets on the dashboard, a custom textbox for checkout, new exchange rate providers, and includes several bug fixes.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#lnd-0-20-1-beta) LND 0.20.1-beta (https://github.com/lightningnetwork/lnd/releases/tag/v0.20.1-beta) is a maintenance release of this popular LN node implementation, which adds a panic recovery for gossip message processing, improves reorg protection, implements LSP detection heuristics, and fixes multiple bugs and race conditions.

Notable code and documentation changes

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#bitcoin-core-33965) Bitcoin Core #33965 (https://github.com/bitcoin/bitcoin/issues/33965) fixes a bug where the -blockreservedweight startup config (see Newsletter #342 (https://bitcoinops.org/en/newsletters/2025/02/21/#bitcoin-core-31384)) could silently override the block_reserved_weight value set by Mining IPC clients (see Newsletter #310 (https://bitcoinops.org/en/newsletters/2024/07/05/#bitcoin-core-30200)). Now, when an IPC caller sets the latter, it takes precedence. For RPC callers who never set this value, the startup config -blockreservedweight always takes effect. This PR also enforces the MINIMUM_BLOCK_RESERVED_WEIGHT for IPC callers, preventing them from setting a value below it.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#eclair-3248) Eclair #3248 (https://github.com/ACINQ/eclair/issues/3248) starts prioritizing private channels over public ones when forwarding HTLCs (https://bitcoinops.org/en/topics/htlc/), if both options are available. This keeps more liquidity available in public channels, which are visible to the network. When two channels have the same visibility, Eclair now prioritizes the channel with the smaller balance.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#eclair-3246) Eclair #3246 (https://github.com/ACINQ/eclair/issues/3246) adds new fields to several internal events: TransactionPublished splits the single miningFee field into localMiningFee and remoteMiningFee, adds a computed feerate and an optional LiquidityAds.PurchaseBasicInfo linking the transaction to a liquidity purchase (https://bitcoinops.org/en/topics/liquidity-advertisements/). Channel lifecycle events now include the commitmentFormat to describe the channel type, and PaymentRelayed adds a relayFee field.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#ldk-4335) LDK #4335 (https://github.com/lightningdevkit/rust-lightning/issues/4335) adds initial support for phantom node payments (see Newsletter #188 (https://bitcoinops.org/en/newsletters/2022/02/23/#ldk-1199)) using BOLT12 offers (https://bitcoinops.org/en/topics/offers/). In the BOLT11 (https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) version, invoices included route hints pointing to a non-existent “phantom” node, with each path’s last hop being a real node that could accept the payment using stateless invoices (https://bitcoinops.org/en/topics/stateless-invoices/). In BOLT12 (https://github.com/lightning/bolts/blob/master/12-offer-encoding.md), the offer simply includes multiple blinded paths (https://bitcoinops.org/en/topics/rendez-vous-routing/) terminating at each participating node. The current implementation allows multiple nodes to respond to the invoice request, though the resulting invoice can only be paid to the responding node.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#ldk-4318) LDK #4318 (https://github.com/lightningdevkit/rust-lightning/issues/4318) removes the max_funding_satoshis field from the ChannelHandshakeLimits struct, effectively eliminating the pre-wumbo (https://bitcoinops.org/en/topics/large-channels/) default channel size limit. LDK was already advertising support for large channels (https://bitcoinops.org/en/topics/large-channels/) via the option_support_large_channels feature flag by default, which could have incorrectly signaled support to peers by conflicting with the former setting. Users who want to limit risk can use the manual channel acceptance flow.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#lnd-10542) LND #10542 (https://github.com/lightningnetwork/lnd/issues/10542) extends the graph database layer to support gossip v1.75 (see Newsletters #261 (https://bitcoinops.org/en/newsletters/2023/07/26/#updated-channel-announcements) and #326 (https://bitcoinops.org/en/newsletters/2024/10/25/#updates-to-the-version-1-75-channel-announcements-proposal)). LND can now store and retrieve channel announcements (https://bitcoinops.org/en/topics/channel-announcements/) for simple taproot channels (https://bitcoinops.org/en/topics/simple-taproot-channels/). Gossip v1.75 remains disabled at the network level, pending the completion of the validation and gossiper subsystems.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#bips-1670) BIPs #1670 (https://github.com/bitcoin/bips/issues/1670) publishes BIP360 (https://github.com/bitcoin/bips/pull/1670), which specifies Pay-to-Merkle-Root (P2MR), a new output type that operates like P2TR (https://bitcoinops.org/en/topics/taproot/) but with the keypath spend removed. P2MR outputs are resistant to long-exposure attacks by cryptographically relevant quantum computers (CRQCs) because they commit directly to the Merkle root of the script tree, a SHA256 hash, rather than a public key. However, protection against short-exposure attacks, such as against private key recovery while a transaction is unconfirmed, requires a separate post-quantum (https://bitcoinops.org/en/topics/quantum-resistance/) signature proposal. See Newsletter #344 (https://bitcoinops.org/en/newsletters/2025/03/07/#update-on-bip360-pay-to-quantum-resistant-hash-p2qrh) for earlier coverage when the proposal was known as P2QRH and Newsletter #385 (https://bitcoinops.org/en/newsletters/2025/12/19/#quantum) when the proposal was known as P2TSH.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#bolts-1236) BOLTs #1236 (https://github.com/lightning/bolts/issues/1236) updates the dual funding (https://bitcoinops.org/en/topics/dual-funding/) specification to allow either node to send tx_init_rbf during channel establishment, effectively allowing both parties to fee bump (https://bitcoinops.org/en/topics/replace-by-fee/) the funding transaction. Previously, only the channel initiator could do so. This change aligns dual funding with splicing (https://bitcoinops.org/en/topics/splicing/), where either side could already initiate an RBF. The PR also adds a requirement that both the senders of tx_init_rbf and tx_ack_rbf must reuse at least one input from a previous attempt, ensuring that the new transaction double-spends all prior attempts.

• ● (https://bitcoinops.org/en/newsletters/2026/02/20/#bolts-1289) BOLTs #1289 (https://github.com/lightning/bolts/issues/1289) changes how commitment_signed is retransmitted during reconnection in the interactive transaction protocol used by both dual funding (https://bitcoinops.org/en/topics/dual-funding/) and splicing (https://bitcoinops.org/en/topics/splicing/). Previously, commitment_signed was always retransmitted on reconnection, even if the peer had already received it. Now, channel_reestablish includes an explicit bitfield that lets a node request commitment_signed only if it still needs it. This avoids unnecessary retransmission, which is especially important for future simple taproot channels (https://bitcoinops.org/en/topics/simple-taproot-channels/) where retransmitting would require a full MuSig2 (https://bitcoinops.org/en/topics/musig/) signing round due to nonce changes.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm (https://riverside.fm/studio/bitcoin-optech) at 17:30 UTC on February 24. The discussion is also recorded and will be available from our podcasts (https://bitcoinops.org/en/podcast/) page.

Reference: https://bitcoinops.org/en/newsletters/2026/02/20/

Write a comment

No comments yet.