SegWit

El problema: el identificador dependía de la firma

Imagina que envías una transacción y, antes de que se confirme, alguien en la red la retoca. No cambia quién cobra ni cuánto. Cambia unos bytes de la firma, y con eso cambia el identificador (txid) con el que seguías la operación. La transacción se confirma, pero con otro txid. Tu software la da por perdida.

Pasaba porque, antes de SegWit, el txid se calculaba con todos los datos de la transacción, firmas incluidas. Y ciertas firmas admitían más de una codificación válida. En ECDSA, por ejemplo, la firma lleva un número, s, que se puede cambiar por otro equivalente sin invalidarla. Se llama maleabilidad de transacciones. Es una propiedad de cómo se calculaba el txid, más que un fallo suelto.

Qué cambia en la transacción

SegWit (Segregated Witness) mueve las firmas y las claves públicas fuera del scriptSig, la parte de cada entrada donde iban hasta entonces, a un campo nuevo llamado witness. Va al final, después de las salidas. Ahora hay dos identificadores:

• txid: se calcula sin el witness, con la serialización de siempre. Es el que se usa en el árbol de Merkle de la cabecera y para señalar la salida que se gasta.
• wtxid: se calcula con todo, witness incluido. Sus hashes van en un árbol de Merkle propio, cuya raíz se compromete en una salida OP_RETURN de la transacción coinbase (BIP-141).

Un nodo antiguo ve el mismo txid de siempre.

Qué maleabilidad arregla y cuál no

Si todas las entradas gastan salidas SegWit, un tercero ya no puede cambiar el txid, porque la firma no entra en él. Basta una entrada antigua sin arreglar para que el txid vuelva a ser maleable. Tampoco cambia otra cosa: quien tiene la clave siempre puede firmar otra transacción distinta, y el wtxid sigue dependiendo del witness. En una multifirma de m de n, cambiar el txid exige que se pongan de acuerdo m de los titulares de clave (BIP-141).

Lightning lo necesitaba por esto. La primera transacción de compromiso de un canal, que sirve de reembolso, se firma antes de emitir la de financiación, y la señala por su txid. Si ese txid pudiera cambiar, los fondos quedarían bloqueados en la salida de 2 de 2 a merced de la otra parte. Por eso BOLT 2 recomienda al que financia que use solo entradas SegWit. Puedes seguir la historia del canal en Lightning Network.

BIP-143 añade otras dos mejoras para las entradas SegWit v0. Corrige el coste cuadrático de verificar firmas. El BIP recuerda que una sola transacción de 1 MB con 5.569 operaciones de firma podía tardar unos 25 segundos en verificarse, cuando un bloque normal tardaba 2. Con SegWit ese coste crece de forma lineal, pero solo en las entradas SegWit. Además, la firma compromete el importe de la entrada, para que una billetera (wallet) fría conozca la comisión sin ver la transacción anterior. En 2020 se vio que con varias entradas eso no basta (CVE-2020-14199): se podía engañar a una billetera de hardware para que firmara dos veces y pagara una comisión enorme. Desde entonces las billeteras de hardware vuelven a pedir la transacción anterior completa. Con Taproot ya no hace falta: su firma compromete los importes de todas las entradas (BIP-341).

El peso y el vbyte

El límite de un bloque ya no se mide en bytes, sino en unidades de peso (weight units, WU): como máximo 4.000.000 (MAX_BLOCK_WEIGHT en consensus.h de Bitcoin Core). Cada byte que no es witness pesa 4 WU. Cada byte de witness pesa 1. El vbyte (vB) es el peso dividido entre 4 y redondeado hacia arriba. Un vbyte no es un byte: es una unidad de coste.

Un ejemplo, calculado con una firma de 71 o 72 bytes. Una transacción P2WPKH con una entrada y dos salidas tiene 113 bytes sin witness y unos 110 de witness. Pesa 113 × 4 + 110 = 562 WU, unos 141 vB, aunque ocupe 223 bytes en total. La misma operación en el formato antiguo P2PKH ocupa unos 226 bytes, que son 904 WU o 226 vB. A 10 sat/vB, la comisión sería de unos 1.410 sats con SegWit frente a unos 2.260 sats con el formato antiguo. Es un ejemplo, no una cotización: la tarifa la fija cada día el mercado.

El bloque no pasó a 4 MB. Un bloque solo con transacciones antiguas sigue limitado a 1.000.000 de bytes. Para acercarse a 4 MB haría falta un bloque casi todo witness. Uno de los mayores fue el 774.628 (1 de febrero de 2023), con 3.955.272 bytes (mempool.space). Los bloques habituales son mucho menores: en una muestra del 6 de octubre de 2026 (alturas 970.200 a 970.214, mempool.space), midieron entre 1,46 y 1,77 MB, con una media de unos 1,58 MB, todos cerca de las 4 M WU. En la práctica, SegWit hace que quepan más transacciones por bloque: hoy rondan 1,5 MB de datos donde antes el tope era 1 MB.

Por qué fue un soft fork, y qué precio tiene

Un nodo anterior a SegWit no entiende las salidas nuevas: para él, son salidas que puede gastar cualquiera. No es un agujero en la práctica, porque los mineros que aplican SegWit rechazan los bloques que las gasten sin un witness válido. Las reglas nuevas solo restringen lo que antes se permitía, y por eso es un soft fork.

El precio es que un nodo sin actualizar sigue en la red, pero no ve ni valida el witness. Depende de que la mayoría del hashrate haga cumplir las reglas nuevas. Quien quiera verificar todo por sí mismo debe actualizar.

Direcciones y versiones

SegWit introdujo los programas witness: una versión (0 a 16) y un dato de 2 a 40 bytes. En la versión 0, 20 bytes son P2WPKH y 32 bytes son P2WSH, que sirve para multifirmas y canales. Se escriben con Bech32 (BIP-173) y empiezan por bc1q. Las versiones 1 a 16 quedaron reservadas: la 1 se usó para Taproot, con Bech32m (BIP-350) y direcciones bc1p. Hay también una forma de transición, P2SH-P2WPKH, que empieza por 3. La comparativa completa está en tipos de direcciones.

Activación y uso hoy

SegWit está activo desde el bloque 481.824, el 24 de agosto de 2017. El camino hasta ahí fue largo y disputado; está contado en la guerra de SegWit y en las guerras de bloques.

Según Glassnode, a 5 de octubre de 2026 más de cuatro de cada cinco transacciones gastaban al menos una entrada SegWit. Es una fuente secundaria, otras fuentes dan cifras distintas y no está claro si cuenta las entradas Taproot, así que conviene tomarlo como un orden de magnitud.

Qué significa para ti

Si usas una billetera moderna, ya lo usas sin pensarlo, y pagas menos comisión por la misma operación que con el formato antiguo. Si gestionas un canal de Lightning o programas con transacciones sin confirmar, el txid solo es estable si todas las entradas son SegWit. Y si ejecutas un nodo, comprueba que está actualizado: la protección que da SegWit depende de que valides el witness.