Bitcoin Whitepaper

Un whitepaper présente un problème et propose une solution. Celui de Bitcoin part d’une question quotidienne : lorsque j’envoie de l’argent sur Internet, faut-il toujours une banque ou un autre gestionnaire entre nous ? Satoshi a adressé son projet à une liste de discussion sur la cryptographie le 31 octobre 2008, avec un lien vers le texte. Il ne promettait ni cours du bitcoin ni rendement à un investisseur. Il expliquait comment recevoir des paiements sans confier à une seule entreprise les décisions concernant leur historique. Ce problème relie tout le document. [2] [1]

Imaginez qu’un expéditeur signe deux paiements distincts qui dépensent les mêmes fonds. Un destinataire voit le premier, l’autre le second. Tous deux peuvent vérifier une signature numérique valide, donc une preuve d’autorisation, sans pouvoir être payés tous les deux. Copier des données est facile sur Internet ; une signature seule ne résout pas ce problème. La section 2 distingue donc le droit de dépenser des fonds de la question du paiement retenu dans l’historique commun. Bitcoin ajoute aux signatures un registre public permettant de reconnaître des fonds déjà dépensés. [1]

Les sections 3–5 regroupent les paiements en blocs. Chaque nouveau bloc renvoie au précédent par un hash, une courte empreinte numérique des données. Modifier un ancien enregistrement changerait cette empreinte et romprait les liens. Proof of Work ajoute un calcul coûteux : produire un bloc acceptable demande de nombreuses tentatives, alors que vérifier le résultat est facile. Entre branches concurrentes, c’est donc le travail accumulé dans un historique conforme aux règles qui compte, pas le nombre de comptes ou d’adresses IP créés. Le texte parle de la chaîne la plus longue. Même beaucoup de travail ne rend pas valide une transaction invalide. La chaîne ordonne aussi les événements sans donner l’heure exacte de chaque paiement. [1] [3]

Les ordinateurs et l’électricité ont un coût. La section 6 ajoute donc une incitation économique : le créateur d’un bloc accepté peut recevoir des pièces nouvellement émises et les frais des paiements inclus. Les frais correspondent à la différence entre la valeur consommée par la transaction et celle de ses nouvelles sorties. Ce ne sont pas des pièces supplémentaires créées à partir de rien. Le texte envisage aussi une rémunération future reposant uniquement sur les frais. Mais il faut savoir où s’arrête la proposition : ni la limite exacte de 21 millions ni la division par deux tous les 210 000 blocs ne figurent dans le whitepaper. Ces règles demandent d’autres références sur Bitcoin. [1] [3]

Tout le monde ne souhaite pas télécharger et vérifier toutes les transactions. La section 8 propose donc SPV, la vérification simplifiée des paiements. Le client obtient les en-têtes, qui contiennent les données essentielles des blocs, et une preuve de Merkle : un chemin de hashes attestant l’inclusion d’une transaction dans un bloc. C’est la différence entre vérifier qu’une entrée figure dans un livre et contrôler l’exactitude de tout le livre. L’inclusion seule ne vérifie ni toutes les règles ni l’ensemble de l’historique des dépenses. Le whitepaper reconnaît cette limite : le client simplifié est plus vulnérable à certaines attaques qu’un Full Node qui vérifie lui-même les transactions. [1]

Dans le système bancaire, une grande partie des enregistrements n’est pas publique. Bitcoin a au contraire besoin d’un historique partagé et doit protéger la vie privée autrement. La section 10 explique la séparation entre les paiements et l’identité des détenteurs de clés, et recommande de nouvelles paires de clés pour les transactions suivantes. Elle reconnaît aussi une faiblesse : des paiements peuvent être reliés. Identifier une personne derrière un enregistrement peut révéler d’autres paiements. Une nouvelle adresse n’est donc pas un déguisement magique. Elle limite certains liens sans effacer à elle seule les informations publiques ni celles connues de l’autre partie. [1]

La section 11 évalue les chances qu’un attaquant rattrape la chaîne produite par les participants honnêtes. Imaginez une course : un camp a de l’avance, mais les deux continuent à travailler. Dans le modèle décrit, plus la part de puissance de l’attaquant est faible et l’avance grande, moins il a de chances de rattraper la chaîne. Le calcul repose sur des hypothèses et une approximation de Poisson, une simplification mathématique estimant le nombre d’événements pendant une période. Il ne prédit pas chaque attaque réelle. Un nombre isolé du tableau ne constitue donc pas un nombre sûr de confirmations pour n’importe quel paiement. [1]

Le document décrit le projet initial. Le réseau et le logiciel ont évolué ; SegWit, par exemple, décrit dans la proposition BIP 141, n’y figure pas. Un BIP est un document proposant une amélioration, pas une décision devenant automatiquement une règle du réseau dès sa publication. Pour comprendre les questions actuelles, il faut distinguer proposition, logiciel, règles communes effectivement appliquées et décisions locales d’un nœud concernant le relais des transactions. Un nœud peut refuser de relayer une transaction, puis l’accepter dans un bloc valide. Ces situations ne se contredisent pas. [4] [3]

Commencez par le résumé et la question de la double dépense sans gestionnaire. Regardez ensuite ce qu’apportent les signatures, l’historique commun et le travail nécessaire à la création des blocs. Si les mathématiques vous arrêtent, inutile de comprendre immédiatement chaque formule : cherchez d’abord quelle attaque le calcul modélise et sur quelles hypothèses il repose. Vous pourrez revenir aux détails. Le courriel initial établit quand Satoshi a présenté la proposition ; le PDF contient son argumentation. Une phrase sortie de cet ensemble ne prouve pas qu’un portefeuille ou un service particulier doit être sûr. [2] [1]

L’essentiel n’est pas de mémoriser les titres des sections, mais de comprendre pourquoi aucun élément ne suffit seul : la signature établit l’autorisation, l’historique public aide à détecter la double dépense et Proof of Work complique la réécriture de l’ordre. Ces éléments avaient des prédécesseurs cités par Satoshi. L’apport tient à leur articulation. Le whitepaper reste une bonne introduction au raisonnement derrière Bitcoin, à condition de le lire comme une proposition argumentée reposant sur des hypothèses précises. Ce n’est ni une liste de prix, ni un guide d’investissement, ni la spécification complète de tous les outils et règles portant aujourd’hui le nom Bitcoin. [1]