BIP 66

BIP 66 endureció las reglas de codificación de firmas de Bitcoin para exigir el formato estricto Distinguished Encoding Rules (DER). Activado como soft fork (bifurcación compatible hacia atrás) en julio de 2015, su objetivo principal era que las reglas de consenso de Bitcoin dejaran de depender de los detalles de cómo la biblioteca OpenSSL leía las firmas. De paso redujo un tipo de maleabilidad de las transacciones, que el BIP menciona como beneficio adicional.

El problema: antes del BIP 66, Bitcoin aceptaba cualquier firma que OpenSSL aceptara, y OpenSSL era permisivo. Una misma firma ECDSA, en términos lógicos, podía codificarse de varias maneras: ceros a la izquierda, distintas codificaciones de los enteros, búferes con relleno. Cada codificación se interpretaba como la misma firma, pero los bytes eran distintos, y eso significaba que el txid de la transacción (que se calcula sobre esos bytes) también era distinto.

Era una forma de maleabilidad de las transacciones: alguien podía interceptar una transacción ya transmitida a la red, volver a codificar la firma de otra manera válida y retransmitirla con un txid diferente. La billetera del remitente original perdía el rastro de la transacción aunque esta terminara confirmándose. El caso famoso es Mt. Gox: en febrero de 2014 culpó a la maleabilidad de las pérdidas que acabaron con el exchange, y que después cifró en unos 850,000 BTC. Christian Decker y Roger Wattenhofer, de ETH Zúrich, estudiaron más de un año de datos de la red y no encontraron un uso generalizado de ataques de maleabilidad antes de esa fecha. Según su conteo, a lo sumo unos 386 BTC pudieron haber sido robados así, de Mt. Gox o de quien fuera.

La solución del BIP 66: exigir que las firmas estén en formato DER canónico, es decir, una sola disposición de bytes por cada firma lógica. Cualquier otra cosa la rechazan todos los nodos.

Eso cerró la puerta a los trucos de codificación. No eliminó todas las formas de alterar una firma. Una firma ECDSA sigue siendo válida si su valor S se cambia por su imagen espejo en la otra mitad del rango permitido, así que cualquiera que retransmitiera una transacción podía convertir una firma "low-S" en una "high-S" y cambiar el txid. El BIP 66 no tocó eso. Bitcoin Core se niega a retransmitir firmas high-S desde la versión 0.11.1, pero eso es solo política de retransmisión. El BIP 146, que proponía convertirlo en regla de consenso, se cerró sin llegar a desplegarse. Algunos cambios al script de desbloqueo de una transacción también seguían siendo válidos.

La solución de raíz llegó con SegWit, en vigor desde el bloque 481,824, en agosto de 2017. Cuando una transacción gasta salidas SegWit, sus firmas van en una sección aparte, el testigo (witness), que el txid no cubre, de modo que cambiarlas ya no cambia el txid. Las transacciones que gastan salidas de tipo antiguo, sin SegWit, siguen siendo maleables en principio. El BIP 66 fue un paso intermedio útil.

El BIP 66 reutilizó el mecanismo de cambio por número de versión del BIP 34: una vez que 950 de los 1,000 bloques anteriores eran de versión 3, los bloques de versión 2 pasaban a ser inválidos. El mecanismo de bits de versión del BIP 9 llegó después, y su primer despliegue fue el soft fork CSV de 2016 (BIP 68, BIP 112 y BIP 113).

La regla empezó a aplicarse el 4 de julio de 2015. Poco después, un minero pequeño que no había actualizado produjo un bloque inválido, y mineros que no validaban por completo lo extendieron hasta formar una cadena de 6 bloques antes de que la cadena válida tomara la delantera. Cómo funciona Bitcoin coloca esa bifurcación junto a las otras reorganizaciones (reorgs) profundas de la historia de Bitcoin.