Comme on l'a vu dans l'article précédent, la validité de la chaîne de blocs de Bitcoin est garantie par le mécanisme économique du minage, qui repose sur un algorithme de preuve de travail. Ce mécanisme met en concurrence des mineurs qui sont incités à mettre en jeu leur puissance de calcul, ce qui assure la sécurité du protocole. Ce modèle a fait ses preuves : Bitcoin fonctionne sans interruption depuis quasiment 10 ans. De par sa nature ouverte et sa valeur, il constitue une cible de choix pour les pirates informatiques du monde entier, ce qui fait de lui l'un des systèmes informatiques les plus robustes de la planète.
En plus de cela, le protocole s'améliore au fil du temps. En effet, il ne s'agit pas d'un système figé et fixe : il peut être mis à jour. De fait, Bitcoin n'a pas toujours été ce qu'il est aujourd'hui. De nombreuses modifications lui ont été apportées depuis sa création pour corriger certains de ses bugs, améliorer ses rouages internes ou lui ajouter de nouvelles fonctionnalités. Encore aujourd'hui, le protocole évolue lentement pour s'adapter à la demande de ses utilisateurs.
Cependant, le changement de Bitcoin est une chose difficile à orchestrer : un changement non contrôlé pourrait être dramatique au vu des intérêts en jeu. De plus, contrairement aux systèmes informatiques traditionnels, la mise à jour de ce système de consensus est lente et pénible. Puisque Bitcoin fonctionne sur un réseau pair-à-pair et non sur un serveur centralisé, la modification des règles de consensus requiert une certaine coordination des participants et peut dégénérer en une séparation du réseau en deux parties différentes.
Dans cet article, j'exposerai la manière dont Bitcoin est mis à jour en parlant d'abord de sa nature protocolaire avant de décrire les deux méthodes utilisées pour le modifier : le hard fork et le soft fork.
La nature protocolaire de Bitcoin
Bitcoin est un protocole de communication informatique, c'est-à-dire un ensemble de règles permettant à différentes parties d'un réseau d'échanger des informations. Puisqu'il est construit sur Internet, Bitcoin peut être comparé à d'autres protocoles comme HTTP (HyperText Transfer Protocol) qui est utilisé pour l'affichage des pages web, SMTP (Simple Mail Transfer Protocol) qui est utilisé pour le courrier électronique, ou encore BitTorrent qui est un protocole de partage de fichiers en pair-à-pair.
En raison de sa nature protocolaire, Bitcoin n'est donc pas un logiciel unique mais un ensemble de règles appliquées par des programmes informatiques appelés implémentations du protocole.
Les implémentations logicielles
Comme on l'a vu précédemment, le protocole fonctionne sur un réseau pair-à-pair de nœuds possédant une copie de la chaîne de blocs. Chaque nœud fait tourner une implémentation logicielle qui lui permet d'échanger avec les autres nœuds du réseau. Leurs implémentations peuvent être différentes à certains niveaux, mais cela ne perturbe pas le réseau tant qu'elles respectent le protocole. Il peut ainsi exister des implémentations écrites avec des langages de programmation différents, des implémentations avec ou sans interface graphique, des implémentations fonctionnant uniquement sur Linux et d'autres sur Windows, etc.
Pour des raisons de sécurité et d'audit, le code source des principales implémentations logicielles est librement consultable en ligne (open-source). Ces implémentations sont également soumises à une license libre, ce qui permet à n'importe qui de copier et de modifier le code, et de créer sa propre version de Bitcoin.
L'implémentation de référence de Bitcoin (BTC) est connue sous le nom de Bitcoin Core. On l'appelle implémentation de référence car elle sert de modèle à toutes les autres implémentations du protocole. Bitcoin Core, anciennement appelée Bitcoin (tout court) et Bitcoin-Qt, est le logiciel historique de Bitcoin créé en 2008 par Satoshi Nakamoto : c'est pour cela qu'il est parfois désigné sous le nom de « client de Satoshi », bien qu'il ait considérablement évolué depuis. Bitcoin Core est utilisé par la quasi-totalité des nœuds du réseau BTC (plus de 94 %).
Bitcoin Cash (BCH), qui est un protocole distinct de Bitcoin (BTC) et qui prône l'augmentation progressive de la taille limite des blocs pour passer à l'échelle, possède quant à lui deux implémentations principales. La première est Bitcoin ABC1 et constitue l'implémentation de référence du protocole. La seconde est Bitcoin Unlimited qui a la particularité de ne pas définir une taille des blocs en dur dans le code source. Presque tous les nœuds du réseau BCH (96 %) utilisent l'une ou l'autre de ces deux implémentations. Ces implémentations peuvent également, sous réserve de changer quelques paramètres, servir à se connecter au réseau BTC.
Voici ci-dessous la répartition des implémentations utilisées par les nœuds des réseaux de Bitcoin (BTC) et de Bitcoin Cash (BCH).
| Bitcoin (BTC) | Bitcoin Cash (BCH) |
|---|---|
 Source : coin.dance |
 Source : cash.coin.dance |
