Our next meetup is Thursday September 24! meetup.com/bitdevsnyc/events…

Hot! 🔥 Tonight at BitDevs, @ClaraShik will present the amazing work AllocInit has just published (today!) about private bitcoin transfers without consensus changes. RSVP on meetup or luma: meetup.com/bitdevsnyc/events… luma.com/4l4jywq0

Beer, Brains and Bitcoin TONIGHT! bitdevs.org/2026-09-24-socra… - Liquid Hack - Core Lightning bugs - Consensus changes - Bitcoin Core v32 ! - Quantum threats - LLM threats! - Minor miner mistakes!

See you tomorrow! 6pm at @ChaincodeLabs sponsored by @cakewallet RSVP on Meetup or Luma: luma.com/4l4jywq0 meetup.com/bitdevsnyc/events…

A Bitcoin block can carry full proof of work and still be invalid. I've catalogued 143 established cases from 2010 to 2026, including two previously unreported F2Pool timestamp failures this year. deadmanoz.xyz/posts/2026/inv… 1/4

Because they never share it, here is their Luma: luma.com/4l4jywq0

Imagine paying robin@bitcoin That’s it. The wallet picks the rail: onchain, Lightning, Silent Payments, Ark, Glass Coins,... All behind one handle. spacesprotocol.org

Three more days until our next BitDevs meetup! We are collecting discussion topics, anything you'd love (or hate) to talk about on Thursday? Sponsored by @cakewallet github.com/BitDevsNYC/BitDev…

In August the Core Lightning maintainers told node operators to upgrade or run --offline. There was nothing to upgrade to for another two days, and when v26.06.7 arrived it was binaries only, with the source held back a further two weeks so attackers could not reverse-engineer the fixes. We (me + AI models) used that window. Ten AI models, one public source tree, the same five sentences of prompt, under $100 between them. Every report was hashed into the Bitcoin blockchain with OpenTimestamps as it was finished, nine days before upstream published the source, so none of it can be backdated. Reading source, the models found four of the nine defects the release fixed. Running "strings" on the public download found five more, and one of those is theft that pays for itself: as a forwarding node you refund the sender upstream, and the peer then claims the outgoing HTLC on-chain with the preimage it held the whole time. You pay twice and collect nothing. It was findable because the patched binary carries upstream's own new log line, FUNDS LOSS, which names the function, and the vulnerable code sat in the public v26.06.6 tree throughout. Three models at three price points landed on it within minutes of the download. The embargo hides the patch, but not the mechanism. Write-up: juraj.bednar.io/en/blog-en/2… Full case-study, reports and timestamps: github.com/jooray/CLN-incide…

How is Bitcoin adoption progressing in Burundi? 🇧🇮 Bitcoin adoption in Burundi is steadily gaining momentum, driven by grassroots communities focused on education, technical development, financial inclusion, and building a circular Bitcoin economy. Some of the projects leading this growth: 🔷 BitDevs Gitega (@bitdevsgtga) — A technical Bitcoin community in Gitega inspired by @BitDevsNYC. It hosts meetups, workshops, study groups, and Socratic seminars for developers, builders, educators, and Bitcoin enthusiasts. 🔷 BTC Shule (@btcshule) — A leading initiative building Bitcoin circular economies in communities such as Gitega and Winteko. Through meetups, training, and hands-on education, BTC Shule empowers individuals with the knowledge and tools to use Bitcoin in everyday life. 🔷 Free Tech Institute (FREETI) (@Freeti_Bdi) — A non-profit think tank advancing digital freedom, entrepreneurship, and decentralized technologies through Bitcoin education, youth empowerment, policy advocacy, and community initiatives. 🔷 Rurbit (@rurbit) — Building Bitcoin-powered financial infrastructure for rural and underserved communities, enabling greater financial sovereignty where traditional banking services are limited or unavailable. 🔗 Discover more projects driving Bitcoin adoption across Africa in our directory: directory.bitcoiners.africa

