Clé publique non compressée

Les premiers logiciels de Bitcoin enregistraient les valeurs x et y complètes, ce qui explique que des bitcoins de 2009 et 2010 se trouvent derrière des adresses dérivées de clés de 65 octets. SegWit a ensuite fermé la porte à ce format, puisque le BIP-143 interdit les clés non compressées dans les programmes témoins de version 0 et qu'aucune adresse bc1q ne peut en utiliser une. Si vous récupérez un ancien portefeuille papier, c'est le détail qui décide si vos fonds apparaissent.

Comment cela fonctionne

Une clé publique non compressée a une structure aussi littérale que son nom. Un octet de préfixe 0x04 annonce le format, puis 32 octets donnent la coordonnée x, puis 32 octets donnent la coordonnée y, soit 65 octets au total. Rien n'a besoin d'être calculé pour la lire : les deux moitiés du point sont déjà là, et c'est exactement pourquoi l'implémentation d'origine l'a choisie sur le matériel de l'époque.

Les règles de validité n'ont jamais isolé ce format à la couche de base. Un nœud qui vérifie une dépense héritée pay-to-public-key-hash ou pay-to-script-hash accepte une clé non compressée sans se plaindre, et des bitcoins verrouillés sur une telle clé en 2010 restent dépensables sans échéance. Ce qui a changé, c'est tout ce qui s'est construit par-dessus : les portefeuilles BIP-32 ne dérivent que des clés compressées, donc une phrase de récupération ne peut jamais produire une clé non compressée, et SegWit les a rendues invalides dans les dépenses de version témoin 0.

Le coût des 32 octets supplémentaires est payé au moment de la dépense. Une entrée héritée portant une clé compressée fait environ 148 vbytes ; la même entrée avec une clé non compressée fait environ 180 vbytes, soit environ 22 pour cent de plus pour une dépense identique. Consolider une douzaine de telles entrées pendant une flambée de frais, c'est là que cette différence cesse d'être anecdotique.

Où la rencontre-t-on

Trois artefacts remettent encore des clés non compressées entre les mains des utilisateurs, et tous les trois datent de la même époque.

Les portefeuilles papier imprimés par les sites générateurs de 2011 à 2013 produisaient généralement une adresse commençant par 1 et une chaîne Wallet Import Format commençant par 5, le marqueur du versant non compressé du format. Les pièces physiques de la série Casascius, frappées entre 2011 et 2013, cachaient le même type de chaîne sous un hologramme inviolable. Et les clés privées exportées de logiciels de portefeuille très anciens sont antérieures au changement.

Récupérer une ancienne clé

Le piège n'est pas l'encodage, c'est qu'une seule clé privée produit deux adresses différentes. Hacher la clé de 65 octets donne une adresse héritée ; hacher la version compressée de 33 octets de la même clé en donne une complètement différente. Importez la clé dans un logiciel moderne qui suppose la compression et le solde peut sembler nul alors que les bitcoins restent intacts à l'autre adresse.

Les portefeuilles qui traitent bien les anciens éléments, dont Electrum, vérifient les deux dérivations lorsque vous balayez une clé au lieu de l'importer. Le balayage est aussi l'opération la plus sûre : il déplace les bitcoins vers une adresse contrôlée par votre phrase de récupération actuelle, de sorte qu'une impression restée dans un tiroir, photographiée par un téléphone ou vue par un ancien propriétaire ne peut plus rien dépenser. Vérifiez les deux formes d'adresse sur un explorateur de blocs avant de conclure qu'une récupération a échoué.