pinned tweet for threads

Congrats to Vladimir "astOwOlfo" Ivanov the eleventh Winner of the Hutter Prize

I've resurrected the comonad.com/reader, interleaved a ton of contemporaneous content I had stored elsewhere, and made a couple of the articles interactive by moving their demo code into web assembly using modern GHC. Please let me know if you run into any issues. #Haskell

counterexamples.org/subtypin… doi.org/10.1093/comjnl/32.4.… courses.cs.cornell.edu/cs412… eli.thegreenplace.net/2018/c… ericlippert.com/2007/10/19/c…

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.

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 🫠

Still the most under-appreciated American songwriting genius of the past four decades.

Bad year for Bitcoin treasury companies! Turns out buying Bitcoin and buying businesses that buy Bitcoin aren't the same trade.

What if gravity wasn’t exactly inverse square? Left: F ∝ 1/r² → Perfect, usual closed elliptical orbit Right: F ∝ 1/r^{2.01} → Just 0.5% different… and the orbit no longer closes. It slowly precesses, painting this hypnotic rosette pattern

Cheating and picking two