There's some confusion about what, exactly, was exploited here. I've seen claims that this was a long-standing bug, exploited after the "fix" was pushed to the open source repo but before that fix could be rolled out in production. That does not appear to be true. Instead, it seems that the fix *was* deployed, but inadvertently introduced a new bug which was subsequently exploited. Most of the network was still running official releases, none of which contain the new bug. Those nodes correctly rejected the block containing the exploit and stalled at height 4050335. The timeline is roughly as follows: • 2016-07-12: Range proof caching added • 2017-11-08: Range proofs extended to support assets • 2019-03-19: Range proof cache key "simplified", dropping asset & script fields. introduces Bug A. • 2026-09-01: Bug A "fixed" by extending cache key to include asset + script. introduces Bug B. • 2026-09-06: Bug B exploited, reserves drained, chain split. The original "Bug A" allows some limited cache poisoning because the cache key doesn't commit to the asset and script, allowing a cached result for a range proof for one asset to be applied to a different asset or context. Exploiting this in practice looks quite difficult, since the amount must match the primer and the proof must be genuine. The 2026 "fix" added those missing fields to the cache key, producing a format like: "proof | amount | asset | scriptpubkey" But this unfortunately made the key easier to manipulate and exploit: The four fields are concatenated without separators or length indicators. Since both the proof and the scriptpubkey are variable length, an attacker can stretch the proof and shrink the script to produce the exact same cache key from different proofs, amounts, assets and scripts. This lets an attacker smuggle arbitrary confidential output amounts and junk proofs past the range proof checker without proper validation, which breaks the guarantees that prevent hidden inflation. On-chain evidence suggests that this second bug is what was exploited: Two primer transactions each created an op_return with carefully constructed scriptpubkey and valid range proof for a (presumably) zero value output. blockstream.info/liquid/tx/2… blockstream.info/liquid/tx/7… This produced a cache key like: "<valid proof> | <valid amount> | <L-BTC> | OP_RETURN <negative amount> <L-BTC> OP_RETURN" The exploit transaction then created a large negative op_return output with an invalid range proof: blockstream.info/liquid/tx/f… The invalid proof is padded with bytes corresponding to the primer's valid amount and asset fields, aligning the actual amount and asset fields with the same bytes from the primer's opreturn payload: "<valid proof> <valid amount> <L-BTC> OP_RETURN | <negative amount> | <L-BTC> | OP_RETURN" The exploit transaction could then include a second output crediting the attacker with a large positive value, balanced out by the fake negative amount. Because the success was already cached, the invalid proof was never actually checked and the transaction was accepted as valid by nodes running versions of the software vulnerable to bug B. Although the amounts are blinded, this is the only output with an invalid range proof anywhere in the peg-out's recent ancestry, so this must be where the inflated coins were created. And since the padding only produces a cacheable key under the new format, it must have been the newer bug that was exploited.

Liquid hack explained. Liquid has confidential transactions that hide the amounts for improved privacy. A bug in how these transactions are validated caused inflation of Liquid BTC (L-BTC) and allowed hackers to empty the entire side chain. Liquid nodes don't see the amounts of a confidential transaction, so to make sure that the transaction is still valid and doesn't cause inflation nodes check something called a balance proof and a range proof. The balance proof establish that sum of the input amounts equal the output amounts, i.e., that "x L-BTC going in and x L-BTC going out". But there's a catch. Only relying on a balance proof isn't enough. You also need the range proof. The range proof establishes that a hidden output amount falls within a positive range. That means a valid output must be at least 1 L-sat and at most 2^64 − 1 L-sats. Range proofs make sure that you can't mint "negative L-BTC". Why is this even necessary? Remember, the amounts are hidden and a hidden negative amount would allow extra positive outputs to balance against it. Without a range proof, a transaction could say "I've put 1 L-BTC in, and I'm taking two outputs out: one with 4000 L-BTC and one with -3999 L-BTC)." This is going to cause a disaster in a little bit. Once the balance proof, the range proof, and other validations pass, a transaction is regarded as valid and can pass consensus. However, because especially the range proof is computationally expensive, Liquid nodes cache the result of a successful range proof in memory. Essentially, the node remembers "I saw this range proof before and it was valid, all good!". In order to recognize the same range proof later on, you need to assign a label to it. This is called a cache key. This cache key is the actual cause of the bug. The way this cache key was constructed allowed two different transactions to collide on their cache key. Essentially, one valid transaction (1 L-BTC in, 1 L-BTC out) had the same cache key as an invalid transaction (1 L-BTC in, 4000 L-BTC out). Here's the hack: the attackers submitted the valid transaction (1 L-BTC in, 1 L-BTC out) first. Liquid nodes verified this transaction successfully, created a cache key called REKT and stored it in their cache. Then the attackers carefully crafted a second invalid transaction with (1 L-BTC in, 4000 L-BTC out) that created the same cache key REKT. Instead of validating the second transaction and realizing that it printed money out of thin air, Liquid nodes found it in their cache and said "hey I saw this transaction before, everything is fine" and that caused the inflation. The attackers then took their 4000 L-BTC and withdrew 4000 BTC onto the Bitcoin base chain. Note: I might have gotten some details wrong, and I'm aware that I simplified quite a bit. I wrote this post to help people understand what happened. Please feel free to correct me in the comments or add more details below.

