cryptosnifBitcoin (BTC)
bitcoin-mainnet · Activo nativo · pilot-1Sin puntuación · 0% Cobertura de las pruebas
Promesa documentada. Verificación independiente pendiente.
Las pruebas disponibles son insuficientes para asignar una puntuación global. El mecanismo descrito requiere verificar su funcionamiento actual.
Consultar las pruebasLa revisión de las fuentes explica los mecanismos documentados. Los controles independientes de la red siguen pendientes.
Promesa y Alcance
Este dossier examina Bitcoin nativo BTC en bitcoin-mainnet. El alcance cubre la validación de pagos, los mecanismos de emisión y una divulgación histórica específica de septiembre de 2018 sobre una vulnerabilidad de software. Distingue entre mineros que producen bloques y nodos de validación que aplican las reglas de consenso. El análisis mantiene incógnitas respecto a la propiedad actual, el control, el uso y la liquidez. Esta revisión no trata el único incidente divulgado como una historia completa de eventos de red o un exploit reproducido independientemente. No se hacen afirmaciones numéricas actuales sobre la red.
Hechos Establecidos: Validación y Emisión
La guía para desarrolladores de Bitcoin describe los nodos completos como validadores independientes que verifican bloques contra las reglas de consenso. La prueba de trabajo vincula estos bloques. La guía distingue entre subsidio de bloque, que crea nuevas unidades, y tarifas de transacción, que transfieren unidades existentes. Esta documentación explica las reglas pero no mide la concentración de minería ni el uso real de la red. Un satoshi se define como 1/100,000,000 de un BTC. Subsidio se refiere al nuevo BTC creado por bloque. Las tarifas transfieren unidades existentes como parte de una transacción. Halving es la reducción programada del subsidio de bloque.
La Divulgación de Mantenedores de 2018
El 20 de septiembre de 2018, los mantenedores de Bitcoin Core divulgaron CVE-2018-17144. Este informe identificó un bug de denegación de servicio y una vulnerabilidad crítica de inflación. Se lanzó un parche el 18 de septiembre de 2018, en las versiones 0.16.3 y 0.17.0rc4. El escrito explicó que las versiones vulnerables podían contar dos veces una salida de transacción previamente creada, permitiendo potencialmente una emisión excesiva. Los mantenedores divulgaron inicialmente el riesgo de caída y contactaron a los operadores afectados antes de publicar el impacto inflacionario para fomentar las actualizaciones. Declararon que desconocían cualquier explotación en el momento de la publicación. Esta declaración histórica no establece que la explotación nunca ocurrió. Esta fuente ilustra por qué una regla teórica de emisión depende de una implementación correcta del software. Una regla de código requiere garantía de implementación para prevenir comportamiento no intencionado como el doble conteo de salidas.
Cálculo Reproducible y Tokenomics
Bitcoin Core v29.0 define MAX_MONEY como 21,000,000 BTC. Su comentario identifica explícitamente este valor como una verificación de rango de consenso, no el suministro total real. No se ha medido aquí ningún suministro circulante o gastable. La función GetBlockSubsidy en v29.0 comienza en 50 BTC y desplaza a la derecha la cantidad por el número de intervalos de halving usando aritmética entera de satoshis. La regla se expresa en alturas de bloque. Esta versión histórica es una observación de código, no una confirmación de los clientes desplegados hoy. El cálculo original de Cryptosnif (bitcoin-subsidy-1) reproduce esta función verificada usando satoshis enteros exactos. En las alturas ilustrativas 0, 210000, 840000 y 2100000 el subsidio permitido es respectivamente 50, 25, 3.125 y 0.04882812 BTC. Estas alturas son ejemplos, no observaciones de la red actual. Las épocas 0 a través de 32 tienen subsidio positivo; la época 32 permite 1 satoshi por bloque. La época 33 comienza en la altura 6930000 con cero subsidio. No se infiere ninguna fecha de calendario. En la época 10, 50/1024 equivale a 0.048828125 BTC, mientras que la aritmética entera produce 0.04882812 BTC. Los parámetros de mainnet establecen el intervalo de halving de subsidio en 210,000 bloques. Un programa basado en bloques no establece una fecha de calendario futura exacta. La emisión nativa de subsidio de bloque difiere de una liberación contractual de una asignación existente. Esta revisión no identifica BTC envuelto de terceros ni asignaciones custodiales como emisión nativa. El cálculo original de Cryptosnif suma 210000 * floor(5000000000 / 2^k) satoshis para k=0..32, dando 2099999997690000 satoshis (20999999.97690000 BTC). Esto es una asignación teórica total de subsidio bajo las reglas de v29.0 asumiendo que cada subsidio permitido es reclamado, incluyendo génesis. Excluye tarifas. La fuente declara que la salida de génesis no puede ser gastada. Por lo tanto, esta asignación calculada no mide el suministro emitido, circulante o gastable actual; monedas perdidas y subsidios no reclamados requieren evidencia separada.
Incógnitas y Consecuencias
La concentración de propiedad actual, los poderes de control privilegiados, el uso medido independientemente, la integridad y eficacia de la remediación de incidentes y la liquidez localmente ejecutable permanecen sin verificar en este piloto. La cobertura de evidencia es insuficiente para una puntuación general. Un mecanismo documentado solo no puede establecer resiliencia actual o retornos esperados. Todos los criterios operacionales permanecen desconocidos. Las puntuaciones permanecen sin calificar.
Veredicto y Qué Lo Cambiaría
Promesa documentada. Verificación independiente pendiente. Observaciones de red reproducibles, mapas de control actuales, reglas de suministro documentadas y registros de incidentes independientes permitirían evaluar las verificaciones pendientes.
Hechos documentados
El documento primario enlazado está disponible y describe la promesa del proyecto. Las verificaciones independientes del funcionamiento siguen pendientes.
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]
Lo que queda por verificar
La concentración de titulares, los poderes de control, el uso actual, los incidentes y la liquidez local quedan por verificar.
Las pruebas disponibles son insuficientes para asignar una puntuación global. El mecanismo descrito requiere verificar su funcionamiento actual.
Cada control exige pruebas.
| Control | Peso | Resultado |
|---|---|---|
| Identidad exacta del activoEsencial | 3% | Verificación pendiente |
| Uso observable | 15% | Verificación pendiente |
| Papel económico del token | 10% | Verificación pendiente |
| Mecanismos de ofertaEsencial | 10% | Verificación pendiente |
| Concentración de titulares | 8% | Verificación pendiente |
| Captación de valor | 7% | Verificación pendiente |
| Poderes de controlEsencial | 10% | Verificación pendiente |
| Verificación de seguridad | 7% | Verificación pendiente |
| Proceso de decisión | 8% | Verificación pendiente |
| Responsabilidades | 7% | Verificación pendiente |
| Historial de incidentes | 6% | Verificación pendiente |
| Continuidad operativa | 4% | Verificación pendiente |
| Condiciones de ejecución | 5% | Verificación pendiente |
Controles específicos de la familia: Concentración de hashrate, reglas de consenso, independencia de nodos completos.
Consultar las pruebas
Fuentes de este análisis
Los títulos y resúmenes de las fuentes están en 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 la fuente primaria ↗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 la fuente primaria ↗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 la fuente primaria ↗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 la fuente primaria ↗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 la fuente primaria ↗[1] Bitcoin documentación primariaAfirmación del proyecto
The project publishes the mechanism described above.
Observación 2026-10-03 · Válido hasta 2026-11-02
Consultar la fuente primaria ↗Solo se distribuyen resúmenes originales. Los datos de mercado brutos bajo licencia permanecen privados.
Lo que cambiaría este veredicto
Observaciones reproducibles de la red, un mapa de los poderes y la verificación de las reglas de emisión permitirían completar las pruebas.
Ninguna corrección registrada para pilot-1. Las revisiones conservan sus fuentes y los veredictos anteriores.