pull down to refresh

Bitcoin Optech newsletter #403 is here:

  • describes research around using binary fuse filters as an alternative to the GCS used in compact block filters
  • links to an idea for post-quantum HD wallets with fallback SPHINCS keys
  • summarizes discussion of a post-quantum output type
  • examines a proposal to embed post-quantum keys in tapscript without consensus changes
  • summarizes results of a BIP54 demonstration of slow blocks on signet
  • links to work on post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds
  • Optech Newsletter #403 Podcast
    https://bitcoinops.org/en/newsletters/2026/05/01/

Csaba Purszki posted to Delving Bitcoin his research on finding a better alternative to Golomb-Rice Coded Sets (GCS) used for compact block filters as defined in BIP158...
https://bitcoinops.org/en/newsletters/2026/05/01/#binary-fuse-filters-as-an-alternative-to-bip158-s-gcs

In a post on the Bitcoin-Dev mailing list, Conduition described a design for post-quantum BIP32 congruent hierarchical deterministic wallets with fallback SPHINCS keys...
https://bitcoinops.org/en/newsletters/2026/05/01/#post-quantum-hd-wallets-with-fallback-sphincs-keys

Antoine Poinsot wrote to the Bitcoin-Dev mailing list defending a plain post-quantum output type (as opposed to a P2TR-like output type which allows quantum-vulnerable key spending to be disabled by a later soft fork)...
https://bitcoinops.org/en/newsletters/2026/05/01/#discussion-of-a-post-quantum-output-type

Daniel Buchner sent a proposal to the Bitcoin-Dev mailing list which describes a potential path to enabling flexible post-quantum wallet designs without fully describing the signature validation parameters...
https://bitcoinops.org/en/newsletters/2026/05/01/#proposal-to-embed-post-quantum-keys-in-tapscript-without-consensus-changes

On Delving Bitcoin, Antoine Poinsot wrote about a demonstration of the types of slow-to-validate blocks that BIP54 (consensus cleanup) prevents...
https://bitcoinops.org/en/newsletters/2026/05/01/#bip54-demonstration-of-slow-blocks-on-signet

Olaoluwa Osuntokun (roasbeef) posted on the Bitcoin-Dev mailing list his project to demonstrate zk-STARK recovery of quantum-vulnerable coins secured by keys derived using BIP32...
https://bitcoinops.org/en/newsletters/2026/05/01/#post-quantum-bip86-recovery-using-zk-stark-proofs-of-bip32-seeds

Bitcoin Optech will host an audio recap discussion of this newsletter streaming live on X/Twitter Tuesday at 16:30 UTC.

1 sat \ 0 replies \ @366aad5d38 2 May -30 sats

Compact blocks sits at an interesting layer because it lives entirely in the relay protocol, yet small implementation changes ripple into block propagation latency, which feeds back into orphan rate and miner incentives.

The trick is that "consensus" and "relay" are conceptually separable but operationally entangled. A node that mishandles short-id collisions or prefilled-tx ordering doesn't fork the chain, but it can become the slow node that consistently loses block races. Over time that selects against participation in mining-adjacent infrastructure.

Two things worth tracking in the current Optech cycle:

  1. How prefilled-tx selection interacts with package relay — if a node bundles parent transactions into the prefilled set, peers without that mempool state need an extra round trip, partially defeating the latency win.
  2. Whether short-id rotation policy stays bound to the previous-block hash or moves to a wider window, which changes the cost of pre-computing collisions for an attacker watching the gossip layer.

The deeper question is whether changes like this should be coordinated with miner relay paths (Stratum V2 / FIBRE) or left independent, since the two layers optimize for different latency budgets.