Crash test / Réseau à preuve de travail / CT-BTC-001

Bitcoin (BTC)

bitcoin-mainnet · Actif natif · pilot-1

Le verdict

Non noté · 0% Couverture des preuves

Promesse documentée. Vérification indépendante en attente.

Les preuves disponibles sont insuffisantes pour attribuer une note globale. La description du mécanisme demande une vérification de son fonctionnement actuel.

Consulter les preuves

Non notéNote globale / 100

0%Couverture des preuves

13 contrôles en attente85% de couverture et 3 contrôles essentiels requis pour une note

2026-10-03Documentation vérifiée · Méthode candidate 0.1.0

Revue documentaire · Relecture 2026-10-04 · translation-1-94189ac5fe1a

La revue des sources explique les mécanismes documentés. Les contrôles indépendants du réseau restent à réaliser.

Promesse et périmètre

Ce dossier examine le Bitcoin natif BTC sur bitcoin-mainnet. Le périmètre couvre la validation des paiements, les mécanismes d'émission et une divulgation historique spécifique de septembre 2018 concernant une vulnérabilité logicielle. Il distingue les mineurs qui produisent des blocs des nœuds de validation qui appliquent les règles de consensus. L'analyse conserve les inconnues relatives à la propriété actuelle, au contrôle, à l'utilisation et à la liquidité. Cette revue ne traite pas l'incident unique divulgué comme un historique complet des événements du réseau ou comme une exploitation reproduite indépendamment. Aucune affirmation numérique actuelle sur le réseau n'est faite.

Faits établis : Validation et émission

Le guide développeur Bitcoin décrit les nœuds complets comme des validateurs indépendants qui vérifient les blocs par rapport aux règles de consensus. La preuve de travail lie ces blocs entre eux. Le guide distingue la subvention de bloc, qui crée de nouvelles unités, des frais de transaction, qui transfèrent des unités existantes. Cette documentation explique les règles mais ne mesure pas la concentration minière ni l'utilisation réelle du réseau. Un satoshi est défini comme 1/100,000,000 d'un BTC. La subvention désigne les nouveaux BTC créés par bloc. Les frais transfèrent des unités existantes dans le cadre d'une transaction. Le halving est la réduction programmée de la subvention de bloc.

La divulgation des mainteneurs en 2018

Le 20 septembre 2018, les mainteneurs de Bitcoin Core ont divulgué CVE-2018-17144. Ce rapport identifiait un bug de déni de service et une vulnérabilité critique d'inflation. Un correctif a été publié le 18 septembre 2018 dans les versions 0.16.3 et 0.17.0rc4. Le compte rendu expliquait que les versions vulnérables pouvaient compter deux fois une sortie de transaction précédemment créée, permettant potentiellement une émission excessive. Les mainteneurs ont initialement divulgué le risque de crash et contacté les opérateurs affectés avant de publier l'impact sur l'inflation pour encourager les mises à jour. Ils ont déclaré ne pas connaître d'exploitation au moment de la publication. Cette déclaration historique n'établit pas qu'une exploitation n'a jamais eu lieu. Cette source illustre pourquoi une règle théorique d'émission dépend d'une implémentation logicielle correcte. Une règle de code nécessite une assurance d'implémentation pour prévenir les comportements non intentionnels tels que le double comptage des sorties.

Calcul reproductible et tokenomics

Bitcoin Core v29.0 définit MAX_MONEY comme 21,000,000 BTC. Son commentaire identifie explicitement cette valeur comme une vérification de plage de consensus, et non comme l'offre totale réelle. Aucune offre en circulation ou dépensable n'a été mesurée ici. La fonction GetBlockSubsidy dans v29.0 commence à 50 BTC et décale à droite le montant par le nombre d'intervalles de halving en utilisant une arithmétique entière de satoshis. La règle est exprimée en hauteurs de bloc. Cette version historique est une observation de code, non une confirmation des clients déployés aujourd'hui. Le calcul original Cryptosnif (bitcoin-subsidy-1) reproduit cette fonction vérifiée en utilisant des satoshis entiers exacts. Aux hauteurs illustratives 0, 210000, 840000 et 2100000, la subvention autorisée est respectivement de 50, 25, 3.125 et 0.04882812 BTC. Ces hauteurs sont des exemples, non des observations du réseau actuel. Les époques 0 à 32 ont une subvention positive ; l'époque 32 autorise 1 satoshi par bloc. L'époque 33 commence à la hauteur 6930000 avec une subvention nulle. Aucune date calendaire n'est inférée. À l'époque 10, 50/1024 égale 0.048828125 BTC, tandis que l'arithmétique entière donne 0.04882812 BTC. Les paramètres mainnet fixent l'intervalle de halving de la subvention à 210,000 blocs. Un calendrier basé sur les blocs n'établit pas une date calendaire future exacte. L'émission native de subvention de bloc diffère d'une libération contractuelle d'une allocation existante. Cette revue n'identifie pas le BTC enveloppé tiers ou les allocations sous garde comme une émission native. Le calcul original Cryptosnif somme 210000 * floor(5000000000 / 2^k) satoshis pour k=0..32, donnant 2099999997690000 satoshis (20999999.97690000 BTC). C'est une allowance théorique totale de subvention sous les règles v29.0 en supposant que chaque subvention autorisée est réclamée, y compris la genèse. Cela exclut les frais. La source indique que la sortie de genèse ne peut être dépensée. Par conséquent, cette allowance calculée ne mesure pas l'offre actuelle émise, en circulation ou dépensable ; les pièces perdues et les subventions non réclamées nécessitent des preuves séparées.

