What if a one-time signature survived a second use? HG-WOTS (pronounced "Hogwots") aims for ~80 bits of security when a key is accidentally used twice. It's 786 bytes, vs. 530 for the WOTS+C in SHRINCS. Mostly a Fable invention. No security proof yet. Even more interesting than two-time security is HG-WOTS' potential to improve the efficiency of stateless signatures. Explore HG-WOTS with the following prompt: Consider HG-WOTS, a hash-chain one-time signature, and study what repeated signing exposes. Key: k groups of s hash chains (w nodes each). Hash each group's chain endpoints into the start of a secondary "group chain" (w2 nodes); pk = hash of the k group-chain endpoints. Codeword: choose j hidden groups; each revealed group gets remaining distances with sum d_g; the hidden groups get group-chain distances with total sum d_h. Distances count hash steps to the chain's end (0..w-1, resp. 0..w2-1); codewords are uniform. Signature: the s chain nodes of each revealed group, and one group-chain node per hidden group. Recovery hashes forward to pk. Model: an adversary seeing past signatures may only hash forward. A target is derivable iff it hides every group hidden in all past signatures, each revealed chain distance is <= the max exposed on that chain, and each always-hidden group-chain distance is <= the max exposed there (a group revealed once exposes its whole group chain). Define cover(r) as the probability that a uniform target codeword is derivable from r independent uniform past signatures; explore how cover(r) depends on r and the parameters.

Sad to see nix-bitcoin winding down after 8 years of work. Huge thanks to everyone who built and maintained it, and we’re very grateful that Vinteum was included among the recipients of the remaining security fund. Hopefully someone from the community will step up, fork it, and keep the project alive. We understand why simply handing maintenance over to someone who hasn’t previously contributed to the repository wouldn’t be the right path. Building that trust and familiarity takes time. We hope Vinteum can help that process in some way. ❤️

As part of winding down nix-bitcoin, we're closing the nix-bitcoin security fund. Per the fund's terms, the remaining 0.19 BTC goes in equal parts to non-profits: @HRF's Bitcoin Development Fund @OpenSats @torproject @Vinteum_org blockstream.info/tx/bee50bc3…

Core Lightning 26.06.8 is out, and every node runner should upgrade. This release fixes vulnerabilities responsibly reported over recent weeks. There is no embargo period: the release and fixes are available right now. A number of tests are being held back temporarily to make the underlying issues harder to reverse-engineer while node runners have time to upgrade. Please upgrade as soon as possible. github.com/ElementsProject/l…

Thanks for the careful review. This is the kind of discussion necessary for making progress on post-quantum Bitcoin. There's a lot here I agree with, though I come to a different conclusion. I agree that hash-based signatures are a good fit for Bitcoin, for the reasons the review gives. Reducing block space usage is indeed a primary design goal of SHRINCS, and it comes at a cost. The stateful path's safety depends on wallet infrastructure that the protocol does not prescribe and that still needs standards. I also agree that if block space stays cheap, the stateful path adds complexity for little benefit. But that seems unlikely, since today's fees reflect 64-byte signatures, and stateless SHRINCS signatures are about 90 times larger. High fees matter for a store of value too, because holders eventually need to spend, and we should aim for Bitcoin to remain usable by people who don't hold large amounts. Congestion and high fees are a strong argument for minimizing signature size, and stateful signatures are up to about 10 times smaller than stateless ones. Wallets can start with stateless signing and enable stateful signing for their existing keys later, without another soft fork. A block-size increase can't fully solve this. Every node has to download and validate every block, so blocks can't grow arbitrarily large. The review suggests that the stateful path lets the SHRINCS authors say the block-size concern has been addressed. The intent is rather that SHRINCS doesn't depend on a block-size increase, so that question can be discussed separately without holding up post-quantum signatures. On custody, I agree that it's unreasonable to expect replicas to share stateful signing slots safely. Some high-availability setups can still use the stateful path, for example one where a designated signer signs statefully while the replicas sign only statelessly, so failover costs larger signatures but requires no coordination of state. In practice, custodians may simply sign statelessly. The review describes stateful signing as an optimization, which fits better than the BIP's "primary path" wording. It also made me realize that calling the stateless path a "fallback" is misleading, and we're considering changing the terminology in the BIP. The review proposes considering a stateless-only scheme with a larger block size. Modified algorithms could reduce stateless signatures to roughly 4,000 bytes, about 60 times the size of a Schnorr signature instead of 90. Would that be worth departing from the SLH-DSA algorithms?

Adaptive attacks against FROST when number of signers and corruptions is large. BIP 445 (FROST) not affected because it requires fewer than 128 signers. This requirement in BIP 445 was added by @real_or_random exactly because there was uncertainty about the hardness of LDVR. github.com/siv2r/bips/blob/8…

… it comes with a Lean proof 👀

