Bitcoin est un système ouvert de transfert de valeur monétaire sans administrateur central obligatoire. Le même nom désigne le protocole, le réseau de participants et son unité monétaire ; son symbole est BTC et un BTC se divise en 100 000 000 satoshis. Pour comprendre Bitcoin, suivons un paiement : qui peut disposer de la valeur, comment cette faculté passe au destinataire et comment les autres vérifient son inscription dans un historique commun.
Un solde bancaire représente une obligation de la banque envers son client. Avec du bitcoin en garde personnelle, nous détenons les moyens de satisfaire les conditions de dépense de certains enregistrements du réseau. Le protocole consigne montants et conditions, pas les noms civils des propriétaires. Le portefeuille regroupe ces enregistrements pour afficher le solde ; les pièces ne sont pas des fichiers stockés dans le téléphone. Un solde chez un dépositaire ou une plateforme d'échange signifie autre chose : généralement une créance sur le service qui contrôle les clés. La capacité technique à signer un paiement ne détermine pas à elle seule la propriété juridique. [Bitcoin Developer Guide — Transactions] [Bitcoin.org — Securing your wallet]
Le destinataire communique une adresse créée par son portefeuille. Elle indique comment créer une sortie avec certaines conditions de dépense ; ce n'est ni une boîte à pièces ni un mot de passe secret. Dans le cas courant, une signature numérique produite avec une clé privée autorise la dépense suivante ; sa vérification n'exige pas de révéler la clé. Les conditions peuvent aussi imposer plusieurs signatures ou un délai. Connaître l'adresse ne suffit pas pour dépenser. Quiconque obtient les secrets nécessaires peut toutefois créer une dépense valide ; le réseau ne distingue pas le vol d'une clé du consentement de son détenteur. [Bitcoin Developer Guide — Transactions]
Une sortie non dépensée d'une transaction précédente est appelée UTXO. Une transaction ordinaire référence les UTXO sélectionnés par ses entrées, les consomme entièrement et crée de nouvelles sorties. Avec une sortie adaptée de 100 000 sat, l'expéditeur peut attribuer 60 000 sat au destinataire et récupérer 39 000 sat sous son contrôle. Les 1 000 sat restants constituent les frais, pas un taux recommandé. La sortie initiale ne peut plus être dépensée dans ce même historique. L'adresse de monnaie rendue peut différer de l'adresse initiale. Destinataire, montant et frais se vérifient avant signature. [Bitcoin Developer Guide — Transactions]
Le portefeuille prépare et signe le paiement ; un Full Node vérifie les données selon les règles de consensus. Il contrôle notamment l'existence des entrées non dépensées, le respect des conditions de dépense et l'absence de création de valeur supplémentaire par une transaction ordinaire. Il peut accepter une transaction valide non confirmée dans sa file locale, le Mempool, et la relayer. Chaque nœud possède sa file et ses politiques de relais ; refuser de relayer ne signifie pas toujours une invalidité dans un bloc. Le portefeuille peut utiliser son propre nœud ou un serveur tiers qui lui fournit des informations. Même son propre nœud ne protège pas une clé de signature volée. [Bitcoin Developer Guide — Transactions] [Bitcoin Developer Guide — Operating Modes]
Le détenteur autorisé d'une clé peut signer deux transactions différentes dépensant le même UTXO. Les deux signatures peuvent être correctes, tandis que les participants voient d'abord des paiements différents. Outre l'autorisation, il faut donc un ordre commun. La double dépense ne consiste pas à copier un fichier contenant une pièce : elle tente d'imposer deux utilisations contradictoires d'une même sortie. Une seule au maximum peut appartenir à un historique valide. Ni l'heure de réception, ni le nombre de nœuds connectés, ni une affirmation du portefeuille ne tranchent seuls ce conflit à l'échelle globale. [Bitcoin: A Peer-to-Peer Electronic Cash System]
Les mineurs assemblent des blocs candidats et calculent des hachages à répétition pour trouver un Proof of Work satisfaisant la cible de difficulté. Un bloc référence son prédécesseur ; modifier un historique ancien exige de recalculer le travail qui suit. Le nœud vérifie d'abord les règles, puis choisit parmi les branches valides celle ayant le plus de travail cumulé, pas nécessairement le plus de blocs. Le minage aide ainsi à ordonner les transactions, sans autoriser la dépense des sorties d'autrui. Même une majorité de puissance de calcul ne force pas un nœud inchangé à accepter un bloc invalide ; elle peut cependant perturber l'ordre et la disponibilité des confirmations. [Bitcoin Developer Guide — Block Chain]
L'inclusion dans un bloc accepté donne la première confirmation. Les blocs suivants augmentent généralement le coût du remplacement de cet historique. Leur intervalle n'est pas un horaire : dix minutes est une cible à long terme, pas un délai de paiement promis. Une réorganisation peut retirer un bloc précédemment accepté, rendre une transaction non confirmée ou la remplacer par une dépense contradictoire. Le nombre de confirmations nécessaire dépend donc de la valeur et du risque du paiement ; il n'apporte pas de certitude absolue. Le protocole n'a pas d'administrateur des annulations. Un remboursement volontaire est un nouveau paiement dont les frais doivent être traités à nouveau. [Bitcoin: A Peer-to-Peer Electronic Cash System] [Bitcoin Developer Guide — Block Chain]
La première transaction du bloc, la Coinbase Transaction, peut attribuer au mineur la subvention du bloc et les frais des transactions incluses. Seule la subvention crée de nouvelles unités ; les frais transfèrent de la valeur existante. La subvention maximale a commencé à 50 BTC et est divisée par deux tous les 210 000 blocs. Ce Halving ne concerne pas les frais. L'arrondi en satoshis entiers maintient la somme des subventions autorisées sous 21 millions de BTC. Les nœuds refusent les récompenses excessives. Des clés perdues n'augmentent pas l'émission future, et un nombre limité d'unités ne détermine pas à lui seul leur pouvoir d'achat. [Bitcoin Developer Guide — Block Chain]
Le code source peut être examiné et des modifications proposées publiquement. Un développeur publie un logiciel, un opérateur de nœud choisit les règles qu'il vérifie et un mineur sélectionne le contenu d'un bloc candidat. Aucun rôle ne décide seul pour tous ; des modifications incompatibles peuvent diviser le réseau. L'influence économique des participants reste inégale. L'espace limité des blocs borne les besoins de vérification et de diffusion des données, mais une forte demande crée une concurrence pour l'inclusion. Les frais dépendent donc de la taille de la transaction et de cette demande, pas simplement du montant transféré. [Bitcoin Developer Guide — Block Chain] [Bitcoin Developer Guide — Transactions]
L'historique public permet la vérification, mais aussi le rapprochement de paiements et d'identités, par exemple grâce aux données d'une plateforme d'échange. Le pseudonymat n'est pas l'anonymat. La garde personnelle supprime le besoin de demander une signature à un dépositaire, tout en transférant au détenteur la responsabilité des sauvegardes, de la sécurité de l'appareil et du contrôle du destinataire. Une sauvegarde doit restaurer les clés et la configuration nécessaires ; restaurer le portefeuille ne rend pas secret un secret divulgué. Son propre nœud aide à vérifier l'historique, sans garantir prix, confidentialité ni signature sûre. Vérifier soi-même suppose de savoir laquelle de ces questions on contrôle. [Bitcoin.org — Protect your privacy] [Bitcoin.org — Securing your wallet]
Pour une vision complète, lisez aussi Satoshi Nakamoto, Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node, Limite de 21 millions. Cette entrée est également citée par Satoshi Nakamoto, Bitcoin Whitepaper, Genesis Block, Full Node.