Le service de vestiaire au mariage où je travaillais utilisait des tickets en papier numérotés — on déchirait une moitié, on gardait l’autre, un manteau par numéro. C’était simple, tant que la machine n’imprimait chaque numéro qu’une seule fois.
Ça s’est coincé à mi-chemin de la nuit et la machine s’est mise à réimprimer des numéros qui avaient déjà été distribués. Deux personnes se sont présentées en tenant le ticket n°114. Il n’y avait qu’un seul manteau accroché sous ce numéro.
Le mot qui convient, autant que je puisse en juger : le ticket en plus — une demande émise plus d’une fois, parce que tout ce qui imprime les demandes ne vérifie jamais ce qui est réellement accroché derrière. Les jetons de liquid-staking Bitcoin portent la même exposition : un reçu est frappé en fonction d’un dépôt, et il n’est honnête que dans la mesure du code qui le frappe.
En mars, le coffre BRO de Solv Protocol a permis qu’un dépôt de 1 BTC frappe plus de SolvBTC qu’il ne devrait. Un bug de réentrance a permis à un seul dépôt de NFT de déclencher une callback qui a émis un second lot de jetons avant que le premier mint ne soit terminé — la société de sécurité Halborn a retracé ça à cette voie de double-mint, pour environ 2,7 M$ . Les utilisateurs ont été remboursés, mais pendant un moment, le jeton de reçu a dépassé le Bitcoin qui le sous-tendait.
L’intégration de staking de Babylon, elle, saute l’étape du jeton de reçu pour exactement cette raison. Un coffre de BTC staké comporte trois conditions de dépense pré-signées dès la création — désengager, liquider, slash — appliquées directement par le script Bitcoin lui-même, et non par un mint de contrat intelligent qui émettrait une demande par-dessus le dépôt. Il n’y a pas de second token qui pourrait être émis deux fois, parce qu’il n’y a pas de token.
Ce qui me reste en tête : Solv pourrait corriger son contrat après l’exploit et rembourser les utilisateurs. Un coffre pré-signé ne peut pas être corrigé — quelles que soient les conditions signées à la création, ce sont les conditions pour toute la vie de ce coffre. Échanger un bug qu’on peut corriger contre une erreur qu’on ne peut pas corriger, c’est un risque d’un autre type.
Le ticket n°114 est le numéro dont je me souviens encore, plus que du manteau lui-même.
Ma propre demande de retrait depuis le testnet est toujours bloquée dans sa période de contestation — je ferai un retour une fois que ça aura réellement atterri dans le portefeuille, pas seulement sur le tableau de bord.
@BabylonLabs_io $BABY #baby
Ça s’est coincé à mi-chemin de la nuit et la machine s’est mise à réimprimer des numéros qui avaient déjà été distribués. Deux personnes se sont présentées en tenant le ticket n°114. Il n’y avait qu’un seul manteau accroché sous ce numéro.
Le mot qui convient, autant que je puisse en juger : le ticket en plus — une demande émise plus d’une fois, parce que tout ce qui imprime les demandes ne vérifie jamais ce qui est réellement accroché derrière. Les jetons de liquid-staking Bitcoin portent la même exposition : un reçu est frappé en fonction d’un dépôt, et il n’est honnête que dans la mesure du code qui le frappe.
En mars, le coffre BRO de Solv Protocol a permis qu’un dépôt de 1 BTC frappe plus de SolvBTC qu’il ne devrait. Un bug de réentrance a permis à un seul dépôt de NFT de déclencher une callback qui a émis un second lot de jetons avant que le premier mint ne soit terminé — la société de sécurité Halborn a retracé ça à cette voie de double-mint, pour environ 2,7 M$ . Les utilisateurs ont été remboursés, mais pendant un moment, le jeton de reçu a dépassé le Bitcoin qui le sous-tendait.
L’intégration de staking de Babylon, elle, saute l’étape du jeton de reçu pour exactement cette raison. Un coffre de BTC staké comporte trois conditions de dépense pré-signées dès la création — désengager, liquider, slash — appliquées directement par le script Bitcoin lui-même, et non par un mint de contrat intelligent qui émettrait une demande par-dessus le dépôt. Il n’y a pas de second token qui pourrait être émis deux fois, parce qu’il n’y a pas de token.
Ce qui me reste en tête : Solv pourrait corriger son contrat après l’exploit et rembourser les utilisateurs. Un coffre pré-signé ne peut pas être corrigé — quelles que soient les conditions signées à la création, ce sont les conditions pour toute la vie de ce coffre. Échanger un bug qu’on peut corriger contre une erreur qu’on ne peut pas corriger, c’est un risque d’un autre type.
Le ticket n°114 est le numéro dont je me souviens encore, plus que du manteau lui-même.
Ma propre demande de retrait depuis le testnet est toujours bloquée dans sa période de contestation — je ferai un retour une fois que ça aura réellement atterri dans le portefeuille, pas seulement sur le tableau de bord.
@BabylonLabs_io $BABY #baby