nBits

Bitcoin a besoin d'une cible de 256 bits dans un en-tête qui ne peut pas lui consacrer 32 octets, il en stocke donc une version arrondie sur quatre octets. Le premier octet est un exposant, les trois suivants un coefficient, et la cible est le coefficient multiplié par 256 élevé à la puissance de l'exposant moins trois. Chaque nœud recalcule la valeur qu'il attend, donc un en-tête qui annonce une cible plus facile que ce que les règles autorisent est rejeté d'emblée.

Comment cela fonctionne

nBits se lit comme un octet d'exposant suivi d'un coefficient de trois octets, et les deux sont combinés en un nombre complet de 256 bits.

Prenez la valeur portée par le bloc de genèse, 0x1d00ffff. L'exposant est 0x1d, soit 29, et le coefficient est 0x00ffff, soit 65 535. La cible est donc 65 535 multiplié par 2 à la puissance 208, un nombre qui s'écrit avec huit zéros hexadécimaux, puis ffff, puis des zéros pour remplir 64 chiffres. C'est la cible la plus facile que le réseau principal autorise, et c'est la définition de la difficulté 1.

Deux particularités prennent les gens de court. La première est la précision. Un coefficient de seulement 24 bits ne peut pas exprimer un nombre arbitraire de 256 bits, donc la cible encodée est toujours arrondie, et un aller-retour entre la cible et nBits ne redonne pas toujours la valeur de départ. La seconde est le bit de signe. Si le bit de poids fort du coefficient est activé, la valeur est traitée comme négative, donc les encodeurs décalent le coefficient d'un octet vers le bas et augmentent l'exposant pour compenser. C'est pourquoi la valeur de genèse s'écrit 0x1d00ffff plutôt que le plus évident 0x1cffff00, et pourquoi un octet nul en tête à l'intérieur du coefficient est normal et non un bug.

Dans l'en-tête sérialisé, le champ se situe à l'offset d'octet 72 et est écrit en little endian, donc ces quatre octets apparaissent sur le disque et sur le réseau sous la forme ff ff 00 1d.

Où le voir

nBits circule sous plusieurs noms différents, ce qui explique l'essentiel de la confusion qui l'entoure.

Les explorateurs de blocs l'étiquettent « bits » et affichent la valeur hexadécimale à côté d'un chiffre de difficulté plus lisible. L'appel RPC getblock de Bitcoin Core le renvoie sous le nom « bits », et getblocktemplate le transmet au logiciel de minage comme l'exigence qu'un en-tête candidat doit battre. Dans le code source, c'est le membre nBits de CBlockHeader, converti par arith_uint256::SetCompact et GetCompact. Les pools de minage le montrent rarement : Stratum envoie les quatre mêmes octets aux machines dans une notification de tâche, et le firmware n'a jamais à réfléchir à leur signification.

Le champ change aussi selon un calendrier et non en continu. Il reste fixe pendant toute une fenêtre de 2 016 blocs et ne prend une nouvelle valeur qu'à un ajustement de la difficulté, donc deux blocs minés à une heure d'intervalle portent un champ nBits identique, sauf si un ajustement est tombé entre les deux.

nBits vs seuil de cible

nBits est l'encodage ; le seuil de cible est le nombre qu'il encode. Un nœud ne compare jamais directement le hachage d'un en-tête à nBits. Il développe d'abord les quatre octets en une cible complète de 256 bits, puis vérifie que le hachage se situe au niveau de cette valeur ou en dessous. Traiter nBits comme la cible elle-même est acceptable dans une conversation et faux dans le code, car deux valeurs nBits séparées d'une seule unité se décodent en des cibles qui diffèrent d'un montant absolu énorme.