Segregated Witness se activó en el bloque 481.824, minado a las 01:57 UTC del 24 de agosto de 2017. Suele archivarse como "el acuerdo sobre el tamaño de bloque", lo menos interesante del asunto. Lo que hizo fue sacar los datos de firma de la estructura desde la que se calcula el identificador de una transacción, y después cobrar por ellos a otra tarifa. Ambas mitades siguen determinando lo que cabe hoy en un bloque.
El problema para el que se construyó
El txid de una transacción es un hash de la transacción, y antes de SegWit los datos que se
hasheaban incluían las firmas. Las firmas no son únicas: una firma ECDSA puede reescribirse
como otra igualmente válida sobre el mismo mensaje, y un scriptSig puede rellenarse de
maneras que el intérprete acepta. Así que cualquiera que retransmitiera una transacción sin
confirmar podía alterarla y volver a difundirla, produciendo una transacción que paga los
mismos montos a las mismas direcciones bajo un txid distinto. Eso es la maleabilidad de
transacciones. No roba nada, porque las salidas no pueden cambiar sin una firma válida
sobre ellas. Lo que rompe es todo lo que se refiere a una transacción antes de que confirme.
El daño serio está un nivel más arriba. Un protocolo que firma por adelantado una segunda
transacción que gasta la salida de una primera todavía sin confirmar tiene que nombrar a la
primera por txid. Si el txid cambia, la segunda gasta una salida que no existe, y no se
puede volver a firmar si la contraparte dejó de responder. Esa es la forma de un canal
Lightning: una transacción de financiación, más una transacción de compromiso firmada de
antemano para que cualquiera de las dos partes pueda recuperar su dinero. BIP 141 plantea el
arreglo en esos mismos términos: "permite crear cadenas de dependencia de transacciones sin
confirmar sin riesgo de contraparte, una característica importante para protocolos fuera de
la cadena como la Lightning Network".
La historia que más se repite sobre esto es también la menos exacta. Mt. Gox culpó a los ataques de maleabilidad de haber vaciado sus cuentas cuando se declaró en quiebra en febrero de 2014, pero Decker y Wattenhofer midieron el año previo de tráfico y no hallaron "un uso extendido de ataques de maleabilidad antes del cierre de MtGox".
Sacar el witness del identificador
BIP 141 define "una nueva estructura llamada witness que se compromete en los bloques por separado del árbol de merkle de transacciones. Esta estructura contiene datos necesarios para comprobar la validez de la transacción pero no para determinar sus efectos". Lo que hace una transacción lo deciden las salidas que consume y las que crea; las firmas solo prueban que estaba permitido.
Así que una transacción pasa a tener dos identificadores. El txid no cambia: el doble SHA256
de [nVersion][txins][txouts][nLockTime]. Se define un wtxid nuevo: el doble SHA256 de
[nVersion][marker][flag][txins][txouts][witness][nLockTime]. El txid se compromete con lo
que la transacción hace y no con cómo se autorizó, de modo que "los cambios en la forma en
que se firmó la transacción ya no son relevantes para su identificación".
Con eso el witness no queda sin comprobar: los valores wtxid se hashean en una raíz de
witness comprometida en una salida OP_RETURN de la transacción coinbase, y
BIP 143 dio a los gastos con
witness un digest de firma que además cubre el monto gastado. Pero el arreglo es por
transacción, no por red: "las transacciones segwit solo evitan la maleabilidad si todas sus
entradas son gastos segwit".
El peso de bloque, exactamente como lo define BIP 141
Antes de SegWit, "los bloques están limitados actualmente a 1.000.000 de bytes (1MB) de tamaño total". BIP 141 reemplaza eso por un límite en otra unidad, construido a partir de dos medidas del mismo bloque. El tamaño base es "el tamaño del bloque en bytes con la serialización de transacciones original, sin ningún dato relacionado con el witness, tal como lo ve un nodo no actualizado". El tamaño total es el tamaño del bloque "incluyendo los datos base y los datos de witness". Entonces:
El peso de bloque se define como tamaño base * 3 + tamaño total. [...] La nueva regla es peso de bloque ≤ 4.000.000.
Conviene leerla despacio; la cobertura de segunda mano la deforma constantemente. Un byte fuera del witness aparece en el tamaño base y otra vez en el tamaño total, así que se cuenta 3 + 1 veces: un byte fuera del witness cuesta cuatro unidades de peso y un byte de witness cuesta una. Los datos de firma se cobran a la cuarta parte de la tarifa que se cobra a todo lo demás. El peso de una transacción dividido entre cuatro, redondeando hacia arriba, es su tamaño virtual: la unidad detrás de sats por vbyte.
Por qué la capacidad no es un número
Escrita como peso = 4 * base + witness ≤ 4.000.000, la regla tiene una consecuencia inmediata: el tamaño base nunca puede superar 1.000.000 de bytes. El bloque que ve un nodo no actualizado, con el witness quitado, sigue por debajo de un megabyte, y sigue cumpliendo la regla que ese nodo aplica.
La segunda consecuencia es que no hay una capacidad fija en bytes. Cuatro megabytes exigirían un bloque hecho casi por completo de datos de witness, cosa que ningún bloque real es. El texto de Bitcoin Core de 2016 estimaba "un límite efectivo más cercano a 1,6 a 2 MB", y los promedios diarios de mainnet-observer dan diciembre de 2017 en 1,05 MB y 3,96 millones de peso, mayo de 2023 en 1,70 MB y 3,98 millones, y los treinta días hasta el 19 de agosto de 2026 en 1,62 MB y 3,93 millones. El mismo tope, tres recuentos de bytes distintos, porque la mezcla de transacciones cambió por debajo. Los mineros llenan cuatro millones de unidades de peso y ordenan por comisión por unidad de peso, así que la capacidad en bytes es un resultado de lo que hace la gente, no un dato de partida.
Cómo lo hizo un soft fork
Un programa de witness es un scriptPubKey formado por un push de byte de versión seguido de
un push de entre 2 y 40 bytes, y un gasto de ese tipo lleva un scriptSig vacío. Pásese eso
por un nodo de 2016: ve 0 <hash-de-20-bytes>, lo evalúa como un script común, encuentra un
valor no vacío en la pila y lo da por bueno. Acaba de aceptar un gasto sin ninguna firma
dentro. BIP 141 lo dice así: los nodos no actualizados "no verán ni validarán los datos de
witness y considerarán todos los programas de witness como scripts que cualquiera puede
gastar" (anyone-can-spend scripts).
Eso es lo que hace posible un soft fork, y tiene un precio. La compatibilidad hacia atrás significa que el nodo viejo no está validando esos gastos; los acepta porque no puede ver la regla que cumplen. Lo que protege las monedas son los nodos actualizados y el poder de cómputo que aplica BIP 141, no la comprobación propia del nodo viejo.
Las direcciones, y por qué tardaron años
Bajo la versión 0 de witness, un programa de 20 bytes es pay-to-witness-public-key-hash
(P2WPKH): el programa es el HASH160 de una clave pública, y el witness contiene una firma y
esa clave. Un programa de 32 bytes es pay-to-witness-script-hash (P2WSH), la misma idea para
un script: el programa es el SHA256 de un witnessScript que se revela al gastar, más largo
que los 20 bytes de P2SH porque "mejora la seguridad frente a posibles ataques de colisión".
Cualquiera de los dos puede anidarse dentro de una salida P2SH, que es como las billeteras
lanzaron SegWit antes de que bech32 tuviera soporte amplio, a costa de 24 bytes fuera del
witness en cada gasto.
Las salidas de witness nativas necesitaban un formato de dirección nuevo, y ese es
BIP 173: bech32, "un formato
base32 con suma de verificación", con la parte legible bc en mainnet. Base58 "necesita mucho
espacio en los códigos QR" y su "suma de verificación de doble SHA256 es lenta y no tiene
garantías de detección de errores"; bech32 usa un código BCH que "garantiza la detección de
cualquier error que afecte como mucho a 4 caracteres".
La adopción tardó años, por una razón ajena a la criptografía: una dirección nueva para recibir no sirve hasta que el software que envía sabe interpretar el formato, y el lado que envía es cada casa de cambio y cada billetera. Contando las transacciones que gastan al menos una entrada de witness, la serie diaria de mainnet-observer sitúa la proporción cerca del 3 por ciento en septiembre de 2017 y del 15 por ciento en febrero de 2018; superó la mitad por primera vez en octubre de 2019, volvió a caer por debajo durante casi todo 2020, y solo se asentó por encima del 80 por ciento a partir de noviembre de 2021. En los treinta días hasta el 19 de agosto de 2026 fue del 97,5 por ciento, cifra que ahora incluye Taproot, porque una salida de BIP 341 es witness versión 1.
Lo que no hace
No subió el tamaño de bloque a cuatro megabytes, como muestran las medidas anteriores. No abarató las comisiones de forma permanente, porque cambiar el precio de un tipo de byte respecto de otro no es lo mismo que añadir espacio. No cambió nada sobre la propiedad, la emisión ni el calendario de suministro. No arregla la maleabilidad de una transacción que todavía tenga una entrada sin witness. Y no dejó mejor informado a un nodo no actualizado: ese nodo ahora valida estrictamente menos que antes.
Un descuento es un precio, y los precios tienen consecuencias
El descuento trata de lo que un byte le cuesta a un nodo dentro de años: los datos de firma se pueden descartar una vez comprobados, mientras que una salida queda en el conjunto UTXO que cada nodo mantiene. Así que SegWit hace que "los datos de firma, que no afectan al tamaño del conjunto UTXO, cuesten un 75% menos que los datos que sí lo afectan", un incentivo hacia formas de transacción que dejan menos residuo permanente. BIP 141 lo nombró de antemano: el "tamaño del witness podría ignorarse o descontarse al calcular el tamaño del bloque".
Lo que nadie anticipó es que "witness" dejaría de significar "firmas". La ruta de script de Taproot quitó el viejo techo al tamaño de los scripts, y en cuanto pudieron entrar bytes arbitrarios en un witness el descuento se les aplicó también, que es como las inscripciones acabaron guardando imágenes a la cuarta parte de la tarifa vigente, y cómo se comportó el mercado de comisiones en mayo de 2023.
Nadie decidió subvencionar imágenes. Se le puso precio a un recurso por una buena razón, y seis años después la gente optimizó contra ese precio para un fin que sus autores no habían imaginado. El límite de cuatro millones de unidades de peso es menos un acuerdo sobre el tamaño de bloque que una afirmación sobre qué bytes le cuestan algo a un nodo, y toda la discusión sobre espacio de bloque desde entonces ha sido sobre si esa afirmación sigue en pie.