Dos mejoras, dos fechas
| Mejora | Activación | Bloque | BIPs | Qué resolvía |
|---|---|---|---|---|
| SegWit | 24 de agosto de 2017 | 481.824 | 141, 143, 144, 173 | La maleabilidad de las transacciones y el límite de tamaño de bloque; dejó listas las versiones de script. |
| Taproot | 14 de noviembre de 2021 | 709.632 | 340, 341, 342, 350 | Firmas más pequeñas y agregables (Schnorr) y scripts complejos que no se revelan salvo que haga falta. |
Bloques de activación según el despliegue de BIP 141 y BIP 341, verificables en el explorador mempool.space (bloque 709.632). Ambas fueron soft forks: los nodos que no se actualizaron siguieron aceptando los bloques.
SegWit: sacar las firmas de la transacción
Respuesta corta: SegWit («testigo segregado», Segregated Witness) guarda las firmas en un campo aparte, el testigo. Antes, las firmas iban dentro de los datos que se usan para calcular el identificador de la transacción (txid); si alguien cambiaba un detalle de la firma sin invalidarla, el txid cambiaba. Eso es la maleabilidad.
Con el testigo aparte, el txid deja de depender de las firmas. Esto importa para cadenas de transacciones sin confirmar y es una de las bases técnicas de Lightning. Además, el testigo cuenta con menos peso: el límite del bloque pasó a medirse en unidades de peso (4.000.000 como máximo) y 1 vB (byte virtual) equivale a 4 de ellas, de modo que gastar una entrada SegWit ocupa menos y paga menos comisión.
Ejemplo con números: gastar una entrada de una dirección Legacy (1…) pesa unos 148 vB; la misma entrada en SegWit nativa (bc1q…) unos 67,75 vB (la SegWit «envuelta» en P2SH, 3…, es compatible con wallets antiguas pero pesa unos 91 vB). A una tarifa de 10 sat/vB son unos 1.480 sats frente a unos 678 (cálculo propio con la estructura de BIP 141; el detalle está en tipos de dirección).
Taproot: un pago complejo con cara de pago normal
Respuesta corta: Taproot permite que una salida se gaste de dos maneras: por la ruta de clave (key path), con una sola firma, o por la ruta de script (script path), revelando solo la rama del árbol de condiciones que se cumple. Si todos los implicados están de acuerdo, se usa la primera y en la cadena parece un pago normal.
Tres BIPs lo hacen posible: BIP 340 (firmas Schnorr, de 64 bytes y fáciles de combinar), BIP 341 (la estructura de Taproot, con un árbol de Merkle de scripts) y BIP 342 (Tapscript, el lenguaje de esos scripts, preparado para futuras mejoras). Gracias a que las firmas Schnorr se pueden agregar, varias claves pueden firmar como si fueran una sola (por ejemplo con MuSig2, BIP 327).
Por dentro: una salida Taproot contiene directamente una clave pública de 32 bytes, la clave de salida Q = P + H(P ‖ raíz)·G, donde P es la clave interna y «raíz» es la raíz del árbol de scripts (si lo hay). Por la ruta de clave basta una firma Schnorr de Q. Por la ruta de script se revela el script elegido, la clave P y la prueba de Merkle (el control block) para demostrar que esa rama estaba comprometida en Q; el resto de ramas no se ven. Como la clave de salida no va dentro de un hash, es pública antes de gastar: es una diferencia con bc1q…, cuya clave solo se conoce al gastar.
Qué no hace: Taproot no vuelve anónimo a Bitcoin ni oculta importes o direcciones; solo hace que ciertos pagos con varias claves o condiciones se parezcan entre sí. Una dirección Taproot empieza por bc1p… (más en tipos de dirección y en claves).
Tipos de dirección y qué contiene cada witness
Respuesta corta: cada tipo de dirección fija qué hay que presentar para gastar. En las antiguas todo va en el scriptSig; en SegWit y Taproot va en el testigo (witness), que pesa una cuarta parte. Elige un tipo y mira qué guarda la salida (scriptPubKey), qué aporta quien gasta y cuánto ocupa.
- Prefijo
1…(P2PKH)- En la salida (scriptPubKey)
- Hash de 20 bytes de la clave pública (25 bytes de script). La clave no se ve hasta gastar.
- Al gastar: scriptSig
- Firma ECDSA (~72 B) y clave pública (33 B). Todo cuenta 4 unidades de peso por byte.
- Al gastar: witness
- No existe: este formato es anterior a SegWit.
- Tamaño de la entrada
≈ 148 vB- Efecto en comisiones
- El punto de partida: ~148 vB por entrada. Es la referencia más cara para una wallet de una sola clave.
- Prefijo
3…(P2SH)- En la salida (scriptPubKey)
- Hash de 20 bytes de un script (BIP 16), que se revela al gastar. Aquí, una multifirma 2 de 3.
- Al gastar: scriptSig
- OP_0, dos firmas y el script completo (105 B). Es lo que más pesa: todo a 4 unidades por byte.
- Al gastar: witness
- Vacío en P2SH clásico. En P2SH-P2WPKH (SegWit «envuelto») el scriptSig solo lleva un puntero de 23 bytes y el resto va al testigo.
- Tamaño de la entrada
≈ 297 vB- Efecto en comisiones
- Una multifirma 2 de 3 clásica son ~297 vB por entrada. La variante P2SH-P2WPKH de una clave baja a ~91 vB.
- Prefijo
bc1q…(P2WPKH)- En la salida (scriptPubKey)
- Versión 0 y hash de 20 bytes de la clave pública (22 bytes de script). Dirección bc1q… corta.
- Al gastar: scriptSig
- Vacío: nada que firmar fuera del testigo.
- Al gastar: witness
- Firma (~72 B) y clave pública (33 B), con 1 unidad de peso por byte en lugar de 4.
- Tamaño de la entrada
≈ 67,75 vB- Efecto en comisiones
- ~67,75 vB: menos de la mitad que P2PKH. Es el estándar de las wallets de una clave.
- Prefijo
bc1q…(P2WSH)- En la salida (scriptPubKey)
- Versión 0 y hash SHA-256 de 32 bytes de un script (34 bytes). Dirección bc1q… larga (62 caracteres).
- Al gastar: scriptSig
- Vacío, igual que en P2WPKH.
- Al gastar: witness
- Un elemento vacío, dos firmas y el script completo (105 B): se revela todo el script al gastar.
- Tamaño de la entrada
≈ 104,5 vB- Efecto en comisiones
- Una multifirma 2 de 3 son ~104,5 vB, unas 2,8 veces menos que la misma en P2SH clásico.
- Prefijo
bc1p…(P2TR)- En la salida (scriptPubKey)
- Versión 1 y la clave pública de salida de 32 bytes, ya ajustada con el árbol de scripts (BIP 341). Dirección bc1p….
- Al gastar: scriptSig
- Vacío, como en el resto de SegWit.
- Al gastar: witness
- Ruta de clave: solo una firma Schnorr de 64 B (la clave ya está en la salida). Por la ruta de script: script + control block.
- Tamaño de la entrada
≈ 57,5 vB- Efecto en comisiones
- ~57,5 vB por la ruta de clave: la entrada más barata de las cinco y, en multifirma agregada, ahorra aún más.
Tamaños de una entrada (vB = peso/4) calculados con las reglas de peso de BIP 141 (los datos del testigo cuentan 1, el resto 4 unidades de peso) y la estructura de BIP 341 (Taproot, ruta de clave: testigo de 1 + 1 + 64 bytes). Firmas ECDSA de 72 bytes máximo con sighash, clave pública comprimida de 33 bytes; P2SH y P2WSH medidos como multifirma 2 de 3 (script de 105 bytes). Prefijos: BIP 16, BIP 173 y BIP 350. Cálculo propio, orden de magnitud; coincide con la guía de tipos de dirección.
SegWit y Taproot, lado a lado
| Aspecto | SegWit | Taproot |
|---|---|---|
| Dirección | bc1q… (Bech32, BIP 173) | bc1p… (Bech32m, BIP 350) |
| Firmas | ECDSA, unos 71–73 bytes (con el byte de sighash) | Schnorr, 64 bytes |
| Entrada típica (una clave) | ≈ 67,75 vB | ≈ 57,5 vB |
| Scripts complejos | Se revela todo el script al gastar (P2WSH) | Solo se revela la rama usada (árbol de Merkle) |
| Lo que aportó | Fin de la maleabilidad del txid en las entradas SegWit, descuento al testigo, base de Lightning | Firmas agregables, scripts discretos, base para mejoras futuras |
Tamaños de entrada de la guía de tipos de dirección (cálculo propio a partir de BIP 141 y BIP 341).
¿Tengo que hacer algo?
No. Tus bitcoin en direcciones antiguas siguen siendo válidos y gastables: las reglas anteriores no se retiraron. Lo único que cambia es el coste de gastar y las posibilidades de la wallet. Si tu wallet ya genera direcciones bc1q… o bc1p…, no hay nada más que hacer.
Si algún día mueves fondos a otro tipo de dirección, es una transacción normal con su comisión: no hay prisa y no es obligatorio. La guía de cómo guardar tu bitcoin explica cómo elegir wallet y proteger la semilla.
Preguntas frecuentes
¿Qué es SegWit en una frase?
Es la actualización de agosto de 2017 que separa las firmas (el «testigo») del resto de la transacción: corrige la maleabilidad del txid, hace más barato gastar y dejó Bitcoin preparado para Lightning.
¿Qué es Taproot en una frase?
Es la actualización de noviembre de 2021 que introduce las firmas Schnorr y un árbol de scripts: un pago con varias claves o condiciones puede gastarse con una sola firma y, en ese caso, se ve en la cadena como un pago normal.
¿Qué es un soft fork?
Es un cambio de reglas que solo restringe lo que es válido, de modo que los nodos que no se actualizan siguen aceptando los bloques. SegWit y Taproot lo fueron. Se distingue de un hard fork, que exige actualizar a todos o la red se parte.
¿Taproot hace Bitcoin anónimo?
No. Direcciones, importes y el historial de la cadena siguen siendo públicos. Taproot mejora la privacidad de ciertos casos (multifirma, contratos) porque no revela las condiciones no usadas, pero para el resto la guía de privacidad sigue siendo la referencia.
¿Por qué SegWit ayudó a Lightning?
Los canales de Lightning dependen de transacciones que se firman antes de publicarse y que referencian a otras aún sin confirmar. Si el txid pudiera cambiar por maleabilidad, esas referencias se romperían. Con SegWit el txid ya no depende de las firmas.
Fuentes: BIP 141, BIP 143 y BIP 144 (SegWit), BIP 173 y BIP 350 (Bech32 y Bech32m), BIP 340, BIP 341 y BIP 342 (Schnorr, Taproot y Tapscript), BIP 327 (MuSig2) y Bitcoin Core: SegWit benefits. Fechas y bloques de activación comprobables en mempool.space.