Este es un editorial de opinión de Shinobi, un educador autodidacta en el espacio de Bitcoin y presentador de podcasts de Bitcoin orientado a la tecnología.
El 9 de octubre de 2022, Burak de Bitmatrix (una herramienta de intercambio construida en Liquid Network) creó y transmitió una transacción a la red principal de Bitcoin, gastando un UTXO con un Tapscript multisig con un umbral de 998 de 999. Esta transacción tenía 998 firmas individuales en el campo de testigo, y tenía un tamaño de casi 0,1 MB, y de manera un tanto hilarante, reutilizó exactamente la misma clave pública para cada uno de los 999 participantes en la multigrado. Esta transacción causó una interrupción masiva para Lightning Network al exponer un error en LND y btcd (un cliente alternativo para la red Bitcoin).
Todo el propósito de realizar esta transacción fue demostrar la escalabilidad mejorada de los scripts de firmas múltiples que ha habilitado Taproot. Incluso sin utilizar los protocolos MuSig basados en la firma Schnorr, Taproot puede habilitar conjuntos de participantes multisig mucho más grandes que las versiones anteriores de Bitcoin Script. Esta puede ser una discusión un poco matizada con respecto a la limitación de tamaño anterior de multisig si se sumerge en todas las formas posibles en que puede construir multisig con Bitcoin Script, por lo que, en aras de la simplicidad, simplemente discutiré los límites anteriores que se aplican. a construcciones multisig Pay-to-script-hash (P2SH) y Pay-to-witness-script-hash (P2WSH). Cuando se trata de la forma estándar de hacer un multisig P2SH, el límite de tamaño máximo de los participantes es solo 15, y en el caso del multisig P2WSH estándar, el tamaño máximo es 20. Estos límites se deben al tamaño que se le permite a un script. estar utilizando estas diferentes operaciones de secuencias de comandos y las limitaciones en la cantidad de operaciones de procesamiento que se pueden realizar en el ámbito de una única secuencia de comandos. La violación de cualquiera de estos límites invalida la transacción.
Con la implementación de Taproot, estos límites de tamaño de secuencia de comandos se eliminaron por completo, lo que significa que los únicos límites con el tamaño de secuencia de comandos de Taproot son el límite de tamaño de bloque en sí. Aquí es donde viene el problema con respecto a LND y btcd. Las reglas de consenso implementadas en btcd eliminaron correctamente estos límites con respecto al tamaño de la secuencia de comandos, pero el problema es que el código base para la comunicación entre pares también implementó controles en el tamaño de la secuencia de comandos para agregar una doble capa de defensa para los operadores de nodos. Los bloques y las transacciones pasarían por una especie de validación de consenso «preconsenso» antes incluso de llegar al código de consenso central que realiza la validación adecuada, la lógica es que la doble verificación agrega capas adicionales de defensa contra bloques o transacciones no válidos. Este código no se actualizó correctamente para eliminar los límites de tamaño de la secuencia de comandos y se siguieron aplicando los límites de secuencias de comandos anteriores para SegWit en las transacciones de Taproot. Entonces, si bien el código de consenso real en sí mismo habría validado correctamente esta transacción Taproot muy grande, el bloque que lo contiene nunca pasó de la validación de igual a igual a la lógica de validación de consenso real, lo que significa que todos los nodos btcd se estancaron en el bloque, incluido La transacción de Burak.
¿Por qué afectó esto a LND, dado que muchas personas ejecutan Bitcoin Core debajo de su instancia de LND? Es porque LND usa el mismo código que btcd para recibir y procesar bloques. Entonces, incluso si su nodo LND se estaba ejecutando sobre Bitcoin Core, lo que habría validado correctamente el bloque relevante y no se habría estancado, su instancia LND se habría negado a aceptar ese bloque y se habría estancado a pesar de que su nodo de la cadena principal continuó progresando correctamente.
Este error se corrigió muy rápidamente y, según mi conocimiento, no se explotó activamente de una manera que provocara algún daño, pero esto dejó abierto cada nodo LND en Lightning Network a un posible robo de fondos en los canales a menos que estuvieran usando una torre de vigilancia externa. Debido a que el nodo se detuvo en ese bloque, no tenía una vista en tiempo real de la cadena de bloques, y en el caso de que una contraparte del canal hubiera enviado un estado de canal antiguo a la cadena de bloques, no habría sido consciente de ello y no podría responder. con la transacción de penalización apropiada para asegurar los fondos del usuario. Este fue un error muy grave que puso en riesgo de robo un porcentaje masivo de bitcoin en Lightning Network, a menos que los usuarios parchearan y actualizaran manualmente sus nodos, o monitorearan personalmente sus canales para poder responder manualmente en caso de un cierre. con un estado obsoleto. Debo decir que la gran mayoría de los operadores de nodos no técnicos probablemente no habrían podido hacerlo.
Afortunadamente, este problema no se explotó ampliamente, pero si se hubiera descubierto en el código base antes de que la transacción de Burak se enviara a la cadena de bloques, los malos actores podrían haberlo explotado intencionalmente de una manera muy táctica. Una persona, o un grupo de personas, podría haber abierto muy fácilmente una gran cantidad de canales en la red y haber intercambiado todo el dinero de esos canales en la cadena a través de un intercambio submarino, dejando todos los fondos en el canal. por otro lado, y luego envió una gran transacción Taproot como lo hizo Burak, cerrando inmediatamente sus canales usando un estado obsoleto. Las víctimas ni siquiera serían conscientes de ello, e incluso si lo fueran, dada la relativamente baja competencia técnica de muchos operadores de nodos, es muy probable que la mayoría de las personas no hubieran podido responder a tiempo para corregir manualmente el problema con un transacción de penalización.
Este error destaca dos cuestiones importantes a tener en cuenta. En primer lugar, las múltiples implementaciones independientes de nodos de Bitcoin pueden ser muy peligrosas. Afortunadamente, casi nadie ejecuta btcd como un nodo para algo serio, por lo que el efecto que esto tuvo en la red base de Bitcoin fue algo que podría ignorarse por completo, a excepción de un puñado muy pequeño de personas cuyos nodos simplemente se estancaron. Si los mineros hubieran estado ejecutando btcd, esto podría haber resultado fácilmente en una división en cadena en la red de Bitcoin que habría eliminado a todos los operadores de btcd en una cadena minoritaria que habría requerido intervención manual para corregir. El segundo problema es que, en el caso de las segundas capas por encima de la red principal, las implementaciones de las comprobaciones de consenso deben realizarse con mucho cuidado. Este es un problema complicado, porque si bien cualquier nodo Lightning que se ejecute sobre un nodo completo de Bitcoin podría, en teoría, simplemente externalizar el 100 % de esta validación a ese nodo, no todos los nodos Lightning utilizan su propio nodo completo de confianza. Es poco probable que eso cambie: es muy probable que muchos usuarios continúen operando los nodos de esa manera, por lo que, hasta cierto punto, las verificaciones de algunas o todas las reglas de consenso de Bitcoin también deben admitirse en las implementaciones de Lightning.
En el futuro, espero que esta sea una llamada de atención sobre lo importante que es garantizar que las verificaciones de validación de consenso estén sincronizadas entre sí en todo el software en este espacio, ya que sin esa sincronicidad entre todo, en realidad no hay un único Bitcoin coherente. la red. Todos deberían estar muy contentos de que esto no resultó en una explotación masiva en toda la red, pero la gente debería ser consciente de cuán grave podría haber sido este problema si las cosas no se hubieran desarrollado de la manera en que lo hicieron.
Esta es una publicación invitada de Shinobi. Las opiniones expresadas son totalmente propias y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine.
