SegWit

El cambio fue estructural, no cosmético. Las firmas pasaron a una sección de testigo que los nodos antiguos nunca descargan, lo que permitió desplegar un aumento de capacidad como una bifurcación blanda (soft fork), y cada byte de testigo cuesta una unidad de peso en lugar de cuatro. Por eso gastar desde una dirección bc1q cuesta aproximadamente la mitad que una entrada heredada (legacy).

Cómo funciona

Segregated Witness divide una transacción en dos partes y calcula el hash de cada una por separado.

La parte base contiene la versión, las entradas, las salidas y el locktime. La parte de testigo contiene, para cada entrada, la pila de elementos que la autoriza, normalmente una firma y una clave pública. El identificador de la transacción se calcula solo sobre la parte base, así que nada del testigo puede cambiarlo. Un segundo identificador, el wtxid, abarca las dos, y la transacción coinbase fija la raíz de Merkle de todos los wtxid de un bloque, de modo que tampoco se pueden manipular los datos de testigo.

La capacidad se deriva de un cambio de contabilidad y no de un cambio del límite. Cada byte fuera del testigo cuesta cuatro unidades de peso, cada byte dentro cuesta una, y un bloque puede contener 4.000.000 unidades de peso. Por eso los datos que no son de testigo siguen sin poder superar 1.000.000 bytes, exactamente como antes, mientras las firmas viajan en el presupuesto sobrante. Un nodo anterior a 2017 que mide a la manera antigua ve un bloque válido y no pone ninguna objeción, y precisamente por eso la actualización no necesitó una bifurcación dura (hard fork).

BIP-143 reescribió cómo se firma una entrada de testigo, y la ventaja práctica es mayor de lo que parece. El antiguo algoritmo de hash de firma volvía a calcular el hash de partes de la transacción una vez por entrada, así que el trabajo de firmar una transacción con muchas entradas crecía de forma cuadrática. El nuevo reutiliza hash ya calculados y, lo que es decisivo, fija el monto que se gasta. Antes de eso, a una billetera de hardware se le podía mentir sobre cuánto valía una entrada y hacer que autorizara una comisión enorme.

SegWit también numeró sus tipos de salida. La versión de testigo 0 abarca P2WPKH y P2WSH; la versión de testigo 1 quedó vacía y más tarde la ocupó Taproot. Ahora se pueden añadir tipos de salida nuevos sin volver a discutir cada vez el formato de dirección.

Por qué importa cuando compra bitcoin

Tres cosas de su propio uso de bitcoin se remontan directamente a esta actualización.

La primera es lo que usted paga por mover monedas. Una entrada SegWit nativa ocupa alrededor de 68 vbytes frente a aproximadamente 148 de una heredada, así que una billetera que gasta tres entradas con una comisión por vB de 20 sat/vB ahorra varios miles de satoshis en una sola transacción. Ese ahorro llega cuando usted gasta, no cuando recibe, así que lo que importa es el tipo de dirección que usa su propia billetera, no aquel desde el que retira su exchange.

La segunda es lo que su billetera de hardware puede decirle con seguridad. Como BIP-143 fija el monto de la entrada, la comisión que se muestra en la pantalla de un Trezor o un Ledger se deriva de datos que el dispositivo puede verificar y no de datos que afirma la computadora conectada. Eso cerró la puerta a un ataque real, y es la razón por la que firmar una entrada heredada todavía exige entregar al dispositivo toda la transacción anterior para que compruebe el monto por sí mismo.

La tercera es Lightning y, por tanto, cualquier exchange construido sobre esa red. Strike mueve valor por Lightning de forma predeterminada, y los canales Lightning se financian en salidas SegWit porque el protocolo no puede funcionar sin un txid estable. Sin SegWit no hay canales, ni ningún producto de liquidación instantánea encima de ellos.

El error de maleabilidad que tenía que desaparecer primero

La maleabilidad de transacciones parece un caso marginal y fue el mayor obstáculo para construir cualquier cosa sobre bitcoin.

Una firma ECDSA tiene más de una codificación válida. Antes de SegWit, un tercero que observara la mempool podía tomar una transacción sin confirmar, volver a codificar una firma sin invalidarla y volver a difundirla. Las monedas seguían yendo al mismo sitio por el mismo monto. Solo cambiaba el identificador de la transacción, y cualquier software que hubiera registrado el identificador original creía ahora que el pago había desaparecido. Mt. Gox culpó públicamente a la maleabilidad de la suspensión de los retiros en febrero de 2014, una afirmación que otros desarrolladores rebatieron en su momento, pero el fallo de fondo era real.

Los canales de pago convirtieron la maleabilidad en algo fatal en lugar de molesto. Un canal funciona guardando una transacción de reembolso firmada que gasta una salida de financiación identificada por su txid, antes incluso de que se difunda esa transacción de financiación. Si cambia el txid, el reembolso se vuelve imposible de gastar, y una de las partes queda en condiciones de retener como rehén el dinero de la otra. El artículo de 2015 de Joseph Poon y Thaddeus Dryja sobre la red Lightning señalaba en su propio texto una corrección de la maleabilidad como requisito previo.

SegWit eliminó el problema de raíz al sacar las firmas de la preimagen del identificador. Toda entrada que gasta una salida de testigo tiene un txid que ningún tercero puede alterar, y por fin los protocolos de canales pudieron construirse tal como se habían diseñado.

SegWit frente a datos de testigo

SegWit es la actualización; los datos de testigo son la estructura que creó. La actualización es un acontecimiento con fecha, el 24 de agosto de 2017, y con especificación, BIP-141. Los datos de testigo son un campo que existe hoy en la mayoría de las transacciones de la red, que lleva firmas y scripts y que tiene su propia serialización y su propio peso con descuento. Decir que una transacción "usa SegWit" es una forma abreviada de decir que gasta entradas cuya autorización está en ese campo.

SegWit frente a Taproot

Dos bifurcaciones blandas, con cuatro años de diferencia, y ambas sobre testigos. SegWit creó la estructura de testigo y definió los tipos de salida de versión 0, cuyas direcciones empiezan por bc1q. Taproot ocupó la versión 1, añadió las firmas Schnorr y cambió cómo se evalúan los scripts dentro de un testigo, lo que produjo direcciones que empiezan por bc1p. Taproot solo pudo desplegarse con un costo tan bajo porque SegWit ya había construido el esquema de versiones, y por eso conviene leer las dos como un solo diseño llevado a cabo por etapas.