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

  • ● Recent OP_RETURN output statistics: Anthony Towns posted to Delving 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 on X and a dashboard of OP_RETURN statistics, and that orangesurf published a report on OP_RETURN for mempool research.

  • ● Bitcoin PIPEs v2: Misha Komarov posted 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, all the conditional logic is processed off-chain.

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

    • ● Setup: A standard Bitcoin keypair (sk, pk) is generated. sk is then encrypted behind a spending condition statement using witness encryption.

    • ● 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 semantics. In particular, Bitcoin PIPEs v2 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 protocol.

Changes to services and client software

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

  • ● Second releases hArk-based Ark software: Second’s Ark libraries were updated to use hArk, hash-lock Ark, in version 0.1.0-beta.6. 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.

  • ● Amboss announces RailsX: The RailsX announcement outlines a platform using LN and Taproot Assets to support swaps and various other financial services.

  • ● Nunchuk adds silent payment support: Nunchuk announced support for sending to silent payment addresses.

  • ● Electrum adds submarine swap features: Electrum 4.7.0 allows users to pay onchain using their Lightning balance (see submarine swaps), among other features and fixes.

  • ● Sigbash v2 announced: Sigbash v2 now uses MuSig2, WebAssembly (WASM), and zero-knowledge proofs to achieve better cosigning-service privacy. See our previous coverage 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.

  • ● BTCPay Server 2.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.

  • ● LND 0.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

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #33965 fixes a bug where the -blockreservedweight startup config (see Newsletter #342) could silently override the block_reserved_weight value set by Mining IPC clients (see Newsletter #310). 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.

  • ● Eclair #3248 starts prioritizing private channels over public ones when forwarding HTLCs, 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.

  • ● Eclair #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. Channel lifecycle events now include the commitmentFormat to describe the channel type, and PaymentRelayed adds a relayFee field.

  • ● LDK #4335 adds initial support for phantom node payments (see Newsletter #188) using BOLT12 offers. In the BOLT11 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. In BOLT12, the offer simply includes multiple blinded paths 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.

  • ● LDK #4318 removes the max_funding_satoshis field from the ChannelHandshakeLimits struct, effectively eliminating the pre-wumbo default channel size limit. LDK was already advertising support for 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.

  • ● LND #10542 extends the graph database layer to support gossip v1.75 (see Newsletters #261 and #326). LND can now store and retrieve channel announcements for simple taproot channels. Gossip v1.75 remains disabled at the network level, pending the completion of the validation and gossiper subsystems.

  • ● BIPs #1670 publishes BIP360, which specifies Pay-to-Merkle-Root (P2MR), a new output type that operates like P2TR 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 signature proposal. See Newsletter #344 for earlier coverage when the proposal was known as P2QRH and Newsletter #385 when the proposal was known as P2TSH.

  • ● BOLTs #1236 updates the dual funding specification to allow either node to send tx_init_rbf during channel establishment, effectively allowing both parties to fee bump the funding transaction. Previously, only the channel initiator could do so. This change aligns dual funding with 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.

  • ● BOLTs #1289 changes how commitment_signed is retransmitted during reconnection in the interactive transaction protocol used by both dual funding and 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 where retransmitting would require a full MuSig2 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 at 17:30 UTC on February 24. The discussion is also recorded and will be available from our podcasts page.