cryptosnifBitcoin (BTC)
bitcoin-mainnet · Ativo nativo · pilot-1Sem nota · 0% Cobertura das evidências
Promessa documentada. Verificação independente pendente.
As evidências disponíveis são insuficientes para atribuir uma nota geral. O mecanismo descrito exige verificação do funcionamento atual.
Consultar as evidênciasA revisão das fontes explica os mecanismos documentados. As verificações independentes da rede continuam pendentes.
Promessa e Escopo
Este dossiê examina o Bitcoin nativo BTC na bitcoin-mainnet. O escopo abrange a validação de pagamentos, os mecanismos de emissão e uma divulgação histórica específica de setembro de 2018 referente a uma vulnerabilidade de software. Ele distingue entre mineradores que produzem blocos e nós de validação que aplicam regras de consenso. A análise mantém incógnitas sobre propriedade, controle, uso e liquidez atuais. Esta revisão não trata o único incidente divulgado como um histórico completo de eventos da rede ou como uma exploração reproduzida independentemente. Nenhuma afirmação numérica atual sobre a rede é feita.
Fatos Estabelecidos: Validação e Emissão
O guia do desenvolvedor do Bitcoin descreve nós completos como validadores independentes que verificam blocos contra regras de consenso. A prova de trabalho vincula esses blocos. O guia distingue entre subsídio de bloco, que cria novas unidades, e taxas de transação, que transferem unidades existentes. Esta documentação explica as regras, mas não mede a concentração de mineração nem o uso real da rede. Um satoshi é definido como 1/100.000.000 de um BTC. Subsídio refere-se ao novo BTC criado por bloco. Taxas transferem unidades existentes como parte de uma transação. Halving é a redução programada do subsídio de bloco.
A Divulgação dos Mantenedores em 2018
Em 20 de setembro de 2018, mantenedores do Bitcoin Core divulgaram a CVE-2018-17144. Este relatório identificou um bug de negação de serviço e uma vulnerabilidade crítica de inflação. Um patch foi lançado em 18 de setembro de 2018, nas versões 0.16.3 e 0.17.0rc4. A descrição explicou que versões vulneráveis podiam contar duas vezes uma saída de transação previamente criada, potencialmente permitindo emissão excessiva. Os mantenedores inicialmente divulgaram o risco de falha e contataram operadores afetados antes de publicar o impacto da inflação para incentivar atualizações. Eles afirmaram que não estavam cientes de exploração no momento da publicação. Esta declaração histórica não estabelece que a exploração nunca ocorreu. Esta fonte ilustra por que uma regra teórica de emissão depende da implementação correta do software. Uma regra de código exige garantia de implementação para prevenir comportamento indesejado, como a contagem dupla de saídas.
Cálculo Reproduzível e Tokenomics
O Bitcoin Core v29.0 define MAX_MONEY como 21.000.000 BTC. Seu comentário identifica explicitamente este valor como uma verificação de faixa de consenso, não como o fornecimento total real. Nenhum fornecimento circulante ou gastável foi medido aqui. A função GetBlockSubsidy na v29.0 começa em 50 BTC e desloca à direita o valor pelo número de intervalos de halving, usando aritmética inteira de satoshis. A regra é expressa em alturas de bloco. Esta versão histórica é uma observação de código, não confirmação dos clientes implantados hoje. O cálculo original da Cryptosnif (bitcoin-subsidy-1) reproduz esta função verificada usando satoshis inteiros exatos. Nas alturas ilustrativas 0, 210000, 840000 e 2100000, o subsídio permitido é respectivamente 50, 25, 3.125 e 0.04882812 BTC. Estas alturas são exemplos, não observações da rede atual. As épocas 0 a 32 têm subsídio positivo; a época 32 permite 1 satoshi por bloco. A época 33 começa na altura 6930000 com subsídio zero. Nenhuma data de calendário é inferida. Na época 10, 50/1024 equivale a 0.048828125 BTC, enquanto a aritmética inteira produz 0.04882812 BTC. Parâmetros da mainnet definem o intervalo de halving do subsídio em 210.000 blocos. Um cronograma baseado em blocos não estabelece uma data futura exata no calendário. A emissão nativa de subsídio de bloco difere de uma liberação contratual de uma alocação existente. Esta revisão não identifica BTC embrulhado por terceiros ou aloções custodiadas como emissão nativa. O cálculo original da Cryptosnif soma 210000 * floor(5000000000 / 2^k) satoshis para k=0..32, resultando em 2099999997690000 satoshis (20999999.97690000 BTC). Este é um limite teórico total de subsídio sob as regras da v29.0 assumindo que todo subsídio permitido seja reivindicado, incluindo o genesis. Ele exclui taxas. A fonte afirma que a saída genesis não pode ser gasta. Portanto, este limite calculado não mede o fornecimento emitido, circulante ou gastável atual; moedas perdidas e subsídios não reivindicados exigem evidências separadas.
Incógnitas e Consequências
A concentração atual de propriedade, poderes de controle privilegiados, uso medido independentemente, a completude e eficácia da remediação de incidentes e a liquidez executável localmente permanecem não verificadas neste piloto. A cobertura das evidências é insuficiente para uma pontuação geral. Um mecanismo documentado sozinho não pode estabelecer resiliência atual ou retornos esperados. Todos os critérios operacionais permanecem desconhecidos. As pontuações permanecem sem nota.
Veredito e O Que Mudaria Isso
Promessa documentada. Verificação independente pendente. Observações de rede reproduzíveis, mapas de controle atuais, regras de fornecimento documentadas e registros independentes de incidentes permitiriam que as verificações pendentes fossem avaliadas.
Fatos documentados
O documento primário abaixo está disponível e descreve a promessa do projeto. As verificações independentes do funcionamento continuam pendentes.
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]
O que ainda é desconhecido
A concentração dos detentores, os poderes de controle, o uso atual, os incidentes e a liquidez local ainda precisam ser verificados.
As evidências disponíveis são insuficientes para atribuir uma nota geral. O mecanismo descrito exige verificação do funcionamento atual.
Cada verificação exige evidências.
| Verificação | Peso | Resultado |
|---|---|---|
| Identidade exata do ativoEssencial | 3% | Verificação pendente |
| Uso observável | 15% | Verificação pendente |
| Papel econômico do token | 10% | Verificação pendente |
| Mecanismos de ofertaEssencial | 10% | Verificação pendente |
| Concentração dos detentores | 8% | Verificação pendente |
| Captura de valor | 7% | Verificação pendente |
| Poderes de controleEssencial | 10% | Verificação pendente |
| Verificação de segurança | 7% | Verificação pendente |
| Processo de decisão | 8% | Verificação pendente |
| Responsabilidades | 7% | Verificação pendente |
| Histórico de incidentes | 6% | Verificação pendente |
| Continuidade operacional | 4% | Verificação pendente |
| Condições de execução | 5% | Verificação pendente |
Verificações específicas da família: Concentração de hashrate, regras de consenso, independência do nó completo.
Consultar as evidências
Fontes desta análise
Os títulos e resumos das fontes estão em inglês.
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.
Consultar a fonte primária ↗Bitcoin developer guide: block chain
The developer guide describes full nodes independently validating blocks against consensus rules, proof of work linking blocks, and the difference between a block subsidy (new units) and transaction fees (existing units). This is a description of rules, not a live measurement of mining concentration or use.
Consultar a fonte primária ↗Bitcoin Core v29.0: amount constants
Bitcoin Core v29.0 defines 100,000,000 satoshis per BTC and a MAX_MONEY value of 21,000,000 BTC. Its comment explicitly identifies MAX_MONEY as a consensus range check, not the actual total supply. No circulating or spendable supply has been measured here.
Consultar a fonte primária ↗Bitcoin Core v29.0: block subsidy function
The GetBlockSubsidy function in Bitcoin Core 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 or the current subsidy. 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 = 0.048828125 BTC, while integer arithmetic yields 0.04882812 BTC.
Consultar a fonte primária ↗Bitcoin Core v29.0: mainnet parameters
Mainnet parameters in Bitcoin Core v29.0 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. This source also 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.
Consultar a fonte primária ↗[1] Bitcoin documentação primáriaAfirmação do projeto
The project publishes the mechanism described above.
Observação 2026-10-03 · Válido até 2026-11-02
Consultar a fonte primária ↗Somente resumos originais são distribuídos. Os dados brutos de mercado sob licença permanecem privados.
O que mudaria este parecer
Observações reproduzíveis da rede, um mapa dos poderes de controle e a verificação das regras de emissão permitiriam completar os testes.
Nenhuma correção registrada para pilot-1. As revisões preservam suas fontes e os pareceres anteriores.