Crash test / Proof-of-work network / CT-BTC-001

Bitcoin (BTC)

bitcoin-mainnet · Native asset · pilot-1

The verdict

Unrated · 0% Evidence coverage

Documented promise. Independent verification pending.

The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns.

Inspect the evidence

UnratedOverall score / 100

0%Evidence coverage

13 checks pending85% coverage and 3 essential checks required for a score

2026-10-03Documentation checked · Candidate method 0.1.0

Documentation review · Reviewed 2026-10-04 · editorial-3-candidate

The source review explains documented mechanisms. Independent network checks remain pending.

Promise and Scope

This dossier examines native Bitcoin BTC on bitcoin-mainnet. The scope covers payment validation, issuance mechanics, and a specific historical disclosure from September 2018 regarding a software vulnerability. It distinguishes between miners who produce blocks and validating nodes that enforce consensus rules. The analysis retains unknowns regarding current ownership, control, usage, and liquidity. This review does not treat the single disclosed incident as a complete history of network events or an independently reproduced exploit. No current numerical network claims are made.

Established Facts: Validation and Issuance

The Bitcoin developer guide describes full nodes as independent validators that check blocks against consensus rules. Proof of work links these blocks together. The guide distinguishes between block subsidy, which creates new units, and transaction fees, which transfer existing units. This documentation explains the rules but does not measure mining concentration or actual network usage. A satoshi is defined as 1/100,000,000 of a BTC. Subsidy refers to the new BTC created per block. Fees transfer existing units as part of a transaction. Halving is the scheduled reduction of the block subsidy.

The 2018 Maintainer Disclosure

On September 20, 2018, Bitcoin Core maintainers disclosed CVE-2018-17144. This report identified a denial-of-service bug and a critical inflation vulnerability. A patch was released on September 18, 2018, in versions 0.16.3 and 0.17.0rc4. The write-up explained that vulnerable versions could count a previously created transaction output twice, potentially allowing excess issuance. Maintainers initially disclosed the crash risk and contacted affected operators before publishing the inflation impact to encourage upgrades. They stated they were unaware of exploitation at publication. This historical statement does not establish that exploitation never occurred. This source illustrates why a theoretical issuance rule depends on correct software implementation. A code rule requires implementation assurance to prevent unintended behavior such as double counting outputs.

Reproducible Calculation and Tokenomics

Bitcoin Core v29.0 defines MAX_MONEY as 21,000,000 BTC. Its comment explicitly identifies this value as a consensus range check, not the actual total supply. No circulating or spendable supply has been measured here. The GetBlockSubsidy function in v29.0 starts at 50 BTC and right-shifts the amount by the number of halving intervals using integer satoshi arithmetic. The rule is expressed in block heights. This historical version is a code observation, not confirmation of today’s deployed clients. Original Cryptosnif calculation (bitcoin-subsidy-1) reproduces this verified function using exact integer satoshis. At illustrative heights 0, 210000, 840000 and 2100000 the allowed subsidy is respectively 50, 25, 3.125 and 0.04882812 BTC. These heights are examples, not observations of today's network. Epochs 0 through 32 have positive subsidy; epoch 32 allows 1 satoshi per block. Epoch 33 starts at height 6930000 with zero subsidy. No calendar date is inferred. At epoch 10, 50/1024 equals 0.048828125 BTC, while integer arithmetic yields 0.04882812 BTC. Mainnet parameters set the subsidy halving interval to 210,000 blocks. A block-based schedule does not establish an exact future calendar date. Native block subsidy issuance differs from a contractual release of an existing allocation. This review does not identify third-party wrapped BTC or custodial allocations as native issuance. Original Cryptosnif calculation sums 210000 * floor(5000000000 / 2^k) satoshis for k=0..32, giving 2099999997690000 satoshis (20999999.97690000 BTC). This is a theoretical total subsidy allowance under v29.0 rules assuming every allowed subsidy is claimed, including genesis. It excludes fees. The source states the genesis output cannot be spent. Therefore this calculated allowance does not measure current issued, circulating or spendable supply; lost coins and unclaimed subsidies require separate evidence.

Unknowns and Consequences

Current ownership concentration, privileged control powers, independently measured usage, the completeness and effectiveness of incident remediation and locally executable liquidity remain unverified in this pilot. The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns. All operational criteria remain unknown. Scores remain unrated.

Verdict and What Would Change It

Documented promise. Independent verification pending. Reproducible network observations, current control maps, documented supply rules and independent incident records would allow the pending checks to be evaluated.

01 / Established facts

Established facts

The linked primary document is available. Its existence establishes what the project describes, while the operational checks remain open.

Project claim

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 / Unknowns

What remains unknown

Current ownership concentration, privileged control powers, independently measured usage, incident remediation and locally executable liquidity remain unverified in this pilot.

Insufficient evidence

The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns.

03 / Crash test

Each check earns its result.

Candidate method 0.1.0. Unknown results are excluded from the score calculation.
Check	Weight	Result
Exact asset identityEssential	3%	Verification pending
Observable use	15%	Verification pending
Economic role of the token	10%	Verification pending
Supply mechanismsEssential	10%	Verification pending
Ownership concentration	8%	Verification pending
Value capture	7%	Verification pending
Control powersEssential	10%	Verification pending
Security verification	7%	Verification pending
Decision process	8%	Verification pending
Accountability	7%	Verification pending
Incident history	6%	Verification pending
Operational continuity	4%	Verification pending
Execution conditions	5%	Verification pending

Family-specific checks: Hashrate concentration, consensus rules, full-node independence.

04 / Evidence

Inspect the evidence

Sources behind this analysis

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.