Bitcoin Whitepaper désigne le document de neuf pages de Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, annoncé le 31 octobre 2008. Il présente une conception du système, pas la spécification complète du Bitcoin actuel ; les neuf pages comprennent les références.
La section 2 décrit le transfert d’une pièce par signatures numériques. Le destinataire peut vérifier l’autorisation, mais l’expéditeur peut aussi signer un paiement concurrent des mêmes fonds. Un historique public commun doit résoudre ce problème. Une signature valide et l’inscription d’une transaction dans cet historique sont deux conditions distinctes. [Original Bitcoin whitepaper]
Les sections 3–5 relient les blocs par des hachages et le Proof of Work. La chaîne la plus longue désigne ici l’historique ayant accumulé le plus de travail, pas un vote selon le nombre d’adresses IP. Le travail ne remplace pas la validation : les nœuds rejettent les blocs invalides. La chaîne établit un ordre, pas une horloge indépendante précise pour chaque paiement. [Original Bitcoin whitepaper] [Bitcoin Developer Guide — Block Chain]
La section 6 présente les nouvelles pièces et les frais comme des incitations à produire des blocs. Les frais sont la différence entre valeurs des entrées et sorties ; le texte envisage un financement futur exclusivement par les frais. Il ne donne ni la limite chiffrée de 21 millions ni l’intervalle de réduction de 210 000 blocs. Ces paramètres nécessitent d’autres sources. [Original Bitcoin whitepaper] [Bitcoin Developer Guide — Block Chain]
La section 8 propose SPV : le client obtient des en-têtes de blocs et une preuve de Merkle d’inclusion de la transaction. L’inclusion n’est pas une vérification autonome de toutes les règles et de tout l’historique des dépenses. Le texte reconnaît explicitement que cette méthode est plus vulnérable à un attaquant qu’un nœud complet. [Original Bitcoin whitepaper]
La section 10 sépare les transactions publiques de l’identité des détenteurs de clés et recommande de nouvelles paires de clés. Elle avertit aussi que les liens entre transactions peuvent révéler d’autres paiements lorsqu’une identité est découverte. Une nouvelle adresse ne garantit donc pas seule l’anonymat ; l’historique public reste analysable. [Original Bitcoin whitepaper]
La section 11 modélise un attaquant rattrapant la chaîne honnête. Le résultat dépend de sa part de puissance de calcul et de l’avance de la chaîne ; face à un attaquant plus faible, le risque diminue avec l’avance. Le modèle repose sur des hypothèses et une approximation de Poisson. Il ne fixe pas un nombre sûr de confirmations pour tous les paiements et toutes les attaques. [Original Bitcoin whitepaper]
Les évolutions ultérieures, comme SegWit décrit dans BIP 141, sont absentes du livre blanc. Publier un BIP ne signifie pas son adoption. Pour interpréter le comportement actuel, il faut distinguer proposition, implémentation, règles de consensus déployées et politique locale de relais ; cette dernière n’est pas une règle de validité des blocs. [BIP 141 — Segregated Witness] [Bitcoin Developer Guide — Block Chain]
L’annonce initiale d’octobre documente la publication du projet, tandis que le PDF expose son raisonnement. Les sections sur les signatures, le réseau et les calculs doivent être lues ensemble : elles traitent des parties différentes du problème. Une phrase citée sans ses hypothèses ne prouve pas la sécurité d’un portefeuille précis ou d’une implémentation actuelle. [Original announcement — 31 October 2008] [Original Bitcoin whitepaper]
Pour une vision complète, lisez aussi Satoshi Nakamoto, Bitcoin, Proof of Work, Transaction, Timechain / Blockchain. Cette entrée est également citée par Bitcoin, Satoshi Nakamoto, Genesis Block, Cypherpunks.