Bitcoin ingresó en la ventana final normal de 2.016 bloques del BIP-110 el 25 de julio con el apoyo de los mineros al 0,89%. La propuesta requiere 1.109 bloques, o el 55%, para el bloqueo normal, y su fase obligatoria de bit de versión puede comenzar en agosto si el apoyo permanece por debajo de ese umbral.
Jameson Lopp ha enmarcado la limpieza de Consensus, los convenios y la preparación cuántica como la próxima agenda de Bitcoin. También ocupa dos lados de esa transición: Lopp se opone a BIP-110 y coescribió BIP-361, un plan preliminar para la migración post-cuántica.
BIP-110 ofrece a esos debates una referencia de gobernanza en vivo porque los desarrolladores, mineros, operadores de nodos, exchanges, custodios y titulares aportan cada uno una forma diferente de consentimiento. Las próximas propuestas vinculan esa prueba de coordinación a la validación de bloques, la custodia resistente a robos y el estado de propiedad de las monedas vulnerables.
Los errores conocidos ingresan a la cola de actualización
Consensus Cleanup combina cuatro reparaciones del protocolo en BIP-54. Antoine Poinsot y Matt Corallo completaron la especificación en mayo, y Bitcoin Inquisition ha ejecutado las reglas en su signet experimental desde febrero.
El paquete cubre el ataque de distorsión temporal, los costos extremos de validación de bloques, una ambigüedad del árbol Merkle que involucra transacciones de 64 bytes y controles futuros de transacciones duplicadas.
La falla de distorsión temporal permite a la potencia de hash mayoritaria dirigir la dificultad de minería hacia su mínimo en 38 días, adelantando la subvención mediante una producción más rápida de bloques y alterando los incentivos de los mineros.
Una debilidad separada es que bloques especialmente diseñados pueden tardar varios minutos en hardware de gama alta y horas en máquinas más débiles.
BIP-54 limita las operaciones de firma por transacción, reduciendo la carga máxima de validación en un factor de 40. También invalida una forma de transacción de 64 bytes que los mineros han tratado como no estándar desde 2019 y que Bitcoin registró por última vez en la cadena en 2016.
Debido a que esas reparaciones fortalecen la validez del consenso, la revisión se centra en los casos límite de la especificación, el código de referencia, los vectores de prueba y meses de uso en Signet. Un retraso prolongado dejaría cuatro debilidades documentadas en el protocolo y aumentaría la probabilidad de que un ataque futuro comprima el calendario de revisión.
Consensus Cleanup realiza una prueba de mantenimiento al bitcoin con fallas definidas y soluciones medibles, permitiendo la aprobación para demostrar que la red puede procesar trabajo de protocolo defensivo mediante revisión ordinaria.
Un retraso prolongado convertiría las debilidades conocidas en deuda técnica acumulada.
| Reparación de BIP-54 | Riesgo abordado | Impacto práctico | Pregunta prospectiva |
|---|---|---|---|
| Corrección de Timewarp | La mayoría de la potencia de hash puede empujar la dificultad hacia el mínimo | Podría acelerar la producción de bloques y adelantar la subvención | ¿Puede bitcoin cerrar las fallas de incentivo conocidas antes de que se vuelvan explotables? |
| Límites de costo de validación | Los bloques elaborados pueden tardar minutos u horas en validarse | Debilita los nodos con recursos limitados y aumenta el riesgo de propagación | ¿La red prioriza la resiliencia en el peor de los casos antes de que aumente la presión del ataque? |
| Regla de transacción de 64 bytes | Ambigüedad del árbol de Merkle debido al formato de transacción especial | Elimina una clase de ambigüedad histórica de consenso | ¿Es más fácil realizar una limpieza preventiva antes de que el caso límite se convierta en un arma? |
| Limpieza de transacciones duplicadas | Preocupaciones futuras sobre la validación tipo BIP-0030 | Reduce la gestión de excepciones heredadas | ¿Puede el bitcoin simplificar el consenso sin desencadenar una reacción de coordinación negativa? |
Los convenios pasan a prueba activa
La Inquisición de Bitcoin activó OP_TEMPLATEHASH del BIP-446 el 27 de julio en el bloque signet 314.928. Esta instrucción permite que un Tapscript se comprometa con la transacción exacta que puede gastar una salida, brindando a los monederos y sistemas de segunda capa un primitivo de convenio.
Una bodega utiliza ese primitivo mediante una primera transacción que anuncia un intento de retiro y crea un retraso durante el cual el propietario puede redirigir los fondos a una dirección más segura o bloquear el pago del ladrón.
Las construcciones actuales pueden utilizar transacciones prefirmadas y claves de firma destruidas, un modelo operativo que se vuelve frágil con saldos grandes y períodos de almacenamiento prolongados.
BIP-448 propone un paquete Tapscript de tres opcodes que combina OP_TEMPLATEHASH con OP_CHECKSIGFROMSTACK y OP_INTERNALKEY.
Gregory Sanders, Antoine Poinsot y Steven Roose vinculan el paquete con transacciones reasignables, canales de pago más simples, diseños de Lightning multiparte, statechains y variantes de Ark.
Los revisores pueden comparar una activación independiente de TEMPLATEHASH, con su superficie de revisión más pequeña y sus herramientas de bodega anteriores, con el mayor soporte para sistemas de pago de BIP-448 y la menor probabilidad de otra bifurcación suave.
Un período de prueba más largo mantiene las reglas de consenso actuales y prolonga la dependencia de custodios o construcciones prefirmadas frágiles.
Para los titulares, covenant policy determines cuánto control puede codificar un monedero antes de que los fondos salgan de una dirección.
Los retrasos en bóvedas, rutas de recuperación y plantillas de gasto restringido podrían fortalecer la autocustodia y mantener el control fuera de exchanges, ETFs o custodios profesionales.
| Propuesta | Cambio principal | Caso de uso principal | Interacción |
|---|---|---|---|
| BIP-446 / OP_TEMPLATEHASH | Vamos a que Tapscript comprometa la transacción de gasto | Bóvedas, rutas de recuperación, gastos restringidos | Superficie de revisión más pequeña, pero capacidad más limitada |
| Paquete BIP-448 | Combina OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK y OP_INTERNALKEY | Canales de pago, Lightning multiparte, statechains, variantes de Ark | Mayor utilidad, pero mayor carga de revisión por consenso |
| No se activará ningún covenant | Mantiene las reglas de consenso actuales | Bóvedas con firma previa, controles de custodia, modelos de monedero existentes | Evita el riesgo de bifurcación suave, pero debilita las herramientas de auto-custodia |
La migración cuántica establece la fecha límite de propiedad
BIP-361 coloca la tarea de coordinación más grande en un reloj de cinco años. El borrador detendría la creación de nuevos saldos vulnerables a la computación cuántica alrededor de tres años después de la activación, y luego los nodos reforzarían la verificación para las rutas de gasto de ECDSA y Schnorr heredados alrededor del año cinco.
La fase B requeriría un protocolo de rescate resistente a la computación cuántica para gastos heredados, aunque el borrador aún no especifica un único diseño de rescate.
Ese cronograma requeriría que los exchanges, custodios, proveedores de monederos y titulares individuales transfirieran fondos a un tipo de salida post-cuántica. Los propietarios que no migren antes de la Fase B deberán cumplir con las nuevas condiciones de rescate.
Al incluir garantías de propiedad dentro del diseño de seguridad, BIP-361 busca impedir que un operador cuántico transfiera monedas expuestas a través de rutas de gasto heredadas. Los propietarios que pierdan el plazo podrían enfrentar mayor dificultad para recuperar sus fondos, y cualquier mecanismo de rescate requeriría reglas para el diseño de pruebas, privacidad, controles de fraude y fondos inactivos.
| Fase | Hora aproximada | ¿Qué cambios? | ¿Quién debe actuar? |
|---|---|---|---|
| Activación | Año 0 | Comienza el reloj de migración cuántica | Desarrolladores, operadores de nodos, proveedores de monederos, exchanges, custodios |
| Fase A | Alrededor del año 3 | Las nuevas salidas vulnerables a la computación cuántica dejarían de crearse | Monederos, exchanges, procesadores de pagos, custodios |
| Fase B | Alrededor del año 5 | La verificación heredada de ECDSA/Schnorr se reforzaría con reglas de rescate cuánticamente seguras | Todos los titulares con salidas vulnerables |
En el escenario alcista, el proceso BIP-110 genera estándares más claros para la preparación de la red. BIP-54 recibe una revisión concentrada, las propuestas de convenio obtienen datos comparativos de signet, y la planificación cuántica recibe un plazo de implementación de varios años.
Los monederos obtienen controles de robo más robustos, los nodos obtienen límites de validación más estrictos y los custodios obtienen tiempo para inventariar los resultados vulnerables.
En el escenario bajista, la disputa por el spam convierte cada bifurcación suave en una contienda factional. Consensus Cleanup permanece en signet, el trabajo sobre covenant se fragmenta entre paquetes de opcode competidores, y la política post-cuántica espera una amenaza criptográfica más inminente.
Bitcoin luego lleva errores conocidos, herramientas de autocustodia más débiles y un calendario de migración comprimido al mismo proceso de gobernanza.
La ventana de agosto de BIP-110 creará un único registro de la gobernanza de bitcoin, y Consensus Cleanup, covenants y BIP-361 extenderán ese registro hacia el mantenimiento, la custodia y la supervivencia criptográfica.
La trayectoria del bitcoin ahora depende de identificar qué propuestas de protocolo protegen sus funciones fundamentales y construir consenso antes de que las condiciones de emergencia establezcan el calendario.
La publicación Cuatro errores sin parchear, un reloj cuántico de 5 años y un enfrentamiento entre mineros están empujando a Bitcoin a una encrucijada crítica apareció primero en CryptoSlate.