Suivi des messages : liquid group chat. Preuves : liquid-2026-incident-forensics.
Le 6 septembre 2026, en moins d’une heure, environ 4 000 BTC quittent le wallet Bitcoin qui adosse le L-BTC sur Liquid (~320 M$ à l’époque). Ce n’est pas une rumeur de Discord : d’abord une inflation de L-BTC non adossés sur la sidechain, puis un peg-out qui convertit ces jetons en vrais bitcoins. Peu après, une adresse publie dans un OP_RETURN : We are whitehats. Contact us on chain. Blockstream et Liquid parlent, eux, de purported white-hat hackers : auto-proclamés, pas un label prouvé.
Ce qui suit est une négociation publique sur Bitcoin. Poussière de 1 000 sats pour signaler un message, chiffrement PGP ou Electrum quand le contenu est sensible, un retour de 3 400 BTC (~85 %), un :(, puis du clair et un ultimatum sur les ~15 % restants. Le 9 septembre sort Elements v23.3.4 (cache des range proofs). Le 10, une reprise d’ops contrôlée commence. En parallèle : un nœud Elements peut-il réutiliser à tort le résultat d’une vérif crypto déjà faite, et accepter une transaction qu’il aurait refusée à froid ?
Voici ce fil, sans thriller. Pour lire les OP_RETURN utiles sans le spam, il existe une interface tierce, liquid group chat. Ce n’est pas un salon officiel. C’est un lecteur qui ignore pubs de memecoins et demandes d’argent collées sur l’adresse devenue célèbre, et ne garde que ce qui est authentifié : dépense depuis les bitcoins du présumé whitehat, ou signature PGP valide contre la clé Blockstream.
De quoi parle-t-on ? Liquid, Elements, Blockstream
Trois noms. Pas interchangeables.
Liquid (Liquid Network) est une sidechain de Bitcoin : une chaîne à part, branchée sur Bitcoin par un peg bidirectionnel. On y envoie du BTC pour obtenir du L-BTC (en principe à 1:1, garanti par des BTC bloqués côté Bitcoin). On peut aussi y émettre d’autres actifs (stablecoins, etc.). Les blocs sont rapides (de l’ordre d’une minute). Beaucoup de montants et d’assets peuvent être confidentiels. Liquid n’est pas minée comme Bitcoin : un consortium d’entreprises (exchanges, infrastructures…), la Liquid Federation, fait tourner des functionaries qui co-signent les blocs et gèrent le peg.
Elements est le logiciel open source (fork / extension de Bitcoin Core) sur lequel Liquid est construit. C’est le code du nœud (elementsd), avec confidential transactions, assets natifs, peg fédéré, signature de blocs, etc. Quand on parle d’Elements v23.3.4, on parle d’une version de ce logiciel, pas d’une autre blockchain.
Blockstream est l’entreprise qui développe et fournit une grande partie de la techno (Elements, outils, etc.) et qui, dans cet incident, publie les updates et signe une partie des messages on-chain avec sa clé PGP security@. Blockstream n’est pas à elle seule toute la Liquid Federation. Sur Liquid, elle apparaît surtout comme fournisseur techno et interlocuteur public pendant la crise.
En une phrase : Liquid = le réseau en production. Elements = le code du nœud. Blockstream = l’éditeur / acteur qui communique et patch ici.
Pourquoi on-chain, et pas un simple e-mail ?
Un e-mail ou un ticket support laisserait des métadonnées (serveurs, horaires, parfois une identité). Parler on-chain, en ne signant qu’avec le contrôle des coins, permet au présumé whitehat de négocier sans coller un pseudonyme Web, une boîte mail ou un compte Telegram à cette adresse. Le message est public, mais le canal reste celui des UTXO. C’est paradoxal : tout le monde peut lire le fil, et pourtant c’est souvent plus confortable, côté anonymat opérationnel, que d’ouvrir une boîte mail traçable. Blockstream authentifie une partie de ses réponses avec sa clé PGP publiée, y compris quand les bitcoins partent d’adresses de change différentes de la première adresse de contact.
Comment ~4 000 BTC sont sortis (sans piratage de clés annoncé)
Le point que beaucoup d’analyses soulignent, et qu’il faut poser avant le feuilleton des messages : Liquid et SideSwap ont déclaré que la PAK SideSwap et, plus largement, qu’il n’y a pas eu de compromission des clés du peg. Ce n’est pas une preuve négative on-chain. C’est leur récit officiel, cohérent avec un bug de validation plutôt qu’un vol de clés. Le chemin observé / reconstruit ressemble à ceci.
1. Priming sur Liquid. Avant le gros coup, des transactions Liquid de « setup » apparaissent (notamment 71c9… et 2711… au bloc 4050335). Elles sont des candidats cryptographiques : leurs sorties peuvent produire la même clé de cache post-fix qu’une sortie d’attaque (alias). Leur rôle plausible : présenter des range proofs valides pour écrire une entrée dans le cache. Limite importante (CertiK, et nos missions) : connecter le bloc 4050335 consomme l’entrée de cache. Le primer effectif qui aurait rechargé le cache juste avant f24a (tx mempool / live, après 4050335) n’est pas identifié publiquement.
2. Inflation / mint. Vers 13:53 UTC le 6 septembre (bloc Liquid 4050336, tx f24a…), une transaction crée de l’ordre de ~4 000 L-BTC non adossés : du L-BTC que le réseau accepte, alors qu’aucun BTC supplémentaire n’a été déposé côté Bitcoin pour les garantir (le peg-in normal : on bloque du BTC sur Bitcoin, on reçoit du L-BTC). En labo, sur le mécanisme de cache : sans entrée déjà présente, secp256k1_rangeproof_verify échoue sur la preuve de l’alias. Si un priming a déjà enregistré la même clé, CachingRangeProofChecker peut renvoyer validé en consultant le cache, sans rappeler la vérification rangeproof complète. La construction on-chain colle à cette famille d’alias. Quel binaire tournait sur chaque nœud le jour J, et quel primer live a servi, reste non démontré ici.
3. Peg-out via SideSwap. Selon SideSwap et des analyses publiques (CertiK, Chainalysis, TRM…), ces L-BTC passent par SideSwap, membre de la Liquid Federation qui opère un service de sortie L-BTC → BTC. Vers 14:05 UTC environ, une demande client y serait traitée : burn des L-BTC sous autorisation valide, avec sa PAK (Peg-out Authorization Key). SideSwap et Liquid ont dit que cette PAK n’était pas compromise. Le bug allégué est dans Elements (validation des preuves), pas dans la garde d’une clé privée volée.
4. Sortie des BTC. Les functionaries (les machines des membres de la Liquid Federation qui co-signent) approuvent le peg-out comme d’habitude, via un multi-signature à seuil. Vers 14:28 UTC, environ 3 996 BTC quittent le wallet Bitcoin du peg (bc1qdlld6…). Ils passent d’abord par une adresse intermédiaire (bc1qgslsy…, souvent appelée hop : une étape entre le peg et la destination finale), puis rejoignent bc1ql4mfu…. En une demi-heure environ : mint → BTC. La presse cite souvent qu’un mouvement de cette taille représentait de l’ordre de ~95 % des BTC alors détenus pour adosser le L-BTC.
Autrement dit : si le récit SideSwap tient, le service de peg-out a traité correctement une demande portant sur des L-BTC que le consensus venait d’accepter à tort. Les signatures du peg-out étaient authentiques. La réserve Bitcoin derrière le L-BTC, elle, ne correspondait plus.
L’argent est dehors, les messages commencent
L’adresse bc1ql4mfu… porte ensuite tout le récit côté présumé whitehat.
Pour publier un texte on-chain, il faut une transaction Bitcoin avec une sortie OP_RETURN (le texte) et, ici, souvent 1 000 sats vers l’autre partie pour attirer l’attention. Ces txs sont signées avec les clés des UTXO du présumé whitehat : frais de miner, change éventuel, rien de magique. Premier message public : we are whitehats. contact us on chain.
Dans la soirée (annonce publique vers 22 h 25), Liquid / Blockstream confirment l’incident sur X. ~4 000 BTC (~320 M$). Purported white-hat hackers. Contact on-chain avec message signé en cours. PAK SideSwap non compromise. Exchanges prévenus pour geler dépôts / retraits L-BTC. Autres actifs Liquid (USDT, DePix, RWA, etc.) présentés comme non touchés. Bridge nodes coupés : plus de nouvelles txs soumises, sidechain en pause. Lien mempool vers le wallet Bitcoin du peg (bc1qdlld6…).
Blockstream répond aussi on-chain (bc1qn8mgs…, puis d’autres UTXO). Premier réflexe visible : Please contact security@blockstream.com. Puis des OP_RETURN chiffrés (BIE1 vers la clé liée à bc1ql4mfu…, ou PGP vers Blockstream). Sur l’interface de suivi : on voit qu’un message chiffré existe, éventuellement une signature PGP valide. Sans la clé privée, le contenu reste illisible.
Le présumé whitehat ne renvoie pas immédiatement les bitcoins. Condition : corrigez d’abord le bug (« chain under risk at latest commit »), patchez tous les nœuds, ensuite le gros du montant sera rendu, détails chiffrés. Blockstream signe « Yes, thank you. », puis plusieurs fois : bridge nodes patchés, safe to return. Nouvelle confirmation d’adresse. Le 7 septembre vers 16:09 UTC, 3 400 BTC reviennent au peg. Environ 598,5 BTC restent chez le présumé whitehat (~15 %, ~47 M$ selon les valorisations alors citées). Pas d’OP_RETURN dans ce transfert.
Après le transfert de 3 400 BTC
Les OP_RETURN chiffrés reprennent. Blockstream publie même un mode d’emploi BIE1 / Electrum à côté d’un ciphertext. Le présumé whitehat renvoie du PGP vers security@. Vers 21 h : :(.
Le 8 septembre, Blockstream continue en BIE1 (souvent signé PGP). Vers 14 h 25 UTC, le présumé whitehat annonce : All messages will be in plaintext. Autrement dit : les prochains messages seront en clair, plus en PGP / BIE1. Les anciens messages chiffrés ne s’ouvrent pas pour autant.
Le lendemain, un long OP_RETURN lisible par tous accuse Blockstream de sous-investissement sécu, exige un bug bounty de 10 % « avec votre propre argent », menace une perte de 15 % pour les holders de L-BTC en cas de refus, et annonce la publication ultérieure d’une clé pour déchiffrer les anciens OP_RETURN. Citation on-chain, pas un audit de budget. Asymétrie : le présumé whitehat écrit en clair. Blockstream répond encore souvent en BIE1 clearsigné.
L’interface de suivi se met à jour avec les nouveaux OP_RETURN authentifiés. Cet article reste une photo à une date donnée.
Pendant ce temps, sur le réseau Liquid
Dès le 6 septembre au soir : incident reconnu, PAK présenté comme non compromis, L-BTC gelé côté exchanges, bridges coupés, sidechain en pause.
Le 9 septembre (13:30 UTC) : release d’urgence Elements v23.3.4. Functionaries à jour tout de suite. Tous les opérateurs de nœuds invités à suivre. Le texte dit que cette version traite la vulnérabilité du cache de vérification des preuves (clés de cache des range proofs). Revues internes / externes (Bitcoin Red Team, Alpen Labs, etc.).
Plan de recovery (encore révisable) :
- reprendre la production de blocs pendant que le peg reste suspendu
- rejouer les transactions vérifiées comme valides
- rouvrir le peg une fois l’état restauré, y compris un retour de fonds
Les deux premières étapes sont testées en parallèle. Aucune n’avance tant qu’elle n’est pas jugée sûre.
Le 10 septembre (10:00 UTC) : phase suivante. Blocs sans transactions, le temps de stabiliser. Functionaries / bridge à jour selon eux. Peg (y compris peg-outs PAK) toujours suspendu, restauration de la réserve BTC / L-BTC en cours. Alerte arnaques / faux sites d’update.
Deux horloges : remettre Liquid en route. Négocier sur Bitcoin au sujet des BTC encore chez le présumé whitehat. L’une n’efface pas l’autre.
Et le bug, dans tout ça ?
Sur Liquid, les sorties confidentielles s’accompagnent de range proofs (secp256k1-zkp) : la preuve lie un Pedersen commitment de valeur à un générateur d’asset, et optionnellement à des données extra (scriptPubKey comme extra_commit). Vérifier ça coûte cher. Elements mémorise certains succès dans un cache de process (CachingRangeProofChecker / ComputeEntryRangeProof).
Deux problèmes distincts autour de la clé du cache
Il est important de distinguer deux problèmes conceptuellement différents.
Le défaut de liaison de contexte (pré-durcissement) concernait l’isolation du contexte de validation. Avant le durcissement, la clé du cache des range proofs ne liait pas suffisamment la preuve à l’ensemble du contexte de sortie. Schématiquement, elle pouvait être représentée comme :
proof + value commitment
L’asset et le scriptPubKey n’étaient donc pas suffisamment pris en compte dans l’identité de l’entrée de cache. Une vérification valide pouvait ainsi être mémorisée puis réutilisée dans un contexte différent.
Le problème distinct concerne la nouvelle construction de clé du correctif. Celui-ci cherche justement à lier la clé au contexte en ajoutant notamment l’asset et le scriptPubKey. Mais si ces champs sont simplement concaténés sans encodage permettant de délimiter leur longueur ou de rendre leur représentation non ambiguë, la séquence de bytes résultante peut elle-même être ambiguë : des champs différents peuvent être découpés de plusieurs manières tout en produisant la même concaténation.
Il ne s’agit donc pas d’une collision cryptographique de SHA-256. Le problème se situe en amont, dans la construction sérialisée des données qui sont ensuite hachées : c’est une ambiguïté de représentation permettant un aliasing de la clé du cache.
Cette distinction est importante : le premier problème concerne l’absence de liaison suffisante entre la preuve et son contexte ; le second concerne une construction de clé censée justement renforcer cette liaison, mais dont la concaténation peut rester ambiguë.
En labo : le primer a une preuve que secp256k1_rangeproof_verify accepte. L’alias échoue si le cache est vide. Si le primer a déjà écrit l’entrée, le checker peut accepter l’alias sans refaire la crypto. Ce n’est pas « deux préimages différentes, même SHA-256 ». C’est la même préimage, mal découpée. Locus : CheckTxInputs → VerifyAmounts → CRangeCheck.
Point disclosure (hypothèse, pas fait). Calendrier public utile : AuthorDate du fix autour d’août 2026, commit / PR (c26d719, #1592) visibles vers le 1er septembre, alors qu’aucune release taguée contenant le fix n’était encore en prod (ex. 23.3.3 encore pré-fix). Un merge pertinent côté master intervient après l’attaque du 6 (~17:21 UTC, après le mint 13:53). Plusieurs articles en déduisent qu’un attaquant a pu lire un diff public avant déploiement. On ne le prouve pas ici. On note surtout le décalage code visible / release déployée, classique sujet de coordinated disclosure.
Limite épistémique : mécanisme confirmé en laboratoire. La construction on-chain est cohérente, selon plusieurs analyses publiques (dont CertiK), avec la construction de clé à quatre champs non délimitée, plutôt qu’avec l’ancienne clé à deux champs. Les reproductions en laboratoire vont plus loin et montrent que cette construction à quatre champs peut produire l’aliasing de clé de cache octet pour octet. Cela confirme le mécanisme d’exploit en conditions contrôlées, mais n’établit pas quel binaire exact, quel état du runtime, quel contenu de cache, ni quel primer live était présent sur chaque functionary lors de l’incident historique, et ne prouve pas non plus que le primer reproduit soit celui utilisé le 6 septembre.
Détail, fixtures, limites ConnectBlock : repo, surtout final/28_red_team_review.md et missions suivantes.
Ce que j’ai essayé de documenter
Le dépôt liquid-2026-incident-forensics n’est pas un journal des OP_RETURN. C’est un pack de reproduction et de limites : aliasing de clé de cache, chemin dans Elements, ce qui reste bloqué (ex. expérience hot/cold sur vrai elementsd post-fix). Chronologie BTC filtrée et images en snapshot, pas en remplaçant de l’interface de suivi.
En résumé : group-chat pour le fil public filtré. Repo pour le mécanisme et le niveau de preuve.
Ce qu’on ne sait toujours pas
Le contenu des messages publiés via OP_RETURN encore chiffrés (PGP ou BIE1). Runtime exact de chaque nœud le jour J. Primer live après 4050335. Suite des ~598 BTC encore chez le présumé whitehat. Publication ou non de la clé annoncée pour déchiffrer les anciens messages. Les updates des 9-10 septembre décrivent v23.3.4 et un recovery par étapes, avec peg encore fermé. Ils ne ferment pas la négociation on-chain. Tant que ce n’est pas sur la chaîne ou une source vérifiable, mieux vaut ne pas inventer la fin.
Sources utiles : liquid group chat, repo forensics, chronologie image final/data/btc_3400_opreturn/chronology.jpg, blockstream.com/pgp.txt, annonces Liquid / Blockstream des 6, 9 et 10 septembre 2026. Analyses publiques convergentes sur le chemin mint → SideSwap → BTC et sur l’encoding de clé de cache : entre autres CertiK, Chainalysis, TRM Labs, Decrypt.
Mechanism confirmed in lab. Historical incident causality remains unproven.