The Nostr Observer

The Patch Is Not the Upgrade: Core Fixes Three Memory Bugs, but 96% of Nodes Lag Behind

Discovery to disclosure took five days without an embargo, but code moves faster than operators: half the network still runs version 31.1.0.

Sixteen hours after Bitcoin Core published advisories for three memory vulnerabilities uncovered by automated LLM scanning tools, a network census reveals the stubborn gap between releasing a patch and securing a fleet. Of 16,283 reachable nodes identifying as Bitcoin Core, exactly 568—or 3.5 per cent—reported running a patched release carrying the mitigation [s584]. A single older release, 31.1.0, still accounted for 8,080 nodes, while 4,965 nodes ran versions already declared end-of-life.

The timeline itself marks a milestone in open-source vulnerability handling. On October 23, an automated scanner found an issue that lets any connected peer crash a Windows, macOS or BSD node. By October 26, the fix was opened, merged, and backported. On October 27, versions 31.2 and 32.1 shipped, followed immediately by point updates 29.5 and 30.4. Disclosure occurred in the same hour without a private embargo [s584].

Code can be fixed in a day; a fleet cannot. The vulnerability window is now set by three clocks running at different speeds, and the policy change that Bitcoin Core merged on 22 October only touched the first one.

Two of the vulnerabilities were discovered by Project Loupe, an automated scanning pipeline developed at Spiral [s584]. While the TCP urgent data crash was patched within days of detection, an earlier pre-BIP31 queue exhaustion bug discovered in mid-September waited forty-one days until the scheduled release train. The lesson is straightforward: automated auditing makes flaw discovery cheap and continuous, but shipping remains coupled to human release cycles and manual node upgrades [s584].

A Paint App Shouldn’t Need to Understand Nostr: The Case for Napplets

NIP-5D proposes separating lightweight tools from protocol plumbing, letting users trust a single shell rather than untrusted app code.

Building software on open protocols often forces developers to reinvent identity, relay management, and signing infrastructure before drawing a single pixel. A new proposal, NIP-5D, argues for lightweight “napplets” that run inside a trusted host shell [s549].

A paint app needs a canvas, some colors, and a way to undo a bad brushstroke. writes sandwich [s549]. None of that requires a relay connection or a signing key. If you want to build one, you should be able to spend your time on the editor. And if someone wants to try it, they shouldn't have to trust you with everything else they do.

By moving cryptographic authority and network permissions entirely into the host shell, users gain a defensible security posture: trust the shell, but isolate the app in a sandboxed frame [s549].

Jumble Adds NIP-22 Comment Toggle

Clients are gradually moving toward standard threaded replies. Cody noted that Jumble now offers a setting under General Features allowing users to reply to kind 1 notes via NIP-22 comments [s123].