LearnBitcoin

Glosario

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 un scriptPubKey P2WSH.
  • 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

Fuentes (6)

Referencias externas (3)

Términos relacionados (5)

Publicado el . No hay correcciones registradas para esta página.

Editar esta página en GitHub