BIP 54 restringe cuatro casos límite históricos del consenso sin añadir un nuevo opcode para usuarios; Complete significa que la especificación está terminada, no activada en Bitcoin mainnet.
Antoine Poinsot y Matt Corallo reunieron en BIP 54 cuatro correcciones acotadas: timewarp, bloques con validación extremadamente costosa, la debilidad del árbol de Merkle ante transacciones de 64 bytes y el riesgo futuro de transacciones coinbase duplicadas. El paquete no añade un opcode nuevo para usuarios. [1]
En cada frontera de un periodo de 2016 bloques, el BIP exige que el timestamp del primer bloque sea como mínimo la hora del bloque anterior menos 7 200 segundos y que el del último bloque sea al menos la hora del primero del periodo. Así cierra el timewarp clásico y un periodo Murch–Zawy negativo. [1]
Para cada transacción que no sea coinbase fija un máximo de 2 500 legacy signature operations contadas en scriptSig, scriptPubKey y P2SH redeemScript. El BIP afirma que reduce unas cuarenta veces el peor tiempo de validación sin afectar transacciones estándar normales. [1]
Las transacciones cuya serialización sin witness data mida exactamente 64 bytes serían inválidas tras la activación. Esos mismos 64 bytes pueden interpretarse como el par de hashes de un nodo interno del árbol de Merkle, lo que complica las pruebas simplificadas seguras. [1]
La coinbase tendría que usar nLockTime igual a la altura del bloque menos 1 y nSequence distinto de 0xffffffff. Cada coinbase futura quedaría diferenciada de las excepciones históricas y, tras la activación, podría omitirse para siempre la comprobación BIP 30 antes de la altura de riesgo más cercana 1 983 702. [1]
La especificación alcanzó la versión 1.0.0 y el estado Complete en mayo de 2026. El changelog señala el 22 de mayo; Bitcoin Core tiene una implementación de referencia sin activación en mainnet y ya crea plantillas de bloque más compatibles, pero nada de eso activa por sí solo las reglas nuevas. [3]
El borrador BIP 95 para Testnet 5 prevé aplicar BIP 54 desde el bloque 1, pero sigue en estado Draft. Una red de prueba, signet o código inactivo ayuda a verificar la implementación; no demuestra consenso en mainnet. [4]
Para verificar una afirmación hay que revisar la versión vigente del BIP, el estado de cualquier mecanismo de activación y la versión exacta del nodo. Complete describe un documento terminado; la validación plena de las reglas nuevas solo empieza con una activación separada del soft fork, si llega a ocurrir. [2]
Para obtener la imagen más completa, lee esta entrada junto con Reglas de consenso, Soft Fork, Timewarp Attack, Proof of Work, Bitcoin Core, Transacción. También enlazan con esta entrada Timewarp Attack.
01¿Está BIP 54 activo en Bitcoin mainnet?+
No. La especificación está Complete y existe una implementación sin activación en mainnet, pero las restricciones de consenso requieren un proceso de activación independiente.
02¿Qué cambia exactamente Consensus Cleanup?+
Restringe timestamps en las fronteras de periodos de dificultad, limita legacy sigops por transacción, prohíbe transacciones de exactamente 64 bytes sin witness data y garantiza la unicidad de futuras coinbase.