A quantum-resistant Bitcoin transaction, with no soft fork, confirmed on mainnet in August. Producing it took ~3,100 GPU-hours across ~100 GPUs. That cost is now the problem to solve. Today, @StarkWareLtd in collaboration with @eigenlabs and Yukon Research, we're opening it to everyone. With $20,000 prize up for grab. The QSB Autoresearch Challenge targets the two GPU grinding workloads behind QSB: transaction pinning and subset selection, ranked as separate tracks. Every candidate is an ECDSA public-key recovery plus a SHA-256 hash, repeated billions of times. The CUDA seed was written fast with AI help and shipped once it worked. It is deliberately unoptimized. How it works: bring your coding agent, model and harness, and submit CUDA optimized kernels. Ranked runs execute in a sandbox on hosted NVIDIA RTX 4090s, against a fresh problem instance seeded after your code is locked. Every hit is re-derived on CPU, so no kernel gets throughput credit without doing the real elliptic-curve work. To take the lead, beat the current best by at least 1%. Why I'm excited: as far as I know, this is the first wide-scale autoresearch experiment aimed at improving a Bitcoin construction rather than breaking one. It is also a live test of which models and harnesses can do hardcore CUDA and cryptographic optimization, with results nobody has to take on trust. If you build on Bitcoin, write CUDA, or push coding agents hard: come break the baseline. Bring your clanker. qsb.fast/

⚛️ Bitcoin does not have a quantum computer problem today. It has a migration problem, and migrations could take years to get right. SHRINCS is the first Bitcoin-specific post-quantum proposal I have seen that makes a serious end-to-end trade-off, and it deserves to be read carefully rather than cheered or dismissed. Their work is the proposal. I wrote an analysis of the challenges that come with it, the ones that only become visible when you look past the signature scheme and into the wallets that have to run it. The migration really has three questions: - which scheme Bitcoin should support - what that scheme does to the protocol and the wallet ecosystem - what happens to coins that have never been moved by their owner. Almost all of the public discussion is still on the first one, which is probably the easiest of the three. SHRINCS is conservative where it matters. It is hash-based, so it leans on the SHA-256 that Bitcoin already depends on instead of stacking a lattice assumption on top. A single 48-byte public key commits to both a compact stateful path (Flexible XMSS and WOTS+C) and a stateless SLH-DSA fallback. Verification is the pleasant surprise. It is mostly SHA-256, and the draft reports a worst-case cost per signature byte below BIP340 Schnorr. The stateful path uses one-time keys, and each one must sign exactly once. The counter must never move backwards, it must be committed to persistent storage before the signature leaves the device, and it must never be restored from a backup. Sign two different messages from the same slot and an observer can steal your fund. SHRINCS handles this better than a purely stateful scheme. If the state is lost or merely uncertain, the seed still derives the stateless key, so you lose efficiency rather than funds. The cost is that wallet state stops being application data and becomes cryptographic state whose rollback can take user funds: hundreds of counters for hundreds of UTXOs, across several devices and several software wallets, on hardware where hash-based keygen already takes minutes. There are also capabilities we do not get back. Non-hardened BIP32 derivation, and with it watch-only wallets as we build them today. Compact Schnorr-style threshold signing. None of this makes SHRINCS a bad proposal, and the spec is honest about its own status: non-standard SLH-DSA parameters, constructions outside the NIST standard, security proof pending. It does mean the cost of this migration cannot be only measured in signature bytes. The stateful aspect of SHRINCS would be very challenging in terms of security and UX. The uncomfortable part is that picking the signature scheme may be the easiest question here. ledger.com/blog-shrincs-bitc…

I wrote a blog post on the recent exploits in the Bitcoin ecosystem, how Bitcoin Core is holding up, and how I think the community can get ahead of the models: dergoegge.de/blog/somethings…

OP_TEMPLATEHASH can solve two of the biggest BitVM3 bridge pain points: • interactive deposits → non-interactive • 1-of-n committee for safety → gone robinlinus.com/bitvm448.pdf

RT @zooko: Hey folks! I made a cool resource. Please read this tweet (quote tweeted below) and then click through to the link so you can ex…

Solving Bitcoin is an auto-research project aimed at advancing the state of the art in Bitcoin protocols. We’re starting by optimizing common cryptographic primitives, including Lamport signatures and arithmetic. Join us: let your clankers optimize scripts, implement new primitives, and submit PRs. github.com/solving-bitcoin/b…

Oh didn't know that :) Good catch, glad you guys found it before an attacker could try to add malicious binaries. @craigraw you might also want to update the download guide in the Sparrow wallet website.

