La norme de facture BOLT11 exige désormais exactement un hash de paiement et un secret de paiement. Tout champ manquant ou répété doit entraîner l’échec du paiement. Les développeurs de Lightning ont adopté cette modification le 19 octobre, après qu’une attaque signalée a montré comment des parseurs de factures divergents pouvaient faire apparaître comme impayés des retraits de Bitcoin pourtant réalisés. Le compte rendu de l’incident ne précisait ni date ni montant des pertes.
Pourquoi c’est important
La vulnérabilité provenait de composants logiciels qui interprétaient différemment la même demande de paiement signée. Un parseur pouvait sélectionner le premier champ de hash de paiement, tandis qu’un autre retenait le dernier. Un service pouvait ainsi enregistrer un retrait sous un hash alors que son nœud exécutait le paiement sous un autre, amenant le système comptable à considérer comme impayé un retrait déjà effectué et pouvant déclencher un nouveau versement.
La nouvelle règle couvre à la fois les hash de paiement et les secrets de paiement. Les implémentations doivent compter les occurrences des champs, y compris lorsque des valeurs identiques sont répétées, au lieu de les regrouper en une seule entrée. Une facture contenant deux hash distincts et une facture répétant le même hash sont toutes deux invalides selon la spécification mise à jour.
Impact sur le marché
L’impact immédiat est opérationnel, et non un signal direct sur le cours du Bitcoin. Les opérateurs de paiement doivent rejeter les factures ambiguës et s’assurer que le suivi comptable utilise le même hash de paiement que le nœud. Cette modification met également en évidence un risque plus large pour les infrastructures crypto : des données signées peuvent malgré tout provoquer des erreurs lorsque différents logiciels interprètent leurs champs de manière incohérente.
Le logiciel de nœud lnd a intégré le rejet des hash en double le 23 septembre. Ses versions v0.20.5-beta et v0.21.4-beta incluent cette correction. Une proposition distincte portant sur la validation des secrets de paiement et d’autres contrôles du décodeur était toujours ouverte au 27 octobre, et un décodage réussi ne garantit pas à lui seul qu’un paiement sera finalisé.
Questions fréquemment posées
-
Qu’est-ce qui a changé dans la norme de facture BOLT11 ?
BOLT11 exige désormais exactement un hash de paiement et un secret de paiement. Tout champ manquant ou répété doit entraîner le rejet de la facture.
-
Comment des parseurs divergents pouvaient-ils faire apparaître un retrait de Bitcoin comme impayé ?
Un parseur pouvait utiliser le premier hash de paiement, tandis qu’un autre retenait le dernier. Un service pouvait alors suivre un hash différent de celui utilisé par son nœud pour exécuter le paiement.
-
Quel type d’attaque a provoqué la modification des règles de BOLT11 ?
Une attaque signalée contre un bot pair-à-pair sur Telegram a exploité les différences entre bibliothèques de factures. Des retraits de Bitcoin réalisés semblaient impayés, créant la possibilité de nouveaux versements.
-
Quelles versions de lnd incluent le rejet des hash en double ?
La correction du rejet des hash en double a été intégrée le 23 septembre et figure dans lnd v0.20.5-beta et v0.21.4-beta.
-
Les contrôles des secrets de paiement sont-ils déjà finalisés dans lnd ?
Non. Une proposition distincte de lnd couvrant la validation des secrets de paiement et d’autres contrôles du décodeur était toujours ouverte au 27 octobre.
CoinDesk
CZ Binance
TheBlock
WuBlockchain