here are the transactions that caused the liquid consensus split and inflation bug, prior to the peg-out 1. two valid setup txs primed the rangeproof cache: blockstream.info/liquid/tx/2… blockstream.info/liquid/tx/7… 2. follow-up tx carried a garbage 4234-byte "proof" with an identical cache key that forked the network at block 4050336 and created 3,996.0183 L-BTC blockstream.info/liquid/tx/f… they later then pegged out va sideswap you are only allowed to peg out if ur on the whitelist but i think sideswap just let anyone add their key or something 🫠

We are aware of a security incident on @Liquid_BTC. Purported white-hat hackers have withdrawn ~4,000 BTC (~$320 million) from the Liquid Federation wallet. The @Blockstream team is working on contacting them on-chain with a signed message. What we know so far is that the funds were withdrawn via the SideSwap PAK (Peg-out Authorization Key), but that key was not compromised, nor were any others. Exchanges have been notified and have already paused (or will pause) LBTC deposits and withdrawals. Other Liquid assets such as USDT, DePix, and RWAs are unaffected by this security incident. Bridge nodes have been temporarily disabled, so no new transactions can be submitted to the network. Effectively, the Liquid sidechain is paused until this issue is resolved. Liquid wallets will be impacted, and we're sorry for any inconvenience. Federation members are actively working on resolving this so we can restore normal network activity. You can monitor the situation via @mempool's liquid.network site below: mempool.space/address/bc1qdl…

I wrote a hands-on guide for newbies on how to contribute to Bitcoin OSS. It contains many tips and tricks to A) find something to do and B) survive the first code review without crying (or using `git merge`). Check it out! 🤓 danielabrozzoni.com/posts/co…

Welcome to our live show! nitter.net/i/broadcasts/1yxBePbpl…

New paper! nkohen.github.io/blog/iceber…

See you tonight! @tdryja is in the house -- maybe we can persuade him to explain his "LifeBoat" post-quantum rescue proposal 😍 Sponsored by @cakewallet

Today, we're publishing BIP SHRINCS, the first concrete proposal for a post-quantum signature scheme designed specifically for Bitcoin. The BIP draft turns what began as a rough idea into exact algorithms with an executable reference implementation. This is an important milestone: the discussion can now focus on analyzing, criticizing, and improving a concrete proposal. The BIP makes choices ranging from major design questions, such as whether to support flexible XMSS and how to balance signature size against verification time, to the many smaller decisions involved in saving a byte here or there. All of these choices are up for debate. Big thanks to Mike Casey, @conduition, @Ethan_Heilman, @kudinov_mikhail, @olkurbatov, Boris Nagaev, and @remix7531 for their contributions to the BIP. A lot more work lies ahead: - The draft BIP specifies only the cryptography. Using SHRINCS in Bitcoin Script will require a separate BIP. - We are working on a security proof for the exact construction and parameters. - Wallet integration and user experience, for example around backups and recovery after state loss, are still at an early stage. The design space remains wide open. SHRINCS is not intended to be Bitcoin's "final" signature scheme, and it is not optimal along every axis. I do think it is a very good trade-off among the options we have now. bitcoin-dev post: groups.google.com/g/bitcoind… Draft BIP: github.com/SHRINCS/shrincs-b…

If you run Core Lightning: when the release is published: upgrade with signed binaries, or start your node with `--offline`. Details stay under embargo for two weeks. Previous releases, including 26.04, are unsupported. Full details when the embargo lifts. The 26.09 release is still planned for late September.