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

I don't recommend anyone scramble to move their funds to new wallets today. But we should take the risks to cryptography from AI-accelerated math seriously, and minimize our exposure to not just quantum-vulnerable cryptography, but also potentially AI-vulnerable cryptography. The core new area of risk from this viewpoint is, unfortunately, ML-DSA / FHE / lattices. (and it's also another reason, along with quantum, why ECDSA might fall even faster than expected, hence the "fresh address" recommendation) So far most people have been in the mode of thinking "elliptic curves broken, hashes safe, lattices safe". But there is a good chance that the concrete security of lattices will take serious hits from the next two years of AI math. The basic threat model is: factoring is something that naively takes 2^(n/2) time, but over decades smart people have found and optimized number field sieves, and degraded that to 2^O(n^(1/3)), which is why RSA keys and signatures need to be ~400 bytes (and not 64 bytes). What if there are skeletons in the closet like that, both for elliptic curves and lattices, that we are simply not smart enough to discover - but bots soon will be? This is a major part of the reason why for the past year ethereum's lean roadmap has been going in the "hash-only" direction: no lattices, no ML-DSA, no Falcon, no lattice-based commitments inside ZK proofs, etc. Signatures in lean ethereum are all hash-based, either WOTS or SPHINCS-. For signatures and proofs, we already know how to go hash-only. The bigger challenge is for *public-key encryption* - and this goes far beyond blockchains. Secure communication, anonymizing protocols, lots of things need public-key encryption. And unfortunately there are long-standing mathematical theorems showing why public-key encryption cannot be done with hashes alone. You have to have some kind of trapdoor object that has at least one form of usable "structure" - either group theory (incl. isogenies) or lattices or code-based or potentially in the future even more newfangled and spooky things (local mixing?). But for anything that has structure, you should assume that AI will make at least some progress in breaking that structure. Here, one reasonable inference is that if you want to make something plausibly long-term secure, multiply the key sizes by 10. To me that's a very plausible world and something not at all extreme to predict. If AI will bring us 50 years of math in 2 years, then that 50 years of math may very plausibly include a "naive factoring -> GNFS" level of improvement to our ability to break lattices. In that world, lattices will still exist, but they will have to be significantly bigger to guarantee the same level of safety. And at those new larger sizes, hash-based constructions will beat lattice-based constructions on concrete efficiency in every use case where hash-based constructions are possible at all. Theoretically, of course it's possible that hashes are broken too (eg. P = NP would imply that). But I think P = NP is very unlikely. And intuitively, it's much more likely that a mathematical object has exactly no exploitable structure (like hashes are intended to), than that a mathematical object has exactly ~3 forms of exploitable structure (for elliptic curves: associativity, Schoof, pairings) and not some secret fourth form of structure we have not yet discovered that greatly degrades its security (for elliptic curves, ECDLP and pairing security). Similar for LWE, SVP, RLWE and the zoo of lattice problems. For this reason, we do not yet see any reason to worry and start padding the byte size of hashes (if we start to worry more, we would pad the round count first before doing anything to the byte size). Concrete TLDR, my own personal views: * Hash-based > lattice-based, in those situations where hash-based is possible at all * For anything lattice-based, be much more paranoid on param sizes. Remember that blockchains are only a small portion of the cryptography story; this point goes far beyond blockchains and applies to eg. access to websites, secure messaging, Tor / VPNs ... * For privacy protocols, strongly favor NOT putting encrypted notes onchain. Instead, send them offchain through some third-party mechanism. * If it's not difficult for you, keeping your funds in addresses which have not yet been used to make a transaction is a good idea. If it's easy for you, do it. **But be careful about migrations; I personally have lost more money in botched migrations than I have lost in all hacks combined**. * For multisig wallets, doing confirmations offchain is better than onchain, because this way the signatures of signer wallets do not get exposed to the public, so if ECDSA falls to AI much faster than expected, at least the multisig "gracefully degrades" to a 1-of-1 where the 1 is whoever was gathering the signatures - a much better place to be than "anyone can take the money" firefly.social/post/x/210783…

La razón científica detrás de perdonar 70 veces 7. Desde los tiempos de Jesús hemos llevado este consejo como algo superficial. Hoy la ciencia nos indica la verdad detrás de perdonar 70 veces 7. Las palabras de Jesús nunca pasarán. Una prueba más de Dios está entre nosotros y su amor nos quiere llevar a ser y estar mejor. Video de nexo_pj

Hoy en @ETHSpain_ hablamos con @chematomic sobre @tutellus 🛡️