June Roundup
May 7 to June 3
CORE
Wallet and mining IPC work
A fix that unsticks decade-old wallets from the migration tool, and a new submitBlock call on the IPC mining interface that hands block-building off to the mining client.
VERIFY
Reproducibility and secp256k1 verification
b10c matched a Guix-built bitcoind with Nix using Claude Code's
/goal + /loop; UltrafastSecp256k1 v4 lands with Sparrow as the visible adopter.FUNDING
Brink, Btrust, and 2140 reports
Brink 2025 annual report, Btrust new board and Q1 cohort, 2140 first annual report.
MEMPOOL
A decade of workarounds
Spiral retrospective on Bitcoin Core mempool policy.
LOUPE
Spiral and Block AI vulnerability scanner
Free scanning-as-a-service for FOSS Bitcoin: Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Jade, bitcoinj, SRI in the initial cohort.
AI RECOVERY
cprkrn / Claude wallet recovery
~5 BTC unlocked after 11 years. Claude found a 2019 backup and a btcrecover misconfiguration; the seed came from a college notebook.
REGULATION
Australian Travel Rule
AUSTRAC compliance deadline 1 July 2026, no value threshold, self-hosted-wallet collection still required.
NOSTR VPN
Nostr-based VPN connectivity
Martti Malmi's nostr-vpn repo.
KAGIKAI
Multisig bearer instrument
2-of-3 multisig peer-to-peer electronic cash with secure-enclave assumptions.
ZCASH
Coordinated network upgrade
Orchard was paused by soft fork, then restored by the NU6.2 hard-fork upgrade.
Bitcoin Core Watch
Two notable merges - one for very old wallets, one for mining
PR #34198 - ANCIENT WALLETS CAN MIGRATE AGAIN
furszy, merged by achow101. Very old wallets - created before bitcoin/bitcoin#152, back in the early days of the codebase - never wrote a "best block locator", the marker a wallet uses to remember how far it has scanned the chain. The new wallet-migration tool was treating that missing marker as fatal and refusing to proceed, leaving anyone sitting on a decade-old
wallet.dat stuck on the legacy format. The fix accepts the empty value, falls back to a normal rescan on reload, and lets these wallets finally move onto the modern descriptor wallet format.PR #34644 - MINING SOFTWARE GETS A NEW WAY TO SUBMIT BLOCKS
woltx/w0xlt, merged by ryanofsky. Bitcoin Core has been growing an inter-process (IPC) Mining interface that lets external mining software drive a Core node from a separate process. This PR adds
submitBlock, mirroring the existing checkBlock shape: the caller hands the node a fully formed block - including the coinbase witness commitment - and the node only validates and broadcasts it. Block construction lives entirely on the mining-client side, unlike the older submitblock RPC. Useful for mining stacks that want to build templates themselves rather than rely on Core's getblocktemplate.Verification and Reproducibility
Two threads on how Bitcoin software gets checked
NIX MATCHES GUIX (DRIVEN BY CLAUDE CODE)
b10c handed the whole task to Claude Code with one directive -
/goal produce a Nix-built binary with a hash matching the Bitcoin Core v31.0 release binary for x86_64-pc-linux-gnu - paired with /loop 2h continue with what you were doing. If you are stuck, try solving a different problem first so the agent kept working through Pro-plan usage-cap resets. A mix of Claude Sonnet 4.6 and Opus 4.7, around 80 unreviewed commits, and roughly 1.5 weeks of Claude Pro usage later, the agent came back with a Nix-built binary matching the official Guix bitcoind at sha256: dae69848…e25eb6. The point: reproducibility today really only holds inside Guix - a second, fully independent toolchain converging on the same bytes turns it into something you can cross-verify, and an agent-driven loop got there.ULTRAFASTSECP256K1 v4.0
shrec, 2026-05-16. Targets x86, ARM64, RISC-V, ESP32, STM32, Android, iOS, WASM, and CUDA. v4.0 introduces CAAS (Continuous Assurance Architecture System), a quality framework where docs, benchmarks, CI, audit modules, and integration behaviour "must continuously agree with reality". Reception on Delving has been quiet: a companion thread proposing it as an opt-in libsecp256k1 backend (default unchanged) has drawn limited engagement and no merged path. Visible adoption sits with Sparrow's
duckdb-ufsecp-extension - a Craig Raw DuckDB extension that runs BIP-352 Silent Payments scanning on libufsecp, with optional CUDA, OpenCL, and Apple Metal GPU paths. Not in the desktop wallet itself.Funding and Org Updates
Brink, Btrust, 2140, Bitcoin++ schedule
BRINK - 2025 ANNUAL REPORT
Raised ~$7.8M; spent ~$2.6M with 87% to programs - of which $1.75M went to developer salaries and grants. Funded eight engineers and two fuzz-testing interns; new in 2025 was Eugene Siegel on Bitcoin Core P2P. Underwrote Bitcoin Core's first third-party security audit (Quarkslab), Fuzzamoto, and the CoreDev meetings in Jamaica and Frankfurt. 2026 plan flagged: bug bounty, quantum-effort exploration, LLM integration.
BTRUST - NEW BOARD
Inaugural board (Obi Nwosu, Ojoma Ochai, Carla Kirk-Cohen, Abubakar Nur Khalil) completed its mandate. New board as of 2026-04-30: Janet Maingi, Bruno Garcia, Laurence Aderemi. Abubakar Nur Khalil moves to CEO. Funded by the original 500 BTC endowment from Jack Dorsey and Jay-Z (2021). Focus remains Global South, Africa-based talent.
2140 - FIRST ANNUAL REPORT
First-year team: Rob, Novo, Sadiq, Sergi. Amsterdam office opened 2025. Projects: Silent Payments in Bitcoin Core and libsecp256k1, SwiftSync prototype, Kyoto (BIP-158 light client), the new mining interface, libmultiprocess, and libbitcoinkernel work. Hosted a Silent Payments gathering in Amsterdam.
BITCOIN++ - 2026 SCHEDULE
Four upcoming editions:
- Nairobi - June 17-19, Open Source edition
- Toronto - July 22-24, Consensus edition
- Berlin - Oct 1-3, Payments edition
- Seoul - Nov 5-6, Privacy edition
Mempool Policy: A Decade of Workarounds
Spiral retrospective by @theinstagibbs, 2026-04-08
THE ARC
It walks through how Bitcoin Core mempool policy evolved from v0.12 (Feb 2016) to v31's cluster mempool (2026). The author argues the 2018-2019 RBF carveouts were Lightning-specific patches that newer work - TRUC and cluster mempool - finally lets the project rip out, replacing rule-of-thumb constraints with policy that follows directly from how miners actually order transactions.
WORKAROUNDS COVERED
Opt-in RBF (BIP 125), CPFP, CPFP carveout, single-conflict RBF carveout, TRUC/v3 (BIP 431), 1P1C package relay, sibling eviction, Pay-to-Anchor (P2A), ephemeral dust, full RBF by default, and cluster mempool.
RULES THE POST WANTS DELETED
The "no new unconfirmed parents" RBF rule, the CPFP carveout, the single-conflict RBF carveout, and the topology restrictions on package RBF - now obviated by cluster mempool's linearisation.
CONTRIBUTORS NAMED
Matt Corallo (Nov 2018 CPFP carveout proposal), Pieter Wuille (cluster mempool linearisation), Suhas Daftuar (cluster mempool overview).
Loupe
Spiral and Block AI vulnerability scanning, announced 2026-05-12
ANNOUNCEMENT
Authored by Elias Rohrer, Jordan Mecom, and Thomas Kilbride (Spiral and Block). Pitched as free "scanning-as-a-service" for FOSS Bitcoin projects, with a stated quality gate that the tool "only report vulnerabilities backed by a demonstrable test case".
INITIAL COHORT
Projects committed to early scanning: Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Blockstream Jade, bitcoinj, and SRI.
MODEL APPROACH
Loupe wraps multiple LLMs behind one interface and picks per-finding. Spiral says it'll keep that model mix updated as new frontier releases land; specific models aren't named in the announcement.
WHAT'S NOT IN THE POST
No specific vulnerabilities, CVEs, or quantified results are disclosed in the launch announcement. Block and Spiral describe prior internal use across Bitcoin repos with private maintainer reporting, but findings are not enumerated.
AI-Assisted Wallet Recovery
cprkrn's recovery of a 2015 wallet, posted 2026-05-13
WHAT WAS POSTED
X account @cprkrn reported recovering roughly 5 BTC (~USD 400k) from a wallet password set in 2015 and forgotten. Earlier
btcrecover brute-force attempts had run without success.WHAT CLAUDE DID
Given a large dump of an old college computer, Claude located a December 2019 backup of the wallet file the owner had not remembered, and identified a misconfiguration in how
btcrecover was combining the shared key and candidate passwords. The owner separately found a mnemonic seed in an old college notebook.WHAT CLAUDE DID NOT DO
No encryption was broken. The recovery used the existing open-source
btcrecover path plus owner-recovered seed material. Closer to structured discovery and tool orchestration than cryptographic attack.DISCUSSION PROMPTS
What hygiene applies when feeding an LLM a wallet file or seed material - local model versus hosted, log retention, sandboxed instances? How does this sit alongside Loupe's defensive use of AI?
Australian Travel Rule
AUSTRAC compliance deadline 1 July 2026
COMPLIANCE DATE
All VASPs - existing and newly regulated - must comply with the Travel Rule by 1 July 2026.
VASP REGISTRATION
New providers can enrol with AUSTRAC from 31 March 2026; deadline 29 July 2026. The old "DCE" designation is retired in favour of "VASP".
NO VALUE THRESHOLD
Every in-scope transfer triggers Travel Rule information handling. There is no minimum AUD threshold below which the rule does not apply.
ASIC FRAMEWORK
A separate ASIC Digital Assets Framework commences 9 April 2027, layering financial-services obligations onto the AUSTRAC regime.
DATA TO BE SENT
The sending exchange has to collect and verify who the payer is, collect the payee's full name, and pass all of that - plus tracing info for the transfer - to the next VASP in the chain, either before or alongside the transfer.
SELF-HOSTED WALLETS
Sending to a self-hosted wallet skips the VASP-to-VASP message - there's no other VASP to message - but the sending exchange still has to collect and verify payer details and the payee's name. Exchanges receiving from a self-hosted wallet must collect payer details, the payee's full name, and tracing info before crediting the account.
Nostr VPN
Martti Malmi's Tailscale-style mesh, coordinated over Nostr
DESIGN
A private mesh VPN in the Tailscale shape: every device talks directly to every other device once they've joined the network. The data channel itself runs jmcorgan's FIPS ("Free Internetworking Peering System") mesh protocol - a separate Rust project that nostr-vpn integrates with - rather than something Malmi authored; WireGuard only shows up at the exit node, when the mesh forwards traffic out to the regular internet. CLI is
nvpn (cargo install nvpn); identities are Nostr npub keys generated locally on first run.NOSTR ROLE
Nostr relays carry invite sharing, roster sync, and admin coordination. There is one active named network at a time, with MagicDNS, route advertisement, and exit-node selection.
PLATFORMS
Native apps for Apple Silicon macOS, Linux x64 (GTK/libadwaita, .deb), Windows x64 (WPF, WinTun), Android arm64. iOS TestFlight is not yet public. Umbrel and StartOS packages exist. Intel macOS is source-only.
LICENSE / LANG
MIT. Rust app-core with Swift, Kotlin, and C# platform shells.
CANONICAL REPO
git.iris.to under Malmi's npub; GitHub is a mirror.Kagikai - Multisig Bearer Instrument
Hardware-enclave 2-of-3 P2TR bearer cash, plus the Delving critique
KEY MODEL
- Address - a Taproot 2-of-3 multisig over three locally generated keys.
- Keys - Key A (issuer side, deleted before funding); Key B and Key C (both held by whoever holds the note). B and C combine via MuSig2, so on-chain spends look like any other Schnorr signature.
- Hardware - the phone's secure chip generates and holds the keys (Android Titan M2 / iOS Secure Enclave).
- Transfer - encrypted key handover over QR, NFC, or HTTPS, with a Nostr receipt for the new bearer.
DELVING CRITIQUE (AdamISZ, since-deleted thread #2470)
After the original P2SH framing was posted on 2026-05-01, AdamISZ replied that the core "transfer private key, then delete it" model is not convincing because the receiver cannot know the sender really deleted their copy. In other words: peer-to-peer handover lets the previous bearer race the new one. Hardware enclaves do not change this for the bearer-to-bearer step, only for the issuer's Key A.
AUTHOR'S RESPONSE
The author narrowed the claim and updated the design:
- Issuer key deletion is not the security assumption. The novelty is the issuer being permanently below the spend threshold.
- Moved from P2SH to Taproot/MuSig2 with buyer-generated keys (buyer generates Keys B and C locally, sends only pubkeys to the issuer).
- Added multi-node UTXO verification and a merchant sweep step.
- Conceded that finality only comes from sweeping the UTXO to a fresh receiver-only address.
UPSHOT
Kagikai removes the issuer as a trust point and lets a UTXO circulate off-chain, but it does not solve copied-key finality. Treat it as a digital cash note backed by a UTXO where possession of key material is the claim and real safety comes at sweep. The Delving thread is now 404; the criticism summary above is from prior cached reading.
Zcash Orchard Emergency Upgrade
Soft-fork pause, then NU6.2 hard-fork remediation
WHAT HAPPENED
A critical soundness vulnerability in the Orchard zero-knowledge proof circuit was discovered by Taylor Hornby on 2026-05-29 and privately disclosed to Zcash Open Development Lab engineers. Successful exploitation could have permitted invalid state transitions or double-spending within Orchard, but Zcash reported no evidence of exploitation, no evidence of unauthorized value creation, and no privacy impact.
SOFT FORK
zcashd v6.12.5 and zebrad v4.5.3 temporarily disabled Orchard actions at mainnet height 3,363,426 (transition began 22:30 EDT on 2026-06-01 / 02:30 UTC on 2026-06-02).HARD FORK
The follow-up NU6.2 hard-fork network upgrade, shipped in
zcashd v6.20.0 and zebrad v5.0.0, completed at 00:05 EDT on 2026-06-03, re-enabling Orchard with the corrected circuit.SCOPE
Only Orchard transactions were paused. Sapling and transparent pools continued to operate normally.
NETWORK EFFECT
Mining nodes that missed the soft-fork update orphaned blocks; operator Kenbak reported a 25-block competing fork at heights 3,363,431-3,363,455, plus 37 total orphans across the transition.
WHY TWO STAGES?
The soft fork bought time without publishing the full circuit fix. The hard fork was needed because the permanent remediation changed Orchard's zero-knowledge proof circuit and verifying key.