P2SH-P2WSH (SegWit anidado)
Una salida P2WSH envuelta en una capa exterior P2SH, de modo que la dirección parece legacy (empieza con '3') mientras el gasto usa datos de testigo de SegWit.
Traducción hecha con ayuda de IA, pendiente de revisión humana. Lee el original (en inglés).
P2SH-P2WSH, a veces llamado "script SegWit anidado" (nested SegWit) o "P2WSH envuelto en P2SH", es una salida P2WSH envuelta dentro de una capa exterior P2SH. La dirección parece legacy (empieza con 3), pero el gasto sigue las reglas de SegWit: el script de canje (redeem script) se limita a comprometerse con un scriptPubKey P2WSH, y los datos de testigo reales quedan fuera de la estructura legacy de la transacción.
Existió por una sola razón: la compatibilidad hacia atrás durante el despliegue de SegWit que empezó en 2017.
Cuando SegWit se activó en agosto de 2017, la mayoría de las billeteras y exchanges todavía no podían enviar a direcciones SegWit nativas (bc1q...); la propia billetera de Bitcoin Core solo las añadió en la versión 0.16.0 (febrero de 2018), y aun entonces dejó SegWit envuelto como opción predeterminada. Todo el mundo sí sabía enviar a direcciones 3... (P2SH existía desde 2012, gracias al BIP 16). Para que los usuarios adoptaran SegWit antes de que el resto del ecosistema se pusiera al día, las billeteras generaban direcciones P2SH-P2WSH: legacy por fuera, SegWit por dentro. Quien enviaba veía una dirección 3... conocida; quien recibía obtenía el descuento en comisiones y la corrección de la maleabilidad que trae SegWit.
Cómo funciona la envoltura:
- Recibir. La dirección es el hash de un script de canje corto,
OP_0 <32-byte-script-hash>, que es a su vez unscriptPubKeyP2WSH. - Gastar. La entrada revela ese script de canje (semántica P2SH), y el script de gasto real más las firmas viven en la pila de testigo (semántica SegWit).
En la práctica es un gasto P2WSH con una capa de envoltura extra. La envoltura cuesta 35 bytes de scriptSig en cada gasto (la salida en sí es 11 bytes más pequeña que una P2WSH nativa), y a cambio tienes las ventajas de SegWit por dentro.
Dónde lo verías:
- Billeteras configuradas entre 2017 y 2020 que querían las ventajas de SegWit sin romper la compatibilidad con quien enviaba. La billetera de Bitcoin Core usó SegWit envuelto por defecto desde la versión 0.16.0 hasta que la versión 0.20.0 (junio de 2020) cambió a
bc1q. - Configuraciones multisig de esa época. El BIP 48, que estandarizó las rutas de derivación para multisig, asigna tipos de script distintos a SegWit anidado y a SegWit nativo, y los gastos P2WSH anidados superaron en número a los gastos P2WSH nativos en la cadena todos los años de 2017 a 2022.
El panorama actual:
- Las billeteras nuevas usan por defecto SegWit nativo (en inglés) (
bc1q...) o Taproot (bc1p...), y la opción predeterminada que el BIP 48 recomienda para multisig es P2WSH nativo. Ya no hay razón para anidar. - Los UTXOs P2SH-P2WSH que existen se pueden gastar para siempre; nada del formato caducó. En 2026 todavía eran más o menos medio por ciento de todas las entradas.
- Si tienes uno, barrerlo a una dirección SegWit nativa o Taproot en un día de comisiones bajas te cuesta una transacción, pero se paga solo con los menores costos de gasto futuros.
El mismo patrón existe para una sola firma (single-sig): P2WPKH envuelto en P2SH da una dirección 3... que se gasta bajo SegWit. Misma lógica, misma historia moderna.
Ideas clave
- Un truco de compatibilidad hacia atrás del despliegue de SegWit que empezó en 2017
- La dirección de recepción parece P2SH (empieza con '3'), pero el gasto usa datos de testigo
- Más grande y más cara que P2WSH nativo; las billeteras modernas usan por defecto bc1q o Taproot
Capítulos relacionados
Fuentes (6)
- BIP 141 - Segregated Witness, nested witness programs: in the 'P2WSH nested in BIP16 P2SH' example the scriptSig holds the redeem script 0 <32-byte-hash> (35 bytes) and the scriptPubKey is HASH160 <20-byte-hash> EQUAL, 11 bytes smaller than native P2WSH; the nested P2WPKH example adds that a nested witness program's address is 'fully transparent and backward compatible for all Bitcoin reference client since version 0.6.0'; a non-upgraded wallet can send to an upgraded one using a P2SH address
- mempool.space - block 481,824 (01:57 UTC, August 24, 2017), the first block under SegWit rules
- Bitcoin Core 0.16.0 release notes (February 26, 2018): full segwit support in the wallet, a new -addresstype option with legacy, p2sh-segwit (default) and bech32, controlling getnewaddress and createmultisigaddress; full support for native segwit (bech32) addresses added
- Bitcoin Core - BIPs implemented (doc/bips.md): BIP 16 took effect on April 1, 2012; bech32 addresses supported as of v0.16.0 and generated by default as of v0.20.0
- BIP 48 - Multi-Script Hierarchy for Multi-Sig Wallets: script_type 1' is nested SegWit (p2sh-p2wsh) and 2' is native SegWit (p2wsh); the recommended default for wallets is p2wsh
- mainnet-observer - Input Types by Count (daily CSV read October 14, 2026): nested P2WSH spends outnumbered native P2WSH spends every year from 2017 through 2022 (2020: 30.0M against 3.1M, 10.3% of all inputs), native pulled ahead in 2023, and nested P2WSH was 0.6% of inputs in 2026
Referencias externas (3)
Términos relacionados (5)
Publicado el . No hay correcciones registradas para esta página.
Editar esta página en GitHub