This week’s newsletter briefly describes a new library allowing output script descriptors to be compressed for use in QR codes. 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

  • ● Compressed descriptors: Josh Doman posted to Delving Bitcoin to announce a library he’s written that encodes output script descriptors into a binary format that reduces their size by about 40%. This can be especially useful when descriptors are backed up using QR codes. His post goes into the details of the encoding and mentions that he plans to incorporate the compression into his encrypted descriptors backup library (see Newsletter #358).

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.

Improve TxOrphanage denial of service bounds is a PR by glozow that changes TxOrphanage eviction logic to guarantee each peer the resources for at least 1 maximum-size package worth of orphan resolution. These new guarantees significantly improve 1-parent-1-child opportunistic package relay, especially (but not only) under adversarial conditions.

The PR modifies existing global orphanage limits, and introduces new per-peer ones. Together, they protect against both excessive memory usage and computational exhaustion. The PR also replaces the random eviction approach with an algorithmic one, calculating a per-peer DoS Score.

Note: the PR has undergone a few significant changes since the Review Club, most importantly using a latency score limit instead of an announcement limit.

  • Why is the current TxOrphanage global maximum size limit of 100 transactions with random eviction problematic?

    It allows a malicious peer to flood a node with orphan transactions, eventually causing all legitimate transactions from other peers to be evicted. This can be used to prevent opportunistic 1-parent-1-child transaction relay from succeeding, since the child wouldn’t be able to stay in the orphanage for long. ➚

  • How does the new eviction algorithm work at a high level?

    Eviction is no longer random. The algorithm identifies the “worst-behaving” peer based on a “DoS score” and evicts the oldest transaction announcement from that peer. This protects well-behaved peers from having their transactions’ children evicted by a misbehaving peer. ➚

  • Why is it desirable to allow peers to exceed their individual limits while the global limits are not reached?

    Peers may be using more resources simply because they are a helpful peer, who’s broadcasting useful transactions such as CPFPs. ➚

  • The new algorithm evicts announcements instead of transactions. What is the difference and why does it matter?

    An announcement is a pair of a transaction and the peer who sent it. By evicting announcements, a malicious peer cannot evict a transaction that was also sent by an honest peer. ➚

  • What is a peer’s “DoS Score” and how is it calculated?

    A peer’s DoS score is the maximum of its “memory score” (memory used / memory reserved) and “CPU score” (announcements made / announcement limit). Using a single combined score simplifies eviction logic into a single loop that targets the peer most aggressively exceeding either of its limits. ➚

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.

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.

  • ● Core Lightning #8377 tightens BOLT11 invoice parsing requirements by mandating that senders not pay an invoice if a payment secret is missing or if a mandatory field such as p (payment hash), h (description hash), or s (secret), has an incorrect length. These changes are made to align with the recent specification updates (see Newsletters #350 and #358).

  • ● BDK #1957 introduces RPC batching for transaction history, merkle proofs, and block header requests to optimize full scan and sync performance with an Electrum backend. This PR also adds anchor caching to skip Simple Payment Verification (SPV) (see Newsletter #312) revalidation during a sync. Using sample data, the author observed performance improvements of 8.14 seconds to 2.59 seconds with RPC call batching on a full scan and of 1.37 seconds to 0.85 seconds with caching during a sync.

  • ● BIPs #1888 removes H as a hardened-path marker from BIP380, leaving just the canonical h and the alternative '. The recent Newsletter #360 had noted that grammar was clarified to allow all three markers, but since few (if any) descriptor implementations actually support it (neither Bitcoin Core nor rust-miniscript do), the specification is tightened to disallow it.

Want more?

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