Traduction d’un article de Jameson Lopp publié le 16 septembre sur le blog de l’auteur.
Analyse technique du comportement d’un mineur que l’on suppose être Satoshi Nakamoto
Si vous fréquentez assidument « l’écosystème crypto », vous avez certainement entendu des critiques contre des cryptomonnaies dont les jetons ont été préminés, minés instantanément ou très rapidement au lancement du projet par les fondateurs. Pour répondre à ceux qui dénoncent légitimement ces pratiques, ces fondateurs souligneront inévitablement que Satoshi lui-même posséderait 1 100 000 bitcoins environ, soit près de 5 % de la quantité globale lorsque tous les bitcoins seront minés.
Préambule à propos du « Patoshi Pattern »
Pour les besoins de cet article, je partirai du principe que ce qu’on appelle le Patoshi Pattern [motif Patoshi] est la marque d’une seule entité et que cette entité était Satoshi. J’utiliserai indifféremment « Satoshi » et « Patoshi » pour désigner cet acteur. Bien qu’il ne soit pas possible de prouver cette affirmation au-delà de tout doute raisonnable, les comportements manifestés par ce mineur suggèrent qu’il avait, dès le début, une compréhension extrêmement approfondie de Bitcoin, du niveau de celle de Satoshi. Mais c’est un sujet qui mériterait un autre article.
Qu’est-ce que le Patoshi Pattern ? Si vous connaissez les bases de l’extraction de Bitcoin, vous savez que les mineurs incrémentent les nonces pour tenter de créer un bloc valide avec une valeur de hachage qui répond à un objectif de difficulté donné. Le champ ExtraNonce, situé dans la transaction coinbase, s’incrémente chaque fois que le champ nonce déborde, ce qui signifie que l’espace de recherche est épuisé. Comme le champ nonce a une longueur de 32 bits et que la cible de difficulté initiale de Bitcoin nécessitait de scanner 32 bits en moyenne, le nonce débordait parfois, mais pas toujours.
1. L‘ExtraNonce fonctionne comme un « compteur libre », sans remise à zéro entre les blocs minés.
2. La vitesse à laquelle un mineur incrémente l’ExtraNonce est beaucoup plus rapide que son taux de hachage réel ne l’indiquerait, sur la base du code source Bitcoin d’origine.
3. Toutes les quelques secondes lors du minage, le meilleur bloc est vérifié. Si ce bloc change, l’ExtraNonce est également incrémenté. Normalement, chaque bloc externe reçu incrémentera l’ExtraNonce, à l’exception du mineur Patoshi, qui ne semble pas suivre cette règle.
Représentés graphiquement, ces ExtraNonces ont permis la visualisation du Patoshi Pattern pour lequel nous pouvons observer des pentes contiguës d’ExtraNonces.
De plus, le mineur Patoshi présente une restriction étrange dans les valeurs du nonce qu’il a trouvées pour ses blocs. Il existe plusieurs théories l’expliquant, mais je pense que la plus plausible est que Patoshi avait développé un logiciel de minage parallélisé et que les plages étaient allouées aux différents cœurs du processeur, chaque cœur balayant un espace de nonce donné.
Remarque : les techniques utilisées pour identifier les blocs Patoshi impliquent une certaine incertitude et il y a des collisions avec des blocs non-Patoshi dans lesquels les modèles ExtraNonce croisent ceux d’autres mineurs. Cependant, les blocs mal attribués sont probablement limités à un taux d’erreur bien inférieur à 1 %.
Les particularités de Patoshi
Si nous lisons la douzaine d’articles techniques qui analysent les blocs qui semblent avoir été minés par Satoshi, nous pouvons tirer plusieurs conclusions sur ce mineur :
- Il a utilisé un client Bitcoin personnalisé qui ne suivait pas le même comportement que le client Bitcoin accessible au public. En termes simples, les processeurs modernes ont plusieurs cœurs – plusieurs processeurs à l’intérieur d’une unité physique. Mais, à moins que vous ne conceviez votre logiciel de manière à ce qu’il puisse distribuer les calculs en parallèle sur plusieurs cœurs, il ne pourra utiliser qu’un seul cœur. Le premier client Bitcoin public n’a pas été écrit avec une capacité de parallélisation ; il ne fonctionnait que sur un cœur de processeur.
- Son taux de hachage était constant pendant des mois, puis a subi des diminutions systématiques.
- Moins de 20 des plus de 22 000 blocs (0,09 %) ont été dépensés.
- Satoshi semble avoir programmé l’activation et la désactivation de son mineur.
Satoshi endormi
Il y a un aspect étrange dans la distribution temporelle des blocs minés par Satoshi : ils ne suivent pas la distribution que nous attendrions d’un mineur qui passe 100 % de son temps à miner. En fait, il n’a pratiquement JAMAIS miné deux blocs consécutifs distants de moins de 5 minutes ! L’explication la plus simple c’est qu’il a programmé son mineur pour qu’il s’arrête pendant 5 minutes après avoir miné un bloc.
Comme l’explique Sergio Lerner dans ses recherches, il est possible que le mineur de Patoshi ait continué à miner juste après avoir trouvé un bloc, mais que son logiciel de minage personnalisé incrémentait artificiellement l’horodatage du bloc suivant de façon à ne pas être en dessous des 300 secondes.
En tout cas, c’est un phénomène intéressant qui est clairement le fruit d’une décision délibérée. Peut-on creuser plus profondément ? J’ai analysé la distribution des blocs de Patoshi de plusieurs manières différentes. Tout d’abord, si nous observons les différences d’horodatage entre les blocs minés par Patoshi et Patoshi uniquement, nous pouvons voir qu’il est assez clair qu’ils minaient rarement des blocs à moins de 5 minutes d’intervalle. La ligne de tendance de distribution delta d’horodatage attendue pour un mineur avec 4,35 mégahachages par seconde (Mhps) à un objectif de difficulté de 1 est affichée en bleu. Pour les besoins de ce graphique, j’utilise uniquement les données du bloc Patoshi pendant la période où elles semblaient exploiter à 4,35 Mhps.
Delta d’horodatage entre deux blocs « Patoshi »
Nous pouvons donc voir qu’il manque beaucoup de blocs « rapides ». Et si nous examinions TOUS les deltas des blocs Patoshi, y compris les blocs qui ont été extraits après des blocs non-Patoshi ?
Delta d’horodatage entre les blocs « Patoshi » et le bloc précédent
Cela semble un peu mieux – il est clair que Patoshi n’a pas éteint son mineur (ou ajusté ses horodatages de modèle de bloc) pendant 5 minutes (300 secondes) après avoir reçu un bloc miné par quelqu’un d’autre. Mais on peut aussi voir que le nombre de blocs minés qui ont pris plus de 10 minutes est beaucoup plus élevé que prévu ! Bien que cela soit en partie dû au fait que Satoshi diminue son hashrate au fil du temps, c’est amplifié par cette manipulation.
Ensuite, j’ai pris l’ensemble de données du graphique précédent et chaque fois qu’un bloc était extrait plus de 5 minutes après le bloc précédent, j’ai soustrait 5 minutes du delta de temps. Nous pouvons voir que cela nous donne un ensemble de données qui correspond beaucoup mieux à la distribution attendue.
Delta d’horodatage ajusté de 300 secondes entre les blocs « Patoshi » et le bloc précédent
Si vous n’avez pas lu mes recherches antérieures sur la variance du temps de bloc, vous vous demandez peut-être si ces graphiques sont réellement significatifs. Pour le savoir, il faut les comparer à un groupe témoin. À titre de comparaison, voici le tableau de TOUS les blocs minés pendant « l’ère CPU » de Bitcoin avant le décollage du minage GPU :
La question reste en suspens : ce phénomène unique est-il dû au fait que Satoshi a éteint son mineur pendant 5 minutes ou est-ce dû au fait qu’il a manipulé son horodatage de 5 minutes ? Je crois fermement que la machine de Satoshi dormait. Pourquoi ?
Une expérience de pensée : si Patoshi définissait simplement son horodatage de bloc 5 minutes dans le futur après avoir trouvé un bloc, nous nous attendrions à ce qu’un pourcentage anormalement élevé de blocs enfants non-Patoshi ait des horodatages antérieurs au deuxième bloc Patoshi, car les mineurs définissent des horodatages en fonction de l’horloge de leur machine locale. Cherchons :
- Une séquence de bloc Patoshi -> bloc Patoshi -> bloc non-Patoshi
- Le deuxième bloc Patoshi doit être miné moins de 10 minutes après le premier
- Trouver le delta d’horodatage entre le 2e bloc Patoshi et le bloc non-Patoshi
J’ai donc écrit ce script pour rechercher des blocs avec ces caractéristiques. Le script a trouvé 1 881 blocs correspondants. Parmi ces blocs :
- Seul 1 avait un delta d’horodatage négatif d’un bloc Patoshi parent
- Seuls 5 (0,3%) ont été créés moins de 5 minutes après un bloc parent Patoshi
De plus, si Patoshi n’avait manipulé que les horodatages des blocs qu’ils ont minés, ils n’auraient PAS été en mesure de cacher la distribution totale des blocs qu’ils ont minés sur une longue période de temps et n’auraient donc PAS pu cacher leur hashrate effectif. Gardez les chiffres suivants en tête pour la suite de cet article : 4,35 Mhps et 6 Mhps.
La domination du hashrate de Satoshi
Nous pouvons observer que le mineur de Satoshi a 4 époques de hachage distinctes. Il a suivi un plan de réduction de leur hashrate de 1,7 Mhps tous les cinq mois, mais un mois après la deuxième baisse de ce type, il a abandonné cette méthode au profit d’un hashrate en baisse continue.
Lorsque nous comparons le hashrate de Satoshi au reste du réseau, nous pouvons observer plus clairement que la puissance de hachage par d’autres mineurs a commencé à décoller en octobre 2009 alors que celle de Satoshi reculait encore.
En fait, jusqu’en octobre 2009, Satoshi était dans une position dangereusement dominante avec plus de la moitié du hashrate du réseau.
Plus intéressant encore, Satoshi n’est devenu un mineur au hashrate minoritaire qu’après avoir volontairement diminué son hashrate plusieurs fois. Cela suggère plusieurs choses :
- Satoshi avait prévu de diminuer son hashrate au fil du temps.
- Satoshi avait initialement un contrôle approximatif du hashrate.
- Satoshi a ensuite développé un contrôle plus fin du hashrate.
La double hélice
Vous avez peut-être remarqué que le premier diagramme de distribution d’horodatage dans la section « Quand Satoshi s’endort » excluait les blocs 1400-1916 de son ensemble de données. Pourquoi ? Parce qu’un phénomène unique s’est produit pendant cette période qui a brisé les calculs du delta d’horodatage du bloc Patoshi : deux mineurs Patoshi fonctionnaient simultanément !
Vous pouvez explorer ce modèle sur le site Web de SatoshiBlocks. Le motif en double hélice a probablement été causé par deux instances du logiciel Patoshi fonctionnant en parallèle. Nous ne savons pas s’il s’agissait d’une erreur commise par Patoshi ou s’il testait quelque chose. Que peut-on déduire de ce phénomène ?
Pendant cette période de 4 jours et 3 heures, Satoshi a miné 458 blocs. À partir de cela, nous pouvons estimer que leur taux de hachage agrégé total pendant cette période était d’environ 5,5 Mhps. Ceci est remarquable car le hashrate de Satoshi au cours des 5 premiers mois de 2009 est en moyenne de 4,3 Mhps. Cela explique également l’écart mis en évidence par rapport au tableau de hashrate précédent.
Pourquoi est-ce intéressant ? Si Satoshi avait mis en place une machine distincte similaire à la première, nous nous attendrions à ce que leur taux de hachage global soit plus proche de 8,6 Mhps pendant la période de double hélice. Pourtant, leur hashrate n’était que de 28% supérieur au lieu de 100%. Nous pouvons voir que les performances de chaque instance d’exploration de données sont réduites, ce qui entraîne une pente uniformément réduite d’ExtraNonces pour les deux instances par rapport à toutes les autres pentes de Patoshi. Pourquoi ? L’explication la plus simple est que les deux instances de minage se disputent les mêmes cœurs de processeur !
Sergio Lerner pense que nous pouvons en déduire que l’ordinateur de Satoshi était probablement un quad-core. Je pense que cela correspond, car il semble que les mineurs standards de l’époque atteignaient un taux de hachage d’un peu plus de 1 Mhps. Dans tous les cas, je pense que le motif en double hélice de Satoshi s’explique par deux instances de son logiciel personnalisé fonctionnant sur le même matériel.
Il y a plusieurs années, j’ai compilé tous les horodatages d’activité publique de Satoshi à partir d’e-mails, de messages de forum et de validations de code pour générer le tableau suivant. Ma conclusion est que Satoshi a maintenu un horaire de sommeil compatible avec quelqu’un séjournant dans le fuseau horaire du Pacifique.
Pourquoi est-ce que j’en parle ? Pour étayer ma théorie sur le phénomène de la double hélice ! Voici ce qui s’est passé, je pense :
- Satoshi a miné le bloc 1386 à 16 heures du Pacifique le 22 janvier 2009
- Le matériel / logiciel de Satoshi a planté peu de temps après
- Satoshi s’est réveillé, a vérifié le mineur peu avant 8 heures du matin le lendemain et a découvert qu’il avait mal fonctionné
- Il a redémarré le mineur et a trouvé un bloc à 8 heures du Pacifique
- À son insu, il a accidentellement démarré 2 instances
- Ces deux instances ont tourné pendant les 3 jours suivants, pendant un week-end, sans que Satoshi s’en aperçoive
- Peu de temps après, au bloc 1916 à 22 h 30, heure du Pacifique, le 25 janvier, le mineur a à nouveau planté
- Satoshi s’est réveillé et a vérifié leur mineur peu avant 7 heures du matin le 26 janvier et l’a relancé sur une seule instance
Séquences de blocs consécutifs
Nous savons que Satoshi avait la majorité du hashrate pendant les 9 premiers mois de 2009 ; pouvons-nous apprendre quelque chose de sa plus longue période de blocs consécutifs ? J’ai écrit un script de recherche de séquences et déterminé que Satoshi avait une séquence de 47 blocs de hauteur 80 à 127.
Cela devrait certainement être pris avec des pincettes étant donné qu’il s’agit d’une fenêtre d’environ 8 heures et que les estimations de hashrate deviennent moins précises à mesure que la plage de temps que vous observez se raccourcit, mais nous pouvons voir que le temps de bloc moyen était de 720 secondes, ce qui nous amène à estimer leur hashrate à 5,97 Mhps pendant cette période.
Satoshi a-t-il miné plus lentement pour maintenir la difficulté à un niveau bas ?
Rappelez-vous que nous avons plusieurs points de données qui suggèrent que la machine de Satoshi, bien que généralement observée à un taux de hachage de 4,35 Mhps, n’était probablement capable que d’un taux de hachage potentiel maximum de 6 Mhps. Un hashrate de 6 Mhps se traduit par un temps de bloc moyen attendu de 708 secondes. N’oubliez pas que la cible de difficulté ne s’ajuste pas tant que les derniers blocs de 2016 n’ont pas été extraits à un rythme moyen inférieur à 600 secondes. Ainsi, le hashrate du réseau global pour chaque unité de difficulté peut être exprimé comme suit :
hachages par seconde = 2^32 / 600 = 7 158 278 hachages par seconde.
Afin de pousser le temps moyen de création de blocs pour que Bitcoin ajuste la cible de difficulté de 1 à 2 , il faudrait plus de 7 158 278 * 1,5 = 10737417 hachages par seconde = 10,7 Mhps sur le réseau.
Cela signifie qu’il devrait y avoir un hashrate de plus de 4,7 Mhps d’autres mineurs sur le réseau afin de dépasser la cible de difficulté si Satoshi minait aussi vite que possible. Il est difficile de dire exactement combien de machines cela équivaudrait, bien que sur la base de certains des caractéristiques de CPU disponibles ici, je suppose que le processeur de bureau commun moyen utilisant le premier mineur Bitcoin non optimisé produisait probablement un peu plus de 1 Mhps. Il existe également des preuves de premiers mineurs publiant leurs hashrates sur BitcoinTalk. Nous pouvons également observer cela et montrer que c’est probable en comparant les pentes ExtraNonce des mineurs non-Patoshi avec les pentes ExtraNonce minées par Patoshi : celle de Patoshi est 3 fois plus raide que les autres mineurs. Ainsi, nous n’aurions besoin que de 4 ou 5 autres mineurs sur le réseau pour augmenter la difficulté.
J’ai écrit un autre script pour extraire l’historique des difficultés de la blockchain :
| Hauteur | Date | Difficulté |
|---|---|---|
| 0 | 2009-01-03 | 1 |
| 40320 | 2010-02-14 | 2 |
| 42336 | 2010-02-24 | 3 |
| 44352 | 2010-03-07 | 4 |
| 48384 | 2010-04-01 | 6 |
| 50400 | 2010-04-12 | 7 |
| 52416 | 2010-04-21 | 11 |
| 54432 | 2010-05-04 | 12 |
| 56448 | 2010-05-19 | 11 |
| 58464 | 2010-05-29 | 16 |
| 60480 | 2010-06-11 | 17 |
Voici un graphique du hashrate total du réseau pendant la période en question :
Pour comprendre comment les ajustements de difficulté auraient changé, nous devons nous demander à quel moment le hashrate du réseau mondial aurait dépassé 10,7 Mhps si Satoshi avait miné à son maximum de 6 Mhps.
En regardant le graphique et en ajoutant le hashrate supplémentaire potentiel manquant de Satoshi, il semble que le réseau aurait dépassé 10,7 Mhps à la mi-décembre 2009 et que la difficulté se serait ajustée à 2 au bloc 32256, environ 2,5 mois plus tôt.
Donc non, l’affirmation selon laquelle Satoshi a miné plus lentement afin de maintenir la difficulté à un niveau bas est ridicule. Il aurait pu extraire BEAUCOUP PLUS de blocs et ainsi gagner BEAUCOUP PLUS de BTC en fonctionnant à son potentiel de hachage maximum sans augmenter la difficulté. Au moment où la difficulté a réellement augmenté, Satoshi avait déjà considérablement réduit son hashrate.
Qu’est-ce qu’un Satoshi cupide aurait fait différemment ?
L’analyse du Patoshi Pattern de Sergio a identifié environ 22 000 blocs appartenant à Satoshi. Certains d’entre eux sont sûrement des faux positifs, mais il y a de bonnes raisons de croire (en raison des multiples empreintes utilisées pour identifier les blocs) que le taux de faux positifs est inférieur à 1 %. Cela ramène le montant total extrait par Satoshi à environ 1 100 000 BTC.
Si Satoshi N’avait PAS décidé de diminuer son hashrate plusieurs fois fin 2009, combien de BTC aurait-il gagné en plus ? Ceci est simple à calculer si nous supposons un objectif de difficulté constant de 1. Nous savons, en observant le taux de création des blocs de Satoshi et l’objectif de difficulté de 1, que son hashrate initial était d’environ 4 350 000 hachages par seconde (4,35 Mhps). Le bloc final attribué à Satoshi était le 54 316 ; exactement 14 mois après l’extraction du bloc de genèse. Combien de blocs Satoshi aurait-il pu extraire s’il avait dépensé 4,35 Mhps pendant 14 mois avec un objectif de difficulté de 1 ?
secondes attendues pour trouver un bloc = difficulté * 2 ^ 32 / hachages par seconde
1 * 2^32 / 4 350 000 = 987,35 secondes par bloc pour Satoshi
36817200 secondes (14 mois) / 987,35 blocs = 37302 blocs = 1 865 100 BTC
Malheureusement, c’est un peu plus compliqué, car la difficulté de minage a commencé à augmenter au bloc 40320 le 14 février 2010 et Satoshi a continué à miner jusqu’au 3 mai 2010 au moins. Ca se complique encore si l’on considère que la puissance de hachage potentielle maximale de Satoshi aurait permis d’avancer le premier ajustement de difficulté d’environ 2,5 mois.
Nous pouvons utiliser le tableau de changement de difficulté historique publié précédemment et avancer les délais d’autant. Si nous supposons que Satoshi a encore miné pendant 479 jours mais à une vitesse soutenue de 4,35 Mhps, cela donnerait à peu près ce qui suit :
| Difficulté | Période | Secondes par bloc | Blocs Satoshi attendus |
|---|---|---|---|
| 1 | 339 jours | 987 | 29 665 |
| 2 | 10 jours | 1974 | 437 |
| 3 | 14 jours | 2962 | 408 |
| 4 | 24 jours | 3949 | 525 |
| 6 | 12 jours | 5924 | 175 |
| sept | 9 jours | 6911 | 113 |
| 11 | 14 jours | 10861 | 111 |
| 12 | 15 jours | 11848 | 109 |
| 11 | 10 jours | 10861 | 80 |
| 16 | 13 jours | 15798 | 71 |
| 17 | 13 jours | 16785 | 67 |
| 23 | 6 jours | 22709 | 23 |
Ce qui revient à 31 783 blocs soit un total de 1 589 150 BTC.
Cependant, nous devons également nous rappeler que Satoshi éteignait régulièrement son mineur lorsqu’il trouvait des blocs distants de moins de 5 minutes. Il s’agit en fait d’une limitation délibérée supplémentaire de son hashrate. Alors, combien de hashrate Satoshi laissait-il réellement sur la table ? Nous pouvons obtenir une assez bonne estimation basée sur notre connaissance de la distribution de Poisson des blocs. Note : si vous voulez en savoir plus, vous pouvez consulter mon article précédent sur la variance du temps de bloc.
Quel pourcentage de blocs devrait être miné moins de 5 minutes après le bloc précédent ? 1 – exp(−5/10) = 39,35 %. Le hashrate potentiel maximum de Satoshi était en fait plus proche de 6,06 Mhps. C’est un résultat intéressant car il est également assez proche du hashrate observé de 5,5 Mhps à l’ère de la double hélice et extrêmement proche du hashrate observé de 5,97 Mhps au cours de leur première séquence de 47 blocs.
Réexécutons le calcul précédent, mais en considérant que Satoshi utilise son taux de hachage maximum théorique de 6 Mhps.
| Difficulté | Période | Secondes par bloc | Blocs Satoshi attendus |
|---|---|---|---|
| 1 | 339 jours | 716 | 40 907 |
| 2 | 10 jours | 1432 | 603 |
| 3 | 14 jours | 2147 | 563 |
| 4 | 24 jours | 2863 | 724 |
| 6 | 12 jours | 4295 | 241 |
| sept | 9 jours | 5011 | 155 |
| 11 | 14 jours | 7874 | 154 |
| 12 | 15 jours | 8590 | 151 |
| 11 | 10 jours | 7874 | 110 |
| 16 | 13 jours | 11453 | 98 |
| 17 | 13 jours | 12169 | 92 |
| 23 | 6 jours | 16464 | 31 |
Soit un total de 43 829 blocs ou 2 191 450 BTC .
Pourquoi Satoshi n’a-t-il pas détruit ses bitcoins ?
La première transaction qui a effectué un dépôt à une adresse manifestement inutilisable était à 111111111111111111114oLvT2 le 10 août 2010 et le premier message que j’ai pu trouver la référençant a été posté un mois plus tard, notant qu’il s’agissait de « la plus petite adresse bitcoin possible« . D »autres intervenants l’ont nommée « l’adresse zéro » car elle avait été créée à partir d’un hachage de tous les zéros. Ces discussions avaient tendance à se focaliser sur les cas extrêmes de la validité d’une adresse bitcoin et non sur les cas d’utilisation pour brûler délibérément des bitcoins.
Autant que je sache, la première utilisation consciente d’une adresse de « burn » a eu lieu le 20 juin 2011 avec cette transaction à 1BitcoinEaterAddressDontSendf59kuE. La discussion la plus ancienne sur les adresses de destruction que j’ai pu trouver a eu lieu le 23 juin 2011 sur ce fil BitcoinTalk à propos de « The Bitcoin Black Hole ».
La dernière activité de Satoshi sur BitcoinTalk remonte au 13 décembre 2010. La dernière fois que quelqu’un a entendu parler de lui, c’était le 26 avril 2011. Il est tout à fait plausible que Satoshi n’ait jamais envisagé l’option de brûler ses bitcoins.
Conclusion
Satoshi a-t-il arrêté de miner avec le mineur Patoshi après le bloc 54 316 ?Il est impossible de savoir si le logiciel de minage a été modifié et est devenu indétectable ou si Satoshi a continué à miner en utilisant le logiciel de minage accessible au public.
De quoi suis-je sûr concernant Satoshi ?
- Son objectif était de maintenir le « battement de cœur » du réseau pendant son amorçage.
- Il a miné sur une seule machine avec un hashrate maximum de 6 Mhps.
- Il aurait facilement pu gagner plus de deux fois plus de BTC s’il avait miné à pleine puissance.
- Il ne voulait pas être en position de dominer le hashrate du réseau, mais il a peut-être estimé que c’était nécessaire dans les premiers temps, lorsque le réseau était beaucoup plus fragile en raison de la présence de moins de cinq mineurs.
- Il se souciait beaucoup des ajustements de difficulté. L’algorithme d’ajustement était l’une des plus grandes innovations de Satoshi et il a été particulièrement loquace sur ce sujet.
- Il voulait que le plus grand nombre possible de personnes puissent miner sur des PC domestiques (Satoshi a dénoncé la course à la performance des FGPA ou des GPU)
« Nous devrions avoir un gentleman’s agreement pour reporter la course aux armements GPU aussi longtemps que possible pour le bien du réseau. Il est beaucoup plus facile d’inclure de nouveaux utilisateurs s’ils n’ont pas à se soucier des pilotes GPU et de leur compatibilité. C’est une bonne chose que quiconque, avec un simple processeur, puisse actuellement rivaliser d’égal à égal. »
Quiconque prétend que Satoshi était cupide n’a tout simplement pas fait le calcul.
Source : blog.lopp.net