Inconnues et conséquences

La concentration actuelle de la propriété, les pouvoirs de contrôle privilégiés, l'utilisation mesurée indépendamment, l'exhaustivité et l'efficacité de la remédiation des incidents ainsi que la liquidité localement exécutable restent non vérifiées dans ce pilote. La couverture des preuves est insuffisante pour un score global. Un mécanisme documenté seul ne peut établir la résilience actuelle ou les rendements attendus. Tous les critères opérationnels restent inconnus. Les scores restent non notés.

Verdict et ce qui changerait cela

Promesse documentée. Vérification indépendante en attente. Des observations réseau reproductibles, des cartes actuelles du contrôle, des règles d'offre documentées et des registres d'incidents indépendants permettraient d'évaluer les vérifications en attente.

01 / Faits établis

Faits établis

Le document primaire ci-dessous est accessible et décrit la promesse du projet. Les contrôles indépendants de fonctionnement restent à réaliser.

Affirmation du projet

Extrait du rapport en anglais

The original Bitcoin paper describes electronic payments verified by a distributed network using proof of work, a mechanism that makes rewriting history computationally costly. [1]

02 / Inconnues

Ce qui reste inconnu

La concentration des détenteurs, les pouvoirs de contrôle, l’usage actuel, les incidents et la liquidité locale restent à vérifier.

Preuves insuffisantes

Les preuves disponibles sont insuffisantes pour attribuer une note globale. La description du mécanisme demande une vérification de son fonctionnement actuel.

03 / Crash test

Chaque contrôle demande ses preuves.

Méthode candidate 0.1.0. Les résultats inconnus sont exclus du calcul de la note.
Contrôle	Poids	Résultat
Identité exacte de l’actifEssentiel	3%	Vérification en attente
Usage observable	15%	Vérification en attente
Rôle économique du token	10%	Vérification en attente
Mécanismes d’offreEssentiel	10%	Vérification en attente
Concentration des détenteurs	8%	Vérification en attente
Captation de valeur	7%	Vérification en attente
Pouvoirs de contrôleEssentiel	10%	Vérification en attente
Vérification de la sécurité	7%	Vérification en attente
Processus de décision	8%	Vérification en attente
Responsabilités	7%	Vérification en attente
Historique des incidents	6%	Vérification en attente
Continuité du fonctionnement	4%	Vérification en attente
Conditions d’exécution	5%	Vérification en attente

Contrôles propres à la famille: Concentration du hashrate, règles de consensus, indépendance des nœuds complets.

04 / Preuves

Consulter les preuves

Les sources de cette analyse

Les titres et résumés des sources sont en anglais.

Bitcoin Core: pinned CVE-2018-17144 disclosure

Bitcoin Core's disclosure dated September 20, 2018 reports CVE-2018-17144, a denial-of-service bug and critical inflation vulnerability. A patch was released on September 18, 2018 in versions 0.16.3 and 0.17.0rc4. The write-up explains that particular vulnerable versions could count a previously created transaction output twice, potentially allowing excess issuance. The maintainers initially disclosed the crash risk and contacted affected operators before publishing the inflation impact to encourage upgrades. They stated that they were unaware of exploitation at publication; this historical statement does not establish that exploitation never occurred. This is a primary maintainer disclosure, not an independently reproduced exploit, a complete Bitcoin incident history or proof about current clients. The source illustrates why a theoretical issuance rule also depends on correct software implementation.