Clé publique compressée

Chaque point de secp256k1 a deux valeurs possibles de y pour un x donné, et indiquer laquelle est la bonne coûte donc un seul octet plutôt que 32. Les portefeuilles génèrent des clés compressées par défaut depuis Bitcoin Core 0.6, publié en mars 2012, et les octets économisés réduisent la taille de chaque entrée que vous dépensez ensuite. Un coût de dépense plus faible est le seul gain, et le format reste invisible à l'usage quotidien.

Comment cela fonctionne

La compression de clé publique relève de l'algèbre, non de la compression de données. L'équation de la courbe, y au carré égale x au cube plus 7, a au plus deux solutions pour y à un x donné, et ces deux solutions sont toujours un nombre pair et un nombre impair. Stocker x plus un bit d'information sur la solution applicable suffit donc à quiconque pour retrouver le point exactement, en résolvant l'équation et en retenant la racine de bonne parité.

L'encodage place ce bit dans l'octet de tête. Un préfixe 0x02 signifie que la valeur de y est paire, 0x03 qu'elle est impaire, et les 32 octets qui suivent sont la coordonnée x. Longueur totale : 33 octets. L'ancien format s'annonce par un préfixe 0x04 et porte les deux coordonnées en entier, pour 65 octets. Tout logiciel qui lit une clé distingue les deux formes au seul premier octet, ce qui a permis aux portefeuilles de rester compatibles pendant la transition.

Les 32 octets économisés se logent à des endroits différents selon le type de sortie. Dans une entrée héritée, la clé figure dans le script de déverrouillage et est facturée au poids plein, donc 32 octets coûtent 32 vbytes, soit environ 640 satoshis à un taux de frais de 20 sat/vB. Dans une entrée SegWit, la clé figure dans le witness, dont le coût est divisé par quatre, donc les mêmes 32 octets coûtent 8 vbytes. Aucun des deux chiffres n'est spectaculaire en soi, et les deux se répètent à chaque entrée de chaque transaction que vous signez.

Où la voir

Vous rencontrez des clés compressées dans les données brutes de transaction. Ouvrez n'importe quelle dépense récente dans un explorateur de blocs et la clé publique du witness ou du script commencera par 02 ou 03, suivie de 64 caractères hexadécimaux. Les clés commençant par 04 sont des vestiges.

Le format détermine aussi l'aspect d'une adresse. Le hachage d'une clé compressée donne un résultat différent du hachage de la version non compressée de la même clé, donc une clé privée peut correspondre à deux adresses héritées entièrement distinctes, avec des soldes distincts. Les portefeuilles traitent cela par convention plutôt que par ingéniosité : tout ce qui est dérivé via le BIP-32, ce qui couvre tous les portefeuilles à phrase de récupération d'usage courant, est compressé de bout en bout, et une chaîne au format Wallet Import Format commençant par K ou L annonce que la clé appartient au côté compressé de cette bifurcation.

SegWit a supprimé l'ambiguïté définitivement. Le BIP-143 interdit les clés non compressées dans les programmes witness de version 0, donc toute adresse bc1q est compressée par règle, et Taproot est allé plus loin en définissant des clés x-only de 32 octets qui suppriment entièrement l'octet de parité.

Clé publique compressée vs clé publique non compressée

Les formes compressée et non compressée encodent le même point, et la différence tient seulement à ce qu'il faut écrire. La forme compressée conserve x et dérive y au besoin, ce qui coûte quelques microsecondes de calcul et économise 32 octets pour toujours. La forme non compressée stocke y directement, ce qui économisait du calcul sur le matériel de 2009 et n'apporte plus rien aujourd'hui. Comme les deux chaînes d'octets diffèrent, elles donnent par hachage des adresses différentes, et c'est cette divergence, plutôt que le nombre d'octets, qui immobilise parfois des fonds issus de portefeuilles très anciens.