-
Zcash aplicó un fork de emergencia: los nodos que no actualizaron a tiempo vieron la red paralizada.
-
Los pagos silenciosos son una propuesta que podría mejorar la privacidad en Bitcoin sin un fork.
Tras el fallo detectado en Zcash en su pool Orchard, el sistema más utilizado para las transacciones blindadas de esa red, el desarrollador bitcoiner Peter Todd expresó que «añadir privacidad al estilo de Zcash a Bitcoin en la capa de consenso es una mala idea».
La publicación de Todd, compartida en X este 3 de junio, abrió el debate sobre Bitcoin, su diseño y los posibles vectores de fallos. En ese sentido, un usuario le recordó al desarrollador que Bitcoin tampoco es inmune a los errores, ya que en 2010, la red tuvo que revertir varios bloques tras un bug que generó 184 mil millones de BTC inválidos, y que en 2013 Bitcoin se dividió temporalmente en dos cadenas por incompatibilidades entre versiones del software Bitcoin Core.
Todd respondió:
Exactamente mi punto. En Bitcoin, revertir la cadena fue viable porque solo una fracción pequeña de las monedas estaba afectada y el exploit era trivial de detectar. El 30% del suministro de Zcash está blindado (en pool Orchard principalmente). Que ese suministro fuera destruido sería un desastre y borraría completamente los fondos de un alto porcentaje de todos los usuarios de Zcash. Yo personalmente tengo un poco de Zcash, y todo está blindado.
Peter Todd, desarrollador de Bitcoin.
El argumento de Todd apunta a que, en Bitcoin, una falla en el protocolo base afecta al suministro público y auditable; en Zcash, una falla en el circuito criptográfico que sostiene la privacidad puede afectar fondos que nadie, ni los propios desarrolladores, podrían cuantificar con precisión en tiempo real, según Todd.
Seguidamente, otro usuario cuestionó si el razonamiento de Todd no frenaría cualquier innovación en Bitcoin: «Es como decir que agregar seguridad cuántica en la capa de consenso es mala idea porque podría tener bugs».
Todd rechazó la equiparación:
Los distintos tipos de criptografía tienen distintos niveles de riesgo. La criptografía al estilo Zcash tiene un nivel de riesgo muy alto, mucho más que la criptografía de Bitcoin. Eso se refleja en que Zcash ha tenido problemas mucho más serios que Bitcoin.
Peter Todd, desarrollador de Bitcoin.
La distinción que traza Todd no es entre innovar o no innovar, sino entre asumir complejidad criptográfica de alto riesgo en el núcleo de un protocolo de reserva de valor y mantener ese núcleo deliberadamente simple, como el diseño de Bitcoin lo establece.
El diseño de Bitcoin y la superficie de ataque que no tiene
Bitcoin no incorpora en su protocolo base el tipo de criptografía que usa Zcash para blindar sus transacciones mediante el pool Orchard. Para esto, Zcash emplea Halo 2, una variante del esquema criptográfico zk-SNARKs, pruebas matemáticas de conocimiento cero (ZK) que permiten validar una operación sin revelar remitente, destinatario ni monto.
Esa complejidad, incorporada en la capa de consenso de Zcash, es precisamente lo que permitió la superficie de ataque que el incidente del 2 de junio pasado expuso. Si bien la vulnerabilidad no condujo a pérdida de fondos, la corrección requirió una bifurcación dura (hard fork) del protocolo que obligó a nodos, wallets y exploradores de bloques a actualizarse de forma coordinada. Los que no lo hicieron a tiempo quedaron desincronizados y mostraron la red paralizada durante horas.
Bitcoin no es infalible, pero la complejidad de Orchard no existe por decisión de diseño. Satoshi construyó un protocolo deliberadamente acotado para cumplir con su propuesta (ser un sistema de dinero electrónico descentralizado), sin capas adicionales.
Esa austeridad no es una limitación técnica sino una filosofía de seguridad. A menor programabilidad en el núcleo del protocolo, menor superficie de ataque. Bitcoin no puede tener una vulnerabilidad en un circuito de pruebas de conocimiento cero porque simplemente no tiene circuitos de pruebas de conocimiento cero.
La privacidad en Bitcoin por otro camino
El debate sobre privacidad en Bitcoin no gira, sin embargo, en torno a si agregarla o no, sino a dónde y cómo. En ese contexto, los pagos silenciosos (o Silent Payments) son una propuesta concreta actualmente activa. Se trata de un sistema que permite recibir bitcoin (BTC) sin exponer el historial de cobros, generando automáticamente una dirección distinta para cada transacción a partir de un único código fijo que el receptor comparte públicamente.
El mecanismo de pagos silenciosos opera en la capa de aplicación, por lo que no modifica el protocolo base, y elimina la reutilización de direcciones, una práctica que hoy expone el historial completo de una cuenta a cualquiera que conozca la dirección.
Sin embargo, la adopción de los pagos silenciosos es todavía acotada. Sparrow Wallet los incorporó en su versión v2.5.0, lanzada el 21 de mayo, como lo explicó CriptoNoticias; Cake Wallet también los soporta; BlueWallet los admite únicamente para enviar, no para recibir.
Por lo tanto, el camino hacia la privacidad en Bitcoin, a diferencia del de Zcash, no pasa por reescribir las reglas del protocolo, pero en contrapartida tampoco ha llegado todavía al usuario promedio.