Le protocole peut aussi être implémenté de façon partielle. C'est le cas des portefeuilles légers (comme Electrum), des programmes utilisés dans les coopératives de minage (comme Stratum) ou de toutes les applications utilisant le protocole Bitcoin pour un usage spécifique.
Les règles de consensus
Bitcoin est donc un ensemble de règles appliquées dans des implémentations logicielles utilisées par les différents nœuds du réseau. Ces règles leur permettent de se mettre d'accord de manière décentralisée sur le contenu de la chaîne de blocs : ce sont les règles de consensus c'est-à-dire les règles de validité des blocs et des transactions. Les règles de consensus sont implicitement définies dans l'implémentation de référence2, à savoir dans Bitcoin Core pour BTC et dans Bitcoin ABC pour BCH. Si un nœud ne les respecte pas en essayant de transmettre une transaction ou un bloc invalide au réseau, les autres nœuds rejettent sa transaction ou son bloc et peuvent, dans le cas d'un trop grand nombre de requêtes invalides, interrompre leur connexion avec lui et le bannir temporairement.
Parmi les nombreuses règles de consensus, il existe quelques règles spécifiques qu'il est intéressant de présenter. La première règle est la taille limite des blocs. Instaurée pour éviter les attaques par déni de service (DDoS), cette règle interdit aux blocs d'être plus gros qu'un certain seuil, qui est actuellement de 1 Mo (1 000 000 octets) pour BTC et de 32 Mo pour BCH. On parle beaucoup de cette règle car c'est elle qui limite la capacité du réseau : la taille maximale de 1 Mo restreint le nombre de transactions à environ 3 transactions par seconde3. C'est la raison de l'augmentation drastique des frais de transactions et des délais de confirmation lors des fortes demandes comme en décembre 2017. Pour améliorer la situation, il suffirait d'augmenter la taille limite des blocs ; c'est d'ailleurs ce qu'à fait Bitcoin Cash. Cependant, cela aurait pour effet de réduire le nombre de nœuds du réseau en augmentant leur coût de fonctionnement, notamment celui de la bande passante et du stockage de la chaîne de blocs. La taille limite des blocs représente donc un compromis entre la capacité transactionnelle sur la chaîne et le niveau de décentralisation du réseau.
Un autre exemple de règle est la limite de rémunération des mineurs qui modère l'inflation des jetons. Lorsqu'un mineur trouve un nouveau bloc, il perçoit ce qu'on appelle une récompense de bloc. Cette récompense est limitée par le protocole : elle doit être inférieure à un certain montant. Ce montant était de 50 bitcoins par bloc en 2009 et est depuis réduit de moitié tous les 4 ans environ4, si bien que le nombre total de bitcoins ne dépassera jamais les 21 millions.
Enfin, une troisième règle est la fixation du temps de bloc moyen à 10 minutes. Cette règle impose un ajustement de la difficulté (la quantité de puissance de calcul pour trouver un bloc) pour qu'un bloc soit ajouté à la chaîne toutes les 10 minutes en moyenne. Ce temps de bloc moyen est un compromis entre une vitesse de confirmation acceptable et une fréquence de blocs invalides (« orphelins ») faible.
Les mises à jour du protocole
Bien qu'elles doivent rester les mêmes pour tout le monde sur le court terme pour que le système puisse fonctionner, les règles de consensus de Bitcoin ne sont pas immuables et rien n'interdit de les modifier à long terme. Le protocole a d'ailleurs beaucoup évolué depuis sa création. Cependant, la nature de Bitcoin fait que les changements sont difficiles à réaliser et requièrent la coordination des différents acteurs du système. On peut voir ce conservatisme inhérent comme une faiblesse de Bitcoin, mais aussi comme l'une de ses plus grandes qualités : s'il était trop facile de le modifier, la confiance accordée au protocole ne serait pas la même.
Les mises à jour des règles de consensus peuvent être effectuée par l'intermédiaire de deux méthodes différentes : le hard fork et le soft fork. Notons que pour Bitcoin (BTC), ces mises à jour sont généralement décrites dans les propositions d'amélioration de Bitcoin (Bitcoin Improvement Proposal ou BIP) qui sont des documents décrivant des changements potentiels du protocole ou fournissant des informations générales à la communauté de Bitcoin.
Un fork (de l'anglais fourche, bifurcation, embranchement) est une duplication de la chaîne de blocs en deux chaînes distinctes. Les forks sont assez communs dans Bitcoin : il arrive que 2 mineurs trouvent chacun un bloc différent dans un intervalle de temps réduit. Dans ce cas, les 2 blocs trouvés sont tout à fait valides, et au moment où ils sont minés rien ne peut les départager. Les nœuds sélectionnent la première solution qu’ils recoivent ce qui entraîne une séparation du réseau en deux parties : l’une qui considère que le premier bloc est valide et le second invalide, l’autre qui considère que le second bloc est valide et le premier invalide. La situation est résolue lorsque l’un mineur trouve un nouveau bloc : c’est alors la plus longue chaîne (la chaîne possédant le plus de travail accumulé) qui est sélectionnée par le réseau. L'autre bloc est mis de côté et considéré comme invalide : ce bloc est appelé « orphelin » (orphan).
Fork de la chaîne
Le terme « fork » est également utilisé dans le développement logiciel pour désigner le programme dérivé du code source d'un programme existant. Cette polysémie prête parfois à confusion, notamment lorsqu'on parle de Litecoin et de Dash comme des forks de Bitcoin, alors que leurs chaînes n'ont rien en commun avec celle de Bitcoin.
Le hard fork
Un hard fork est une duplication de la chaîne de blocs produite par une modification accidentelle ou délibérée des règles de consensus. On dit que l'embranchement (fork) est dur (hard) parce que le réseau ne reconverge pas vers une chaîne unique après la séparation. Dans le cadre d'une mise à jour, la méthode du hard fork est la plus directe : il s'agit d'un changement brutal des règles que tous les nœuds du réseau doivent implémenter s'ils veulent continuer à interagir avec les autres nœuds.
Qu'est-ce qu'il se passe lors d'un hard fork ? Prenons l'exemple typique de l'augmentation de la taille limite des blocs : la taille des blocs est actuellement limitée à 1 Mo dans le protocole Bitcoin (BTC) et l'augmentation de cette limite provoquerait un hard fork. Supposons donc qu'une partie du réseau implémente ce changement en modifiant leur logiciel pour accepter les blocs de 2 Mo. Cela va diviser le réseau en deux parties : les nœuds n'acceptant que les blocs de taille inférieure à 1 Mo et les nœuds acceptant les blocs de taille inférieure à 2 Mo.
Le hard fork se produit lorsqu'un bloc de plus de 1 Mo est miné et transmis au reste du réseau : les nœuds appliquant l'ancienne règle vont rejeter le gros bloc et continuer d'entretenir leur propre chaîne ; les nœuds appliquant la nouvelle règle vont, quant à eux, construire leur chaîne à partir de ce gros bloc. Peu à peu, avec l'accumulation des requêtes invalides, les deux ensembles de nœuds vont se déconnecter et se bannir mutuellement, ce qui va donner suite à une séparation du réseau en deux parties distinctes, chacune entretenant sa propre chaîne de blocs et ayant ses propres règles.
Le hard fork est donc la conséquence d'une modification non compatible des règles de consensus. Il peut être produit de manière accidentelle, mais aussi comme on l'a vu dans l'exemple ci-dessus, de façon délibérée.
Le hard fork accidentel est un hard fork qui se produit de manière non désirée lors d'une mise à jour du logiciel. C'est ce qui s'est produit le 11 mars 2013 (UTC) suite au passage de la version 0.7 à la version 0.8 de Bitcoin Core (appelé alors Bitcoin-Qt). Cette mise à jour procédait à la migration du système de gestion de bases de données utilisé pour stocker la chaîne de blocs de Berkeley DB vers LevelDB. Elle n'aurait pas dû poser de problème particulier. Cependant, il s'est avéré que Berkeley DB possédait dans son code une limite par défaut (une lock limit fixée à 10 000) qui n'était pas présente dans LevelDB. Cette incomptabilité des versions 0.7 et 0.8 s'est soldée par un hard fork à partir du bloc 225 430. Deux chaînes ont ainsi coexisté pendant environ 6 heures. Après concertation des acteurs du réseau, la décision a finalement été prise de repasser à la version 0.7, et les 24 blocs minés du côté de la version 0.8 sont alors devenus invalides. Quelques jours plus tard, un patch correctif (qui respectait la limite de Berkeley DB) était appliqué à la version 0.8.
Le hard fork de mise à jour est un hard fork engendré par une modification des règles de consensus recueillant le consentement quasi-unanime de la communauté. La chaîne est dupliquée en deux chaînes distinctes mais seule la chaîne respectant les nouvelles règles survit. Ce type de mise à jour a eu lieu à la suite du hard fork accidentel du système de base de données décrit ci-dessus. Pour corriger le bug et finaliser le passage à LevelDB, la règle temporaire respectant la limite imposée par Berkeley DB a été assouplie le 15 mai 2013 avec l'accord de la communauté. Le hard fork s'est produit le 16 août avec le bloc 252 451 qui violait l'ancienne règle et rejetait du réseau tous les nœuds n'ayant pas mis à jour leur logiciel5.
Ce genre de hard fork de mise à jour a lieu tous les 6 mois sur la chaîne de Bitcoin Cash. Le dernier en date (15 mai 2018) a fait passer la taille limite des blocs de 8 Mo à 32 Mo et a introduit de nouveaux codes opératoires (OP codes) dans le langage de programmation interne à Bitcoin.
Le hard fork contentieux est un hard fork qui survient en cas de dissension dans la communauté. Celui-ci vise, comme le hard fork de mise à jour, à améliorer le protocole, mais ne recueille qu'un consentement partiel des participants. Puisqu'il conduit nécessairement à une séparation du réseau, les nœuds du réseau appliquant la nouvelle règle rejettent délibérément les blocs et les transactions produits par les nœuds appliquant les anciennes règles. Les deux chaînes issues de l'embranchement survivent car elles sont respectivement valorisées par des parties de la communauté. Le meilleur exemple de ce cas de hard fork est fork de Bitcoin Cash qui s'est produit le 1er août 2017, au bloc 478 559. Ce hard fork s'inscrit dans la continuité des diverses tentatives d'augmentation de la taille limite des blocs : les implémentations Bitcoin XT, Bitcoin Classic et Bitcoin Unlimited ont en effet menacé à tour de rôle d'appliquer ce changement si une portion suffisante de la communauté était convaincue. Bitcoin Cash a finalement franchi le pas en augmentant unilatéralement cette taille limite à 8 Mo en août 2017 et en devenant une chaîne concurrente à Bitcoin (BTC).
Ce type de hard fork pose quelques problèmes. Tout d'abord, puisque les deux chaînes survivent, les possesseurs de bitcoins se retrouvent à en posséder sur les deux chaînes à la fois : les jetons sont dédoublés. Une transaction étant diffusée sur le réseau de manière publique, un utilisateur envoyant des bitcoins à quelqu'un d'autre sur sur une chaîne pourrait se faire voler les bitcoins présents sur l'autre chaîne par rediffusion de la transaction sur l'autre réseau : c'est ce qu'on appelle une attaque par rejeu (replay attack). Heureusement, afin d'assurer la viabilité du projet, les développeurs du hard fork contentieux sont incités à mettre en place une protection contre le rejeu (replay protection) pour que les transactions ne soient pas les mêmes sur la nouvelle chaîne. C'est ce qu'à fait Bitcoin Cash en modifiant la façon dont sont signées les transactions.
Un autre problème du hard fork contentieux est celui de la distribution du taux de hachage entre les deux chaînes. Dans Bitcoin (BTC), la difficulté du minage s'ajuste à la puissance de calcul du réseau toutes les 2 semaines environ (tous les 2016 blocs). Après le hard fork, chaque chaîne conserve une certaine portion du taux de hachage total, ce qui peut se révéler problématique. Supposons que la hard fork ait lieu juste après l'ajustement de la difficulté et que la puissance de calcul totale se répartisse selon une proportion de 80 % pour la première chaîne et de 20 % pour la seconde. Sur la première chaîne cela ne posera pas de gros problème : avec 80 % du taux de hachage, les blocs seront trouvés toutes les 12 minutes et 30 secondes en moyenne et la difficulté sera réajustée après 17 jours et demi. Sur la seconde chaîne par contre, la situation sera plus embarrassante : avec 20 % du taux de hachage, le temps de bloc moyen sera de 50 minutes et le réajustement n'aura lieu qu'au bout de 10 semaines. Bitcoin Cash a évité cette situation malencontreuse en changeant l'algorithme d'ajustement de difficulté original par un algorithme d'urgence appelé Emergency Difficulty Adjustment (EDA) qui s'adapte sur une période plus courte que les deux semaines requises.
Le soft fork
Contrairement au hard fork, le soft fork n'est pas un fork : il s'agit d'une modification rétrocompatible des règles de consensus qui n'entraîne pas nécessairement un embranchement de la chaîne de blocs. Le terme de « soft fork » a simplement été introduit pour différencier les deux méthodes de mise à jour. Afin d'être compatible avec les anciennes règles, un soft fork ne peut être qu'une restriction des règles de consensus, et non un élargissement comme peut le faire le hard fork. Une grande quantité des améliorations apportées à Bitcoin ont été des soft forks, comme par exemple l'introduction des adresses P2SH (Pay-to-Script-Hash) utilisées notamment comme comptes multisignatures.
Qu'est-ce qu'il se passe lorsqu'un soft fork est appliqué ? Considérons l'exemple de la diminution de la taille limite des blocs de 1 Mo à 500 ko, soit une réduction de moitié de cette taille. Dans le cas d'une augmentation, les règles sont élargies et un hard fork a lieu ; dans le cas d'une diminution, les règles sont restreintes et c'est un soft fork qui intervient. Si la chaîne n'est pas nécessairement dupliquée en deux chaînes distinctes, le réseau est cependant divisé en deux parties : les nœuds qui appliquent l'ancienne règle (gros blocs) qui vont accepter tous les blocs produits par le reste du réseau, et les nœuds qui ont implémenté la nouvelle règle (petits blocs) qui refuseront les blocs dont la taille est supérieure à 500 ko, produits nécessairement par les nœuds utilisant la limite de 1 Mo.
Pour fonctionner, un soft fork nécessite la majorité du taux de hachage. Dans le cas où il possède moins de 50 % de la puissance de calcul du réseau, le soft fork peut provoquer un hard fork. Dans notre exemple, à partir du moment où un bloc de taille supérieure à 500 ko est miné, la chaîne est séparée en deux branches. Pour les nœuds appliquant l'ancienne règle, la chaîne majoritaire formée à partir de ce gros bloc est valide, puisqu'il s'agit alors de la plus longue chaîne (celle qui a le plus de travail accumulé). Cependant, les nœuds n'acceptant que les petits blocs vont rejeter cette chaîne car elle transgresse leur règle, et en construire une autre qui sera minoritaire.
Dans le cas où le soft fork recueille plus de 50 % du taux de hachage, il n'y a pas de duplication de la chaîne. Puisque les nœuds appliquant la nouvelle règle possèdent la plus grande puissance de calcul, la chaîne des petits blocs (de taille inférieure à 500 ko) restera la chaîne valide pour l'ensemble du réseau. Les nœuds miniers sont alors incités à adopter la nouvelle règle, car la production d'un gros bloc leur ferait dépenser de l'énergie pour rien, ce gros bloc étant rejeté par le réseau (orphaned). C'est pour cela qu'un soft fork n'est pas plus avantageux qu'un hard fork du point de vue des mineurs : soit ils acceptent les nouvelles règles, soit ils réalisent un hard fork contentieux en dupliquant délibérément la chaîne. C'est plutôt pour les nœuds non-miniers qu'un soft fork a un intérêt : il peuvent choisir de ne pas mettre à jour leur implémentation sans craindre d'être déconnectés du réseau.
Le déploiement des soft forks sur le réseau est facilité par l'intermédiaire du champ de version des blocs, conformément aux spécifications décrites dans le BIP-9. Les mineurs signalent leur volonté d'appliquer les nouvelles règles dans les blocs qu'ils valident. Si une proposition de soft fork dépasse les 95 % (supermajorité) sur une période de 1000 blocs, alors elle est activée. Cette méthode permet de déployer plusieurs soft forks à la fois.
Le dernier soft fork appliqué à Bitcoin (BTC) est la mise à jour appelée « Segregated Witness » ou SegWit. Celle-ci consiste principalement à déplacer les données de signature des transactions (appelées témoin ou witness) vers une structure de données séparée (segregated). Cette modification vise à corriger la malléabilité des transactions et à augmenter modérément la capacité du réseau. SegWit est appliqué sur le réseau depuis le 24 août 2017.
Quelle est la meilleure méthode de mise à jour ?
Les deux méthodes, hard fork et soft fork, présentent toutes deux des avantages et des inconvénients mais il n'existe pas de solution parfaite pour mettre à jour Bitcoin.
Le hard fork a l'avantage d'être propre : le changement des règles est clair et ne rajoute pas de la complexité au code, ce qui est très important pour un système comme Bitcoin qui se doit d'être le plus auditable possible. Mais cette propreté a un coût : l'intégralité du réseau (voire du réseau étendu) doit se coordonner et ceux qui n'ont pas mis leur logiciel à jour se retrouvent exclus. Pire : s'il est contentieux, un hard fork a pour effet de diviser irrémédiablement la communauté, ce qui affaiblit Bitcoin de manière générale.
Le soft fork présente, quant à lui, l'avantage de préserver en apparence l'unité de la communauté en ne nécessitant pas la mobilisation du réseau entier. Cependant, si tous les nœuds du réseau ne sont pas obligés d'appliquer les nouvelles règles, les mineurs le sont pour des raisons économiques. De plus, dans le cas de certains soft forks, les nœuds non-miniers n'ayant pas mis à jour leur logiciel se retrouvent à valider les transactions de manière partielle puisque les modifications ne sont pas prises en compte. Un autre inconvénient du soft fork est l'ajout de complexité au code (ce qu'on appelle dette technique ou technical debt). Par exemple, dans le cas de SegWit, les anciennes et les nouvelles transactions coexistent, ce qui rend plus difficile la compréhension et l'implémentation du protocole.
Ainsi, Bitcoin n'est pas un système figé incapable de s'adapter : il s'agit d'un protocole ouvert qu'il est possible de modifier. Une mise à jour peut se faire de deux manières : soit par un hard fork dans le cas où il s'agit d'un élargissement des règles existantes ; soit par un soft fork dans le cas où il s'agit d'une restriction des règles existantes. Dans les deux cas, il faut une certaine coordination du réseau pour que le changement ait lieu.
Cela nous amène à la question de la prise de décision : puisqu'il n'y pas d'autorité centrale qui dicte comment les choses doivent se passer, qu'est-ce qui dirige l'évolution de Bitcoin ? Comment sont décidées les mises à jour du protocole ? Quels sont les mécanismes à l'œuvre ? Je répondrai à ces questions dans un prochain article consacré au sujet épineux et souvent mal compris de la gouvernance de Bitcoin.
Merci d'avoir lu cet article.
Notes
1. Le « ABC » dans Bitcoin ABC est l'acronyme de Adjustable Blocksize Cap ou taille limite des blocs ajustable.
2. Voir par exemple les fichiers /src/chainparams.cpp et /src/consensus/consensus.h
3. La taille d'une transaction standard (une entrée, deux sorties) est de 226 octets. Le nombre théorique de transactions par seconde pour une taille limite de bloc de 1 Mo est donc de
(1 000 000 / 226 ) / (10 × 60) = 7.37 tps
Cependant, dans la réalité, la taille moyenne d'une transaction avoisine plutôt les 550 octets, ce qui nous donne 3 transactions par seconde.
4. La récompense de minage maximale est réduite de moitié tous les 210 000 blocs. La récompense de bloc était limitée à 50 bitcoins du 03/01/2009 au 28/11/2012, à 25 bitcoins du 28/11/2012 au 09/07/2016 et est depuis limitée à 12.5 bitcoins. La limite devrait être de 6.25 bitcoins par bloc entre 2020 et 2024, et ainsi de suite.
5. Voir le BIP-50 et l'article de Vitalik Buterin pour plus détails sur cette histoire.
Références
Andreas M. Antonopoulos, Mastering Bitcoin: Programming the Open Blockchain (seconde édition), juin 2017, chapitres 8 et 10.
Bitcoin Improvement Proposals (BIP)
Amy Castor, A Short Guide to Bitcoin Forks, 27 mars 2017.
Bitmex Research, A complete history of Bitcoin’s consensus forks, 28 décembre 2017.
Vitalik Buterin, Bitcoin Network Shaken by Blockchain Fork, 12 mars 2013.