Bitcoin Optech: Newsletter #405 Recap

— BIP proposal for UTXO set sharing over P2P: Fabian discussed a draft BIP to enable nodes to receive UTXO snapshots from peers rather than downloading from external sources, improving the AssumeUTXO feature for faster node bootstrap.

— Bitcoin Core CVE-2024-52911 disclosure: A use-after-free vulnerability affecting versions 0.14–28 was disclosed. The bug allowed crafted invalid blocks to crash nodes; exploitation required valid proof-of-work but would not propagate on the network.

— AssumeUTXO adoption and trust model debate: Discussion centered on whether AssumeUTXO is suitable for resource-constrained users. Supporters emphasize its value for nodes with limited bandwidth or hardware; critics argue it introduces unacceptable trust assumptions.

— Core Lightning 26.06 RC1 release: New features include graceful shutdown RPC, send_amount RPC for invoice payment with routing fees specified upfront, and experimental Bolt 12 payer-proof support.

— BIP 323 (24-bit version field extra nonce space): Proposal to use version field bits for additional entropy in block mining, reducing or eliminating the need for timestamp rolling and allowing significantly more block candidates per second.

— BIP 322 message signing completion: Updated generic message signing format now supports all UTXO types with proof-of-funds construction, PSBT support, and moved to complete status for ecosystem adoption.

— For node operators: If running a resource-constrained node or experiencing slow initial block download (weeks rather than hours), test the AssumeUTXO feature in Bitcoin Core 29+. Provide feedback to developers on its usefulness for your setup, as adoption metrics are currently unclear.

— For Core Lightning users: Review the 26.06 RC1 release notes before it ships. Test the new payment RPCs (XPay) and understand the deprecation timeline for legacy pay RPCs (removal in March 2026). Flag any compatibility issues early.

— For application developers using Lightning: Examine BIP 322 (message signing) and LDK's metadata enforcement changes if upgrading. Test compatibility with existing invoice workflows, particularly around Bolt 12 offers and optional metadata fields.