Le livre blanc de Bitcoin expliqué simplement

Le livre blanc de Bitcoin propose une façon de faire des paiements en ligne sans tiers de confiance. Il avance étape par étape, en reliant des briques connues (signatures, horodatage, preuve de travail) pour résoudre un problème concret : empêcher qu’une même monnaie numérique soit dépensée deux fois. Voici le document expliqué dans l’ordre de ses idées, avec un exemple unique qui revient tout du long.

1) Le problème : éviter la double dépense sans arbitre

Imagine une pièce numérique unique, appelée ici coinX. Alice veut payer Bob avec coinX. Sans banque ni plateforme centrale, le risque est qu’Alice envoie coinX à Bob, puis envoie ce même coinX à Charlie : deux receveurs pensent avoir reçu la même pièce. Le livre blanc part de ce point : il ne suffit pas de signer un message, il faut aussi que le réseau s’accorde sur quelle dépense est la première et que la seconde soit rejetée.

L’idée directrice est de remplacer l’arbitre par une règle publique d’ordre des transactions, difficile à falsifier : un registre distribué où les transactions sont regroupées et horodatées.

2) Transactions et signatures : la chaîne de propriété

Le texte décrit une transaction comme un transfert qui s’appuie sur des signatures numériques. Simplifions : chaque personne possède une paire de clés (publique/privée). Pour dépenser coinX, Alice doit produire une signature avec sa clé privée, et tout le monde peut vérifier la signature avec sa clé publique.

Dans l’exemple, coinX appartient à Alice parce qu’une transaction précédente l’a désignée comme destinataire. Pour payer Bob, Alice crée une nouvelle transaction qui référence la précédente (celle qui lui donnait coinX) et signe l’ensemble, indiquant la clé publique de Bob comme nouveau propriétaire. Bob vérifie : (1) que la transaction précédente existe, (2) que la signature d’Alice est valide, (3) que coinX n’a pas déjà été dépensé ailleurs.

Le point (3) est le cœur du problème : vérifier l’absence d’une dépense concurrente nécessite une vision partagée de l’historique accepté.

3) Horodatage en blocs : organiser l’historique

Le livre blanc introduit ensuite une manière d’horodater un lot de transactions : les blocs. Un bloc contient un ensemble de transactions et un lien vers le bloc précédent. Ce lien est un hachage (une empreinte) du bloc précédent : si on modifie l’historique, les empreintes ne correspondent plus, ce qui révèle la falsification.

Reprenons coinX. Si la transaction “Alice → Bob” est incluse dans un bloc accepté par le réseau, elle fait partie d’un historique public. Si Alice tente ensuite “Alice → Charlie” avec la même entrée, les nœuds verront qu’une dépense du même coinX est déjà enregistrée.

Mais un adversaire pourrait essayer de publier une autre branche d’historique où “Alice → Charlie” apparaît à la place. Le texte enchaîne logiquement : il faut une règle pour choisir quelle branche est la “vraie”.

4) Preuve de travail et consensus par travail cumulé

La réponse proposée est la preuve de travail (Proof of Work). Pour produire un bloc, un participant doit trouver une valeur qui rend le hachage du bloc conforme à une condition de difficulté. Concrètement, on teste beaucoup de variantes jusqu’à tomber sur une empreinte qui “passe”. Cela rend la création d’un bloc coûteuse, tandis que sa vérification est rapide.

Le consensus vient de la règle suivante : la chaîne valide est celle qui représente le plus de travail cumulé (souvent décrite comme la “chaîne la plus longue”, mais l’idée est bien la somme de preuves de travail). Dans notre exemple :

• La transaction “Alice → Bob” apparaît dans une chaîne A.
• Alice tente de lancer une chaîne B alternative où “Alice → Charlie” remplace l’autre dépense.
• Pour que B soit acceptée, il faut qu’elle dépasse A en travail cumulé.
• Plus A s’allonge, plus il devient coûteux de la rattraper.

Cette progression explique pourquoi on attend souvent plusieurs blocs supplémentaires avant de considérer un paiement comme très difficile à renverser : ce n’est pas une magie, c’est l’effet du travail cumulé.

5) Incitations, arbres de Merkle et vérification simplifiée (SPV)

Le livre blanc aborde ensuite les incitations : si créer des blocs coûte des ressources, pourquoi des participants le feraient-ils honnêtement ? Le texte décrit une récompense et des frais de transaction qui encouragent à construire sur la chaîne la plus difficile à falsifier, plutôt qu’à tenter de la contredire. L’objectif est d’aligner l’intérêt individuel et la sécurité collective.

Pour structurer les transactions dans un bloc, le document introduit les arbres de Merkle : on hache les transactions, puis on combine ces hachages par paires jusqu’à obtenir une racine unique. Cette racine est incluse dans l’en-tête du bloc. Intérêt : on peut prouver qu’une transaction est incluse dans un bloc sans révéler toutes les autres, en fournissant seulement le chemin de hachages nécessaire.

SPV : vérifier sans tout stocker

La vérification simplifiée (SPV) permet à un client léger de vérifier qu’un paiement est inclus dans la chaîne avec travail cumulé, sans télécharger toutes les transactions. Dans notre exemple, Bob peut :

1. télécharger uniquement les en-têtes de blocs ;
2. demander une preuve de Merkle montrant que “Alice → Bob” est dans tel bloc ;
3. vérifier que ce bloc appartient à la chaîne au plus grand travail cumulé qu’il observe.

SPV fait un compromis : on gagne en légèreté, mais on dépend davantage de la qualité des informations reçues et du fait que la majorité de puissance de calcul suive les règles.

Lexique et implicites du texte

Lexique rapide :

• Signature numérique : preuve cryptographique qu’un détenteur de clé privée autorise une dépense.
• Hachage : empreinte courte d’une donnée ; une petite modification change fortement l’empreinte.
• Bloc : paquet de transactions plus des métadonnées, lié au bloc précédent.
• Preuve de travail : mécanisme rendant la production d’un bloc coûteuse mais vérifiable facilement.
• Travail cumulé : somme de preuves de travail d’une chaîne ; base de la règle de sélection.
• Arbre de Merkle : structure permettant de prouver l’inclusion d’une transaction de façon compacte.
• SPV : méthode de vérification avec en-têtes de blocs + preuves d’inclusion, sans tout télécharger.

Ce que le livre blanc suppose sans détailler : la fiabilité pratique des primitives cryptographiques (hachage, signatures), le modèle de réseau (propagation, délais, partitions), et l’hypothèse centrale que la majorité de la puissance de calcul suit les règles. Pour replacer ce document dans son contexte, voir aussi Anniversaire du livre blanc de Bitcoin.