BitDevs 31_

The primary source. On September 6 at 15:53 UTC (Liquid block 4,050,336) a vulnerability in how Elements nodes cache range-proof verifications was exploited to create ~4,000 LBTC with no bitcoin behind them. The attacker then pegged out through SideSwap — a federation member holding a peg-out authorization (PAK) key — and because the bad transaction had already been accepted as valid at the transaction level, both SideSwap's node and the functionaries processed the withdrawal as normal. Reserve before: ~4,205 BTC. Reserve after: 197 BTC. Blockstream's framing is careful: no keys compromised, no functionaries hacked, the peg-out mechanism "operated as designed." Discussion hook: if every component operated as designed and the reserve still went to zero, what exactly was the design?

The play-by-play of the recovery. Eleven rounds of OP_RETURN messages between the attacker and Blockstream — PGP signatures, an Electrum tutorial, and a mempool.space accelerator — all settled on the Bitcoin mainchain in public. 27 hours after the fork, block 965,950 (mined by Foundry) confirmed 3,400 BTC back in the federation wallet. Ten minutes later the attacker sent one more encrypted message and kept 598.5 BTC (15%). The "whitehats" demanded a 10% bounty or threatened a 15% loss for holders; Blockstream has not accepted that framing as an authorized bounty. Discussion hook: is a 15% haircut negotiated by OP_RETURN a bug bounty or a ransom — and does the answer change if the funds come back?

The technical spine of the seminar — read this one before you show up. Roose (Second CEO, former Liquid engineer at Blockstream) walks the actual code path. Confidential Transactions, range proofs, and balance verification all worked correctly. The problem was an optimization: range proofs are big and expensive to verify, so Elements caches successful verifications keyed by a hash. The original 2018 cache key left out the asset commitment and scriptPubKey — a real bug, but hard to exploit in practice. Then on September 1 a security patch added the missing fields using raw concatenation, SHA256(proof || commitment || asset || script), with no length prefixes. That is a canonicalization bug: variable-length fields with no delimiters mean two different transactions can produce the same byte string. The attacker sent a "primer" transaction with a valid 4,166-byte proof, then an "exploit" transaction with a forged 4,234-byte proof that, once concatenated with different fields, hashed to the same 4,301-byte cache key. The cache said "already verified," the node skipped the proof, and ~4,000 LBTC appeared. Key line: "Hashing structured data by raw concatenation is unsafe precisely because distinct structures can share a byte encoding." Elements v23.3.4 ships length-prefixed serialization. Discussion hooks: the fix was worse than the bug — what review process catches a security patch that introduces a canonicalization flaw? And why did a sidechain with a federation, PAK keys, and whitelisted addresses have no velocity limit on peg-outs?

Where things stand today. v23.3.4 went out September 9; functionaries updated immediately. Block production resumed September 10 in a three-stage plan: (1) blocks resume with the peg suspended, (2) replay transactions verified as valid, (3) reopen peg-ins and peg-outs only after the corrected network state is restored and funds returned. Adam Back says the 1:1 LBTC:BTC peg "will be covered." SideSwap has admitted two operational failures — its PAK key was kept online so peg-outs cleared in the same Bitcoin block as the order, and it had no size, rate, velocity, or supply-cap checks — and returned ~4 BTC in fees to the federation. Discussion hook: Liquid's whole security model is "trust the federation, verify the chain." Users who verified the chain saw valid blocks. What does verification even mean when the bug is in the verifier?

First release candidate of rust-lightning 0.3. Headline changes: splicing now supports RBF of pending splices and splicing in and out in the same operation; async signing is supported everywhere it should be; anchors zero-fee HTLC channels are now the default and pre-anchor channels are on their way out; zero-reserve anchor channels for trusted peers; any HTLC can be intercepted via htlc_interception_flags; LSPS1 service support and BOLT 12 PayerProofs; BOLT 12 payments can carry payment_metadata; a new PaginatedKVStore with FilesystemStoreV2; and ChainMonitor deferred writes that prevent force-closes from stale ChannelManagers. Also worth noting: primary development moved off GitHub to git.rust-bitcoin.org during this cycle due to persistent GitHub outages, with the GitHub repo mirrored. Backwards-compat gotchas: BOLT 11 invoices issued with payment metadata are invalidated on upgrade, unclaimed BOLT 12 refunds will not be claimable on 0.3, and blinded payment paths from older versions are rejected (existing offers still work). Discussion hook: manual channel acceptance is now mandatory and anchors are the default — how many of the "LDK is too low-level" complaints does 0.3 actually address?