La inmutabilidad de Bitcoin es un mito compartido. dennis weidner
La inmutabilidad de Bitcoin es un mito compartido: una breve historia de las reversiones de transacciones y las reversiones de cadenas.
Publicado el 10 de octubre de 2021 3:41 pm
Articulo original:
Traducción de Google:
La inmutabilidad de Bitcoin o la falta de ella es su secreto mejor guardado . Los defensores del dinero sólido afirman que el protocolo criptográfico líder por capitalización de mercado también es el único inmutable, basado en una serie de narraciones y el boca a boca, en lugar de cualquier evidencia. Sin embargo, ha habido al menos dos instancias en la historia del protocolo Bitcoin, donde la inmutabilidad del protocolo se rompió de manera centralizada.
La primera instancia de ruptura de la inmutabilidad de Bitcoin fue el 15 de agosto de 2010, aproximadamente un año y medio después del lanzamiento, un evento conocido técnicamente como CVE-2010-5139: Desbordamiento de valor de Bitcoin o informalmente como el error de Bitcoin 184 mil millones. Se rompió por segunda vez el 11 de marzo de 2013, un evento registrado como CVE-2013-3220 : Incidente de migración de BerkeleyDB a LevelDB . Veamos algunos detalles.
Primera infracción de inmutabilidad de Bitcoin CVE-2010-5139 el 15 de agosto de 2010
Los 184 mil millones de Bitcoines erróneos o CVE-2010-5139: Incidente de desbordamiento de valor de Bitcoin ocurrió el 15 de agosto de 2010. Como resultado, la cadena de bloques de Bitcoin experimentó un tiempo de inactividad de 8 horas : 27 minutos. El desarrollador central de Bitcoin descubrió que a la altura del bloque 74 638 alguien había explotado un error de desbordamiento de valor en el código y creó 184 B (o 184 000 000 000) BTC, eso está muy por encima del límite habitual de 21 millones (o 21 000 000) BTC.
Primera publicación que describe el error Bitcoin 184B – Bitcointalk
Un atacante desconocido había generado estas cantidades increíblemente altas de Bitcoins, de la nada y distribuyó la cantidad en varias direcciones. El desarrollador principal de Bitcoin, Jeff Garzik, descubrió el error de desbordamiento de valor, que resulta del mal funcionamiento de la lógica de verificación del código y el procesamiento inadecuado de grandes sumas de salida.
Descripción del error Bitcoin 184B – Bitcointalk
Pasó desapercibido durante casi dos horas en ese momento, sin embargo, el creador anónimo de Bitcoin, Satoshi Nakamoto, lanzó una nueva versión de cliente parcheada (0.3.10) dentro de las cinco horas para solucionar los problemas. Posteriormente, los participantes de la red realizaron una bifurcación suave y rechazaron las transacciones anormales que generaron una cantidad ridículamente alta de Bitcoins.
Satoshi actualizando a los participantes de la red en la solución – Bitcointalk
La bifurcación resultante y el parche de error representaron 51 bloques previamente validados, no válidos. Por lo tanto, las otras transacciones válidas contenidas en esos errores, además de las maliciosas que producen los 184 mil millones de Bitcoins, se revirtieron y la cadena se revirtió de manera efectiva a través de la reorganización de bloques. No hay una lista de las transacciones revertidas en esos bloques revertidos disponibles.
Este incidente mostró la coordinación entre la comunidad, los mineros y los desarrolladores principales de Bitcoin , que tuvieron que confiar en la toma de decisiones centralizada para solucionar el problema. Esta es la primera instancia en la que se violó la inmutabilidad de Bitcoin y el proyecto tenía solo 1,5 años en ese momento. Puede leer el fascinante hilo de Bitcointalk sobre el tema aquí para echar un vistazo a la actividad que estaba ocurriendo en ese entonces. Cofundador de Ethereum Vitalik Buterín luego describió el error como:
En agosto de 2010, una transacción en el bloque 74638 contenía dos salidas que sumaban más de 184 mil millones, poco más de 2^64 satoshis . El resultado fue un error de desbordamiento de enteros, el equivalente digital de un odómetro mecánico que vuelve a cero después de que el automóvil conduce 999,999 kilómetros.
Segunda infracción de inmutabilidad de Bitcoin CVE-2013-3220 el 11 de marzo de 2013
La segunda violación de inmutabilidad de Bitcoin o CVE-2013-3220: error de migración de BerkeleyDB a LevelDB ocurrió el 11 de marzo de 2013. Esta vez, la cadena de bloques de Bitcoin experimentó un tiempo de inactividad de 06 horas : 20 minutos. En el fatídico día, los mineros que ejecutaban el cliente v0.8.0 produjeron grandes bloques, que no eran compatibles con los mineros que ejecutaban la versión anterior v0.7.0 en la altura 225,430. Esto provocó una bifurcación dura ya que se rompió el consenso de la cadena.
Esta bifurcación dura involuntaria fue causada por la migración de la base de datos de Berkeley a la base de datos de nivel y las versiones del cliente no aplicaron suficientes límites de bloqueo o manejaron incorrectamente las transacciones de mem-pool. Por lo tanto, las cadenas divergieron unas de otras. Un participante de la red no malicioso también pudo ejecutar un doble gasto exitoso , que sigue siendo el único caso en la historia de Bitcoin, donde un doble gasto ha sido exitoso.
Usuario macbook -cuenta aérea de doble gasto exitoso – Bitcointalk
Sin embargo, la detección y la implementación de arreglos fueron más rápidas que antes. Los participantes tardaron 1 hora en descubrir la bifurcación y el problema se resolvió en unas pocas horas, gracias a la toma de decisiones centralizada y la colusión de los desarrolladores principales con los mineros. El desarrollador central de Bitcoin señaló lo siguiente en su informe post mortem del incidente .
Se extrajo y transmitió un bloque que tenía una cantidad mayor de entradas de transacciones totales que las vistas anteriormente. Los nodos de Bitcoin 0.8 pudieron manejar esto, pero algunos nodos de Bitcoin anteriores a 0.8 lo rechazaron, lo que provocó una bifurcación inesperada de la cadena de bloques. La cadena anterior a 0.8 incompatible (de aquí en adelante, las cadenas 0.8 ) en ese momento tenía alrededor del 60 % del poder de hash de minería, lo que garantizaba que la división no se resolviera automáticamente (como habría ocurrido si la cadena anterior a 0.8 superaba a las cadenas 0.8). en trabajo total, obligando a 0,8 nodos a reorganizarse a la cadena anterior a 0,8).
Gavin Andresen Descripción de lo que salió bien – Informe Post Martem
Para restaurar una cadena canónica lo antes posible, BTCGuild y Slush degradaron sus nodos de Bitcoin 0.8 a 0.7 para que sus grupos también rechazaran el bloque más grande. Esto colocó el poder de hash mayoritario en la cadena sin el bloque más grande, lo que eventualmente provocó que los 0.8 nodos se reorganizaran en la cadena anterior a 0.8. Durante este tiempo hubo al menos un gran gasto doble. Sin embargo, fue hecho por alguien que experimentó para ver si era posible y no tenía la intención de ser malicioso.
Bitcointalk
La segunda violación de la inmutabilidad de Bitcoin vio 24 bloques previamente válidos, invalidados. Por lo tanto, las transacciones se revirtieron una vez más y la cadena se revirtió de manera centralizada. Su rectificación solo fue posible porque los grandes operadores de grupos de minería (Slush, BTC Guild, etc.) que ejecutan el cliente v0.8.0 fueron persuadidos con éxito por los desarrolladores centrales de Bitcoin para degradar su software a v0.7.0 , contribuir con su poder de hash y volver a la versión anterior. cadena previamente válida.
El desbordamiento hizo que el software pensara que la transacción contenía solo una pequeña cantidad de BTC, mientras que en realidad las salidas juntas tenían miles de veces más que los 21 millones que deberían existir. Se tuvo que publicar una nueva versión del software de Bitcoin, la cadena de bloques se bifurcó y una cadena nueva y válida superó a la anterior en el bloque 74691, 53 bloques después de la bifurcación original. Esta vez, solo tomó 24 bloques, y ni siquiera fue una amenaza crítica para la vida del sistema: si los desarrolladores no hubieran hecho nada, Bitcoin habría continuado de todos modos, solo causando inconvenientes a los usuarios de bitcoind y BitcoinQt que estaban en 0.7 y habría tenido que actualizar.
Vitalik Buterin sobre el error de migración de BerkeleyDB a LevelDB – Bitcoin Magazine 13 de marzo de 2013
Por lo tanto, el poder de hash mayoritario se explotó para violar la inmutabilidad de Bitcoin al decidir centralmente qué cadena era válida. No hubo ninguna razón particular para seleccionar la cadena v0.8.0 sobre v0.7.0 y parece ser una decisión arbitraria de los desarrolladores principales de Bitcoin . También fue posible porque el poder de hash no se distribuyó por igual y los grandes operadores de grupos de minería pudieron inclinar la balanza a favor de v0.7.0 a pedido de los desarrolladores principales , ya que controlaban más del 70 % de la tasa de hash de minería de Bitcoin.
Bitcoin Core Dev Pieter Wuille iniciando los Bitcoins «¿Pueden dejar de operar?» Momento – Bitcointalk
Más tarde, el desarrollador central de Bitcoin, Pieter Wuille, inició el Bitcoin’s ¿Pueden ustedes dejar de operar? momento pidiendo a los mineros que no extraigan en la cadena v0.8.0. Se informó que en ese momento, se perdieron 25 BTC o $ 26,000 en recompensas mineras y, por supuesto, se revirtió el tx de doble gasto. Sin embargo, la mayoría de las transacciones afectadas se incluyeron más tarde en la nueva cadena. Este incidente mostró que la inmutabilidad de Bitcoin depende en gran medida de los factores humanos o del consenso social y no se parece en nada a los límites fundamentales, como se afirma ampliamente.
Historia olvidada
La inmutabilidad de Bitcoin nunca ha sido objeto de mucha discusión y siempre se ha dado por sentada. Es sorprendente que, a pesar de los registros claros en la cadena y la historia establecida, la comunidad todavía opta por informar engañosamente que el protocolo es inmutable. Es comprensible ver que las dos instancias en la historia de Bitcoin son todo menos eso. Ha habido otros casos, en los que se encontraron varios errores en el código, pero nunca se explotaron en la red principal , después de que los desarrolladores principales los corrigieran silenciosamente sin mucha divulgación previa.
Esta es una referencia a CVE-2018-17144 : Denegación de servicio fuera de memoria del inventario de Bitcoin, donde los mineros podrían haber explotado una vulnerabilidad de Denegación de servicio (DoS) y CVE-2018-17145: Vulnerabilidad de error de inflación: otro error lo que podría haber causado que el suministro de Bitcoin se inflara más allá del límite de 21M. Ambos errores tenían el potencial de causar retrocesos, pero se solucionaron mucho antes de causar problemas. El protocolo no ha encontrado ningún otro problema importante desde entonces, pero la inmutabilidad de Bitcoin sigue siendo un mito compartido hasta la fecha.
Bitcoin claramente no es en absoluto la democracia directa que imaginaron muchos de sus primeros adeptos y, algunos se preocupan, si un núcleo centralizado de la comunidad de Bitcoin es lo suficientemente poderoso como para emprender con éxito estas medidas de emergencia para corregir la cadena de bloques de Bitcoin, ¿qué otra cosa es? lo suficientemente potente como para hacerlo? ¿Forzar gastos dobles para revertir robos millonarios? ¿Bloquear o incluso redirigir las transacciones que se sabe que se originan en Silk Road? ¿Quizás incluso modificar el límite sagrado de suministro de 21 millones de divisas de Bitcoin?
Vitalik Buterin Comments On The Core Dev / Miner Collusion – Bitcoin Magazine Mar 13, 2013
Nota (Ramon Quesada)
a la primera reversión del 15 de agosto del 2010
Este incidente mostró la coordinación entre la comunidad, los mineros y los desarrolladores principales de Bitcoin , que tuvieron que confiar en la toma de decisiones centralizada para solucionar el problema. Esta es la primera instancia en la que se violó la inmutabilidad de Bitcoin y el proyecto tenía solo 1,5 años en ese momento.
En realidad este incidente no es que mostro la coordinación entre los mineros y desarrolladores, como se plantea en el articulo, sino la imposición de Satoshi como líder único del desarrollo del proyecto, para solucionar de forma centralizada este incidente técnico, y demostrando como solucionar lo sucedido en SU proyecto, en un momento muy temprano donde la mayoría de mineros no tenían a penas noción de lo que hacían, el principal minero era Satoshi con su inversión en hardware y software, no fue para nada una solución consensuada, ni votada. y a pesar de la reversión de la cadena durante las horas que duró, el resto de la información si se ha quedado de forma inmutable.
Conclusión; La cadena de bloques de Bitcoin SI ha sido revertida, pero toda la información de las transacciones, que no coinciden con estos dos acontecimientos puntuales, de un total de 14h 47 siguen siendo inmutables. (15 de agosto de 2010 8 horas : 27 minutos y 11 de marzo de 2013 6 horas : 20 minutos.)
La inmutabilidad de Bitcoin es un mito compartido: una breve historia de las reversiones de transacciones y las reversiones de cadenas.
Publicado el 10 de octubre de 2021 3:41 pm
Articulo original:
Traducción de Google:
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!