Teclaro

Vitalik ha publicado sus razonamientos, preocupaciones y pensamientos así como también lo ha hecho @CriptoATH, debido a la publicación de los últimos días de @OpenAI sobre sus consideraciones de la IA con las matemáticas y al matemático @drakefjustin sobre el peligro para Bitcoin. Este es una tema complejo que incluso para los que nos dedicamos a esto, hay detalles que se nos escapan. La IA y la potencia bruta de las GPUs crece cada día, lo que supone estar totalmente actualizado a cada instante, lo cual es humanamente imposible, y más cuando no estás al 100% en cripto. Dicho esto, hay que matizar varias cosas: El planteamiento de @drakefjustin merece atención, sí, pero hay un concepto criptográfico básico y fundamental que tenemos que tener claro: Romper "ECDSA" NO significa romper las 24 palabras BIP39. Lo que es preocupante es encontrar un algoritmo clásico eficiente para resolver ECDLP en secp256k1, es decir, recuperar una clave privada a partir de su clave pública. Para los más novatos: lo matemáticamente posible y fácil es ir de una privada (parte sensible) a una pública (parte no sensible). No tiene sentido poder hacer lo contrario porque si no, las criptomonedas no tendrán sentido, todo el mundo podría robar cualquier fondo a cualquier persona cuando quisiera. Hoy en día el mejor ataque clásico general conocido tiene una complejidad aproximada de 2¹²⁸ operaciones, y que yo sepa, no se conoce ningún avance (al menos público) que permita reducirla hasta recuperar claves privadas en una semana utilizando GPUs. Además, las direcciones P2WPKH (bc1q...) ocultan la clave pública mediante HASH160 (mientras no se haya revelado por otra vía). En cambio, como bien dice @CriptoATH con su resumen, las direcciones Taproot (bc1p...) SÍ exponen su clave pública desde el principio. Eso sí, no utilizan ECDSA, sino Schnorr, así que un ataque contra ECDSA no comprometería a las bc1p, pero uno contra ECDLP sí. Por dejarlo claro antes de continuar y recuperar a quien se haya perdido aquí, para volver a engancharlo y continúe conmigo: - ECDLP es un problema matemático. - ECDSA es un algoritmo criptográfico de firma digital donde su seguridad depende prácticamente, de resolver ese problema. Por eso se habla siempre de Bitcoin como un problema a resolver. ------------------------------------- 1) ECDLP = Elliptic Curve Discrete Logarithm Problem Q = d · G Q: clave pública. d: clave privada (nº secreto). G: punto conocido de la curva secp256k1. El problema en cuestión es si conociendo Q (clave pública) y G (punto de la curva) se puede calcular d (clave privada), que es lo que tienes guardado en tu cajón. 2) ECDSA = Elliptic Curve Digital Signature Algorithm. Es el algoritmo que permite demostrar que tiene una clave privada sin revelarla. Por ejemplo, cuando gastas BTC desde una dirección P2WPKH (bc1q...), utilizas ECDSA para firmar la transacción. ------------------------ Aclarado esto, debes tener en cuenta que aunque los avances recientes de la IA en matemáticas son impresionantes, no significa que haya aún evidencias sólidas de una ruptura a corto ni medio plazo de al curva secp256k1. Es más, esto NADA tiene que ver con las 12 o 24 palabras que tienes en un cajón. Es más difícil obtener por fuerza bruta tus palabras que hacer lo que quieren lograr con la curva. Para que te quede claro, las 12/24 palabras que son la frase semilla, es la puerta de tu casa acorazada con 20 cerrojos y 10 trampas justo en la entrada si logran acceder. En cambio, el ECDSA y ECDLP son las ventanas cerradas. ¿Por qué alguien querría entrar por la puerta principal si es prácticamente imposible si la ventana es más vulnerable? La finalidad es entrar a robar a casa, no hacerlo por un determinado sitio. No es una cuestión de ego, es una cuestión de inteligencia y astucia. Entonces, volviendo a la parte central de la explicación y por dejarlo claro, 🤔 ¿Qué habría que romper exactamente para robar Bitcoin? Como ya sabes, Bitcoin utiliza criptografía de curva elíptica, concretamente la curva secp256k1 que he comentado antes, y la relación es fácil de explicar porque también la he definido: Q = d·G Es sencillo calcular Q conociendo d, pero extremadamente difícil obtener d conociendo únicamente Q. Por eso se le llama ECDLP, el problema del logaritmo discreto en curvas elípticas. Y repito, ECDSA es un algoritmo de FIRMA DIGITAL, mientras que ECDLP es el PROBLEMA MATEMÁTICO donde su dificultad sostiene gran parte de su seguridad. ¿Entonces por qué no se puede resolver con miles o decenas de miles de GPUs al mismo tiempo? Esto ya es algo que muchas veces he explicado, para una curva como la secp256k1, donde un orden de aproximadamente 2²⁵⁶, el mejor ataque clásico general CONOCIDO y PÚBLICO es el del grupo "Pollard rho". (BIP39 de 24 palabras) ≈ 2²⁵⁶ ≈ 1,16 × 10⁷⁷ combinaciones válidas. (ECDLP) ≈ 2¹²⁸ ≈ 3,4 × 10³⁸ operaciones. Son dos problemas DIFERENTES. En el 1º se tiene una clave pública. En el 2º se intenta adivinar una frase semilla. Esto de normal asusta, porque claro, te das cuenta que una clave privada de 256 bits sobre secp256k1 proporciona aproximadamente 128 bits de seguridad clásica frente a los mejores ataques generales conocidos, no 256. Sabido esto, un super clúster de GPUs puede paralelizar el ataque de Pollard rho, sí, pero no elimina la enorme complejidad matemática del problema. Entonces para recuperar una clave privada en una semana con hardware convencional (los clústers de GPUs que estamos teniendo en cuenta) necesitaríamos un avance extraordinario: Un algoritmo radicalmente MUCHO MÁS eficiente, no simplemente GPUs más potentes. Entonces, aquí es donde entra en juego @drakefjustin , donde plantea que la IA es posible que encuentre ese algoritmo MUCHO MÁS eficiente. Y de ahí surge el miedo de @VitalikButerin y @CriptoATH (Espero que tengas todo claro hasta aquí, no está siendo fácil plasmar esto incluso con la ayuda de la IA para los cálculos y datos más precisos, menudo trabajazo joder, y gratis). No existe una demostración matemática general de que ECDLP sea imposible de resolver eficientemente mediante un algoritmo clásico, por tanto, hay como dos afirmaciones muy distintas: 1) Afirmación razonable Una IA mucho más potente e inteligente podría descubrir nuevas técnicas matemáticas y cambiar nuestro conocimiento y sesgo sobre la seguridad de ECDLP. 2) Afirmación para "fumaos" y que no está demostrada Dado el progreso y avance reciente de la IA en cuestiones matemático-físicas, secp256k1 probablemente puedes er vulnerable mediante GPUs en cuestión de meses o 1 año. 🤔 ¿Qué relación tienen los descubrimientos matemáticos de OpenAI con ECDSA? Aquí hay que distinguir varios puntos que el mensaje de Drake utiliza para dar a conocer su preocupación. Entre ellos están las fechas marcadas y reconocidas como: - 20 de mayo de 2026: conjetura de Erdős - 5 de octubre de 2026: conjetura 3SUM - 6 de octubre de 2026: publicación matemática de OpenAI. (Buscad información de éstas, ya que si lo hago yo será un copy-paste literal de la IA y no tendría gracia el tweet por el relleno evidente). Todo esto concluyo, al menos como yo pienso y lo que percibo, que Drake está proponiendo PREPARARSE ante un riesgo de consecuencias muuuy grandes, no presentando una prueba de que ese riesgo sea inminente. Algo así como un hipocondríaco matemático, pero no tan hipocondríaco como pudiera parecer hace 5 años, ya que la IA está creciendo demasiado rápido. Para los más hipocondríacos del ecosistema que no pueden ni agacharse porque tienen las piernas totalmente encogidas aún: ¿Las direcciones que ocultan la clave pública están a salvo? ¡El gran dilema y preocupación de todos mis ingenieros lectores! jajaja De momento sí, están mejor protegidas frente a un ataque que necesite conocer la clave pública, pero NO son invulnerables. (¡¡¡OJO!!! ... Las direcciones de btc SÍ son públicas, lo que puede permanecer oculto es la clave pública criptográfica asociada a ellas.) Para entenderlo, hay que conocer cómo funciona una dirección P2WPKH (bc1q). Sí, lo más seguro es que tú, que me estás leyendo, tengas todo tu capital en una dirección bc1q: Cómo se protege una clave pública mediante HASH160: d: Clave privada ------------------------------- ✅ Solo la conoce el propietario Q: Clave pública ------------------------------- ✅Se deriva mediante secp256k1 SHA256 ---) RIPEMD160 --------------------------------- HASH160(Q): resumen de 160 bits RESULTADO: Dirección bc1q… + Publica el hash, no directamente la clave pública Es decir, para que te quede claro: Una dirección P2WPKH se construye a partir de: h = HASH160(SHA256(Q)) Y aunque mañana descubramos un algoritmo capaz de resolver Q=dG, es decir, ECDLP, en 2 segundos, necesitaríamos primero conocer Q. Si únicamente disponemos de h, el algoritmo que rompe ECDLP no basta. Tendríamos que atacar también la función hash, obtener la clave pública por otra vía o encontrar otra clave que produzca un hash aceptado por esa dirección. Bajo los supuestos criptográficos actuales, buscar HASH160 requiere del orden de 2^160 intentos. ✅ Por tanto, ocultar la clave pública crea una segunda barrera. En resumen: + P2PK (Bitcoin antiguo) SÍ expone la clave pública y SÍ es vulenrable ante ECDLP. + P2WPKH (bc1q...) SÍ expone HASH160 pero está protegida mientras no se conozca su clave pública ante ECDLP. + Taproot (bc1p...) SÍ expone la clave pública y SÍ es vulenrable ante ECDLP. Eso sí, recuerda que estas direcciones utilizan firmas Schnorr. Nada que rompa ECDSA afectaría a éstas. Vamos, que ambos sistemas dependen de la dificultad de recuperar una clave privada a partir de una pública, aunque sus ecuaciones de firma sean distintas. Pero aun así, taproot me sigue sin gustar, porque recuerda que desde un primer momento la dirección bc1p expone su clave pública (Q), mientras que la SegWit de bc1q se conoce la "h", no la Q directamente, siendo h = HASH160(SHA256(Q)) como ya sabemos. O sea, ocultar la Q dentro de la h, es objetivamente algo mejor. También hay que distinguir P2WPKH (comentada anteriormente) de P2WSH: ambas empiezan por bc1q, pero la segunda almacena un hash de un script, no directamente el hash de una clave pública. Esto te puede hacer pensar que las nuevas bc1p fueron un error, y no tiene por qué, la diferencia es que Taproot priorizó otras propiedades y no la ocultación de la clave pública frente a una posible ruptura de ECDLP. ¿Puede que subestimara a la IA en una época pre-boom IA? Puede. Como conclusión de todo esto: Si el riesgo que discutimos es el planteado por @drakefjustin , el recuperar claves privadas rápidamente a partir de claves públicas, una dirección P2WPKH que NUNCA ha revelado su clave pública (ni por filtración de su xpub), SÍ tiene una ventaja defensiva clara frente a Taproot. Pero si el ataque descubierto afectase sólo a ECDSA y no a ECDLP, la comparación podría invertirse, lógicamente. Y con eso tienes que quedarte: romper "ECDSA" NO es necesariamente romper Schnorr (bc1p), pero romper ECDLP en secp256k1 (Q = d·G) comprometería a ambos. Buenas prácticas. No entres en pánico. Preocúpate sólo por lo que tienes en tu mano. Haz caso a los profesionales y huye de los gurús. Pd. Esta entrada me ha costado mucho esfuerzo mental, temporal, físico y años de formación. Pd2. He usado la IA para los datos precisos más difíciles (exponentes) y alguna explicación simplificada y técnica de algún párrafo que no me quedaba bien. Pd3. Si te ha gustado este tweet, es algo que tendrá la guía v3 de seguridad o privacidad, tengo que valorarlo aún, pero éste será el nivel, para que te hagas una idea. Y recogeré esto para ponerlo allí seguramente, con dibujos, animaciones y multimedia incluso para que lo veas muchíiiiisimo más claro. IngenieroSeed