gpg --verify SHA256SUMS.asc is easily bypassable for detached signatures. The correct command requires the data file: gpg --verify SHA256SUMS.asc SHA256SUMS This appears to be a common mistake. Without the second argument, gpg succeeds even if the .asc file contains an arbitrary embedded message rather than signing the actual SHA256SUMS file. It prints a warning, but it's easily missed in gpg's output. The gpg manpage explicitly discourages the single-argument form, keeping it only for backward compatibility. I actually keep a list of gpg pitfalls. This is number 8. Mehdi Kerimov reported this in nix-bitcoin's self-updater via @nixbitcoinorg's bounty program. We had originally followed bitcoincore.org verification instructions, which had the same issue and have since been fixed. That this sat unnoticed on @bitcoincoreorg since 2018 shows just how little-known this footgun is. It's unlikely bad signatures were ever published at scale, as anyone noticing the warning or using the two-argument command would have caught it immediately.

More progress being made by @remix7531 on the libsecp256k1 Schnorr Signature (BIP 340) formal verification front: github.com/bitcoin-core/secp….

LIQUID NETWORK UPDATE: INCIDENT REPORT Status as of September 8, 2026, 19:10 UTC What Happened? On September 6, 2026 at 15:53:10 UTC (Liquid block 4,050,336), a vulnerability in the open-source Elements software related to how Liquid nodes cache range proof verifications was exploited, resulting in the creation of ~4,000 LBTC that were not backed by bitcoin held in reserve. The individual(s) responsible for the exploit then used the SideSwap service, a Liquid Federation member that holds a peg-out authorization (PAK) key, to convert the unbacked LBTC to BTC via Liquid’s standard peg-out mechanism. Because the validation failure occurred at the transaction level before the peg-out was initiated, both SideSwap’s node and the Liquid Network’s globally distributed functionary nodes accepted the LBTC as valid. The functionaries processed the peg-out as authorized, releasing approximately 4,000 BTC through SideSwap’s whitelisted bitcoin address, which SideSwap then forwarded to the address specified by the exploiters. Before the incident, the Liquid reserve held approximately 4,205 BTC. Following this peg-out and additional peg-outs processed before operations were halted, the reserve balance fell to 197 BTC. Key Clarifications No keys were compromised. The Liquid Federation functionaries were not hacked, and no private keys were compromised. The peg-out mechanism that authorizes withdrawals to whitelisted addresses operated as designed. Other Liquid-issued assets were not affected. USDT and other tokens issued on the Liquid Network were not impacted by the vulnerability, though they are temporarily unavailable while the network remains paused. Investigation is ongoing. As is common in complex critical-system failure investigations, this incident arose from the convergence of several individually low-probability factors that interacted in ways that ultimately defeated the system's built-in redundancies. More detail will be shared in forthcoming communications. What Steps Have Been Taken To Recover The Assets? The individual(s) responsible for the exploit left a public message on the bitcoin mainchain identifying themselves as white-hat security researchers and requesting contact to address the vulnerability. Patch deployed. Blockstream identified and deployed a patch to the Liquid Network’s bridge nodes, which was completed on September 7 at 01:09 UTC, ensuring the vulnerability is no longer exploitable. Partial fund recovery. On September 7 at 16:09:25 UTC (Liquid block 965,950), the exploiters returned 3,400 BTC to the Liquid Federation peg wallet. Approximately 598.5 BTC (15% of the total) remains outstanding. Discussions between Blockstream and the individuals responsible are ongoing to secure the return of the remaining funds. What Comes Next? Our immediate priorities are recovering the remaining funds and resuming normal network operations safely and as quickly as possible. Software update in progress. A fix for the exploited vulnerability has been developed and is undergoing multiple rounds of internal and external review. Blockstream is preparing an emergency release of Elements (v23.3.4), which is expected to be released as soon as possible, but within approximately 48 hours. Network restoration. Once the software update is finalized, Liquid Network functionary operators will perform additional adjustments to resume full functionality and restore the corrected network state, including rejection of the invalid peg-out. Ongoing updates. We will continue to provide detailed updates as the situation progresses. What You Should Know The Liquid Network remains offline at this time, while we work on reviewing the security fixes and network resumption code and coordinate with the white hat hacker towards timely resumption of the network with 1:1 backing for BTC. While the network is paused, users cannot transact on Liquid. If you operate a Liquid node, please watch for the emergency Elements release and follow the upgrade instructions when available. Users do not need to take any proactive steps to protect their funds at this time. The Liquid Federation and its members are committed to resolving this incident in coordination with Blockstream and to resuming normal operations as soon as it is safe to do so.

Lightning co-author @tdryja discusses his work on post-quantum rescue protocols for Bitcoin — as well as his new @MaelstromFund grant to advance proposals like "Lifeboat" and "Lifejacket." Rescue protocols will almost certainly be a key piece of Bitcoin's quantum-mitigation plan (God willing 🤞), providing real technical solutions to questions like "What do we do with coins that don't move in time?" As always, thanks to @MARAFoundation_ for making this show possible 🫶