This week’s newsletter summarizes continued discussion about probabilistic payments, describes additional opinions about ephemeral anchor scripts for LN, relays statistics about evictions from the Bitcoin Core orphan pool, and announces an updated draft for a revised BIP process. Also included are our regular sections summarizing a Bitcoin Core PR Review Club meeting, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● Continued discussion about probabilistic payments: following Oleksandr Kurbatov’s post to Delving Bitcoin last week about emulating an OP_RAND opcode (see Newsletter #340), several discussions were started:

    • ● Suitability as an alternative to trimmed HTLCs: Dave Harding asked if Kurbatov’s method was suitable for use inside an LN-Penalty or LN-Symmetry payment channel for routing HTLCs that are currently uneconomical, which is currently done using trimmed HTLCs whose value is lost if they’re pending during a channel force closure. Anthony Towns didn’t think that would work with the existing protocol’s roles due to them being the inverse of the corresponding roles used for resolving HTLCs. However, he thought tweaks to the protocol might be able to align it with HTLCs.

    • ● Setup step required: Towns discovered that the originally published protocol was missing a step. Kurbatov concurred.

    • ● Simpler zero-knowledge proofs: Adam Gibson suggested that using schnorr and taproot rather than hashed public keys might significantly simplify and speed up the construction and verification of the required zero-knowledge proof. Towns offered a tentative approach, which Gibson analyzed.

    Discussion was ongoing at the time of writing.

  • ● Continued discussion about ephemeral anchor scripts for LN: Matt Morehouse replied to the thread about what ephemeral anchor script LN should use for future channels (see Newsletter #340). He expressed concerns about third-party fee griefing of transactions with P2A outputs.

    Anthony Towns noted that counterparty griefing is a greater concern, since the counterparty is more likely to be in a position to steal funds if the channel isn’t closed on time or in the proper state. Third parties who delay your transaction or attempt to moderately increase its feerate may lose some of their money, with no direct way to profit from you.

    Greg Sanders suggested thinking probabilistically: if the worst a third-party griefer can do is raise the cost of your transaction by 50%, but using a griefing-resistant method costs about 10% extra, do you really expect to be griefed by a third party more often than one force close out of every five—especially if the third-party griefer may lose money and doesn’t benefit financially?

  • ● Stats on orphan evictions: developer 0xB10C posted to Delving Bitcoin with statistics about the number of transactions evicted from the orphan pools for his nodes. Orphan transactions are unconfirmed transactions for which a node doesn’t yet have all of its parent transactions, without which it cannot be included in a block. Bitcoin Core by default keeps up to 100 orphan transactions. If a new orphan transaction arrives after the pool is full, a previously received orphan transaction is evicted.

    0xB10C found that, on some days, more than 10 million orphans were evicted by his node, with a peak rate of over 100,000 evictions per minute. Upon investigating, he found “>99% of these […] are similar to this transaction, which seems related to runestone mints [a colored coin (NFT) protocol]” It appeared that many of the same orphan transactions were repeatedly requested, randomly evicted a short time later, and then requested again.

  • ● Updated proposal for updated BIP process: Mark “Murch” Erhardt posted to the Bitcoin-Dev mailing list to announce that his draft BIP for a revised BIP process has been assigned the identifier BIP3 and is ready for additional review—possibly its last round of review before being merged and activated. Anyone with opinions is encouraged to leave feedback on the pull request.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Cluster mempool: introduce TxGraph is a PR by sipa that introduces the TxGraph class, which encapsulates knowledge about the (effective) fees, sizes, and dependencies between all mempool transactions, but nothing else. It is part of the cluster mempool project and brings a comprehensive interface that allows interaction with the mempool graph through mutation, inspector, and staging functions.

Notably, TxGraph does not have any knowledge about CTransaction, inputs, outputs, txids, wtxids, prioritization, validity, policy rules, and a lot more. This makes it easier to (almost) fully specify the class’s behavior, allowing for simulation-based tests - which are included in the PR.

  • What is the mempool “graph” and to what extent does it exist in the mempool code on master?

    On master, the mempool graph exists implicitly as the set of CTxMemPoolEntry objects as nodes, and their ancestor/dependant relationships which can be recursively traversed with GetMemPoolParents() and GetMemPoolChildren(). ➚

  • What are the benefits of having a TxGraph, in your own words? Can you think of drawbacks?

    Benefits include: 1) TxGraph enables the implementation of cluster mempool, with all of its benefits. 2) Better encapsulation of mempool code, using more efficient data structures. 3) Makes it easier to interface with and reason about the mempool, abstracting away topological details such as not double-counting replacements.

    Drawbacks include: 1) The significant review and testing efforts associated with the large changes introduced. 2) It restricts how validation can dictate per-transaction topology limits, as is for example relevant to TRUC and other policies. 3) A very slight run-time performance overhead caused by translation to-and-from the TxGraph::Ref* pointers. ➚

  • How many Clusters can an individual transaction be part of, within a TxGraph?

    Even though a transaction can conceptually only belong to a single cluster, the answer is 2. This is because a TxGraph can encapsulate 2 parallel graphs: “main”, and optionally “staging”. ➚

  • What does it mean for a TxGraph to be oversized? Is that the same as the mempool being full?

    A TxGraph is oversized when at least one of its Clusters exceeds the MAX_CLUSTER_COUNT_LIMIT. This is not the same as the mempool being full, because a TxGraph can have more than one Cluster. ➚

  • If a TxGraph is oversized, which functions can still be called, and which ones can’t?

    Operations that could require actually materializing an oversized cluster, as well as functions that require O(n2) work or more, are not allowed for an oversized Cluster. This includes operations such as computing the ancestors/descendants of a transaction. Mutation operations (AddTransaction(), RemoveTransaction(), AddDependency(), and SetTransactionFee()), and operations such as Trim() (roughly O(n log n)) are still allowed. ➚

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.

  • ● LND v0.18.5-beta is a bug fix release of this popular LN node implementation. Its bug fixes are described as “important” and “critical” in its release notes.

  • ● Bitcoin Inquisition 28.1 is a minor release of this signet full node designed for experimenting with proposed soft forks and other major protocol changes. It includes the bug fixes included in Bitcoin Core 28.1 plus support for ephemeral dust.

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 #25832 adds five new tracepoints and documentation for monitoring peer connection events such as connection lifetime, reconnection frequency by IP and netgroup, peer discouragement, eviction, misbehaviour, and more. Bitcoin Core users that have Extended Berkeley Packet Filter (eBPF) tracing enabled can hook into the tracepoints using the sample scripts provided, or write their own tracing scripts (see Newsletters #160 and #244).

  • ● Eclair #2989 adds support for batched splices in the router, allowing the tracking of multiple channels spent in a single splice transaction. Due to the inability to deterministically map new channel announcements to their respective channels, the router updates the first matching channel it finds.

  • ● LDK #3440 completes support for receiving async payments by verifying the sender’s invoice request embedded in the HTLC’s (held by an upstream node) onion message and generating the correct PaymentPurpose to claim the payment. An absolute expiry time is now set for incoming async payments, preventing indefinite probing of a node’s online status, and the necessary communication flow is added to release an HTLC held by an upstream node when the recipient node comes back online. To complete the full implementation of the async payment flow, nodes must also be able to act as an LSP that serves invoices on behalf of async receivers.

  • ● LND #9470 adds a deadline_delta parameter to the BumpFee and BumpForceCloseFee RPC commands, specifying the number of blocks over which a given budget (also to be specified) will be fully allocated for fee bumping and a RBF will be performed. In addition, the conf_target parameter is redefined to specify number of blocks for which fee estimator will be queried to obtain the current fee rate, for both the above RPC commands mentioned above and the deprecated BumpCloseFee.

  • ● BTCPay Server #6580 removes a check that verifies the presence and correctness of the description hash in BOLT11 invoices for LNURL-pay. This change aligns with a proposed deprecation in the LNURL Documents (LUD) specification, which deems the requirement to offer minimal security benefits while posing a significant challenge to LNURL-pay implementation. The description hash parameter field is implemented in Core-Lightning (see Newsletter #194 and #232).

Corrections

In a footnote to last week’s newsletter, we incorrectly wrote: “In P2SH and the proposed input sigop counting, an OP_CHECKMULTISIG with more than 16 public keys is counted as 20 sigops.” This is an oversimplification; for the actual rules, please see a post this week by Anthony Towns.