Hasta ahora en esta serie cubrimos qué es multisig y qué umbral elegir. Ambos artículos describían el comportamiento de una wallet multisig — m de n llaves firman, la chain comprueba el umbral, el dinero se mueve. Ninguno decía mucho sobre cómo está realmente armada la wallet por debajo. Eso es este artículo.
La versión corta: cuando SSP crea una wallet para ti, no se limita a generar dos llaves aleatorias y dar el trabajo por terminado. Las genera de una forma que sigue un estándar documentado llamado BIP48, de modo que la wallet resultante es interoperable, recuperable desde software distinto a SSP, y predecible al inspeccionar on-chain. Este es el artículo que explica qué es BIP48, por qué existe, y por qué "esta wallet usa BIP48" es una de las oraciones más aburridas e importantes en multisig.
TL;DR
- Una ruta de derivación es el camino desde una sola frase semilla a una llave específica (y dirección) en una wallet. Rutas estandarizadas como BIP44 / BIP48 permiten que distintos software de wallet lleguen a las mismas llaves a partir de la misma seed.
- BIP48 es la spec específica para wallets multisig. Dice: aquí está la ruta de derivación canónica para las
mllaves que componen una wallet 2-of-3, 3-of-5, etc., a través de los principales tipos de script de salida. - SSP usa BIP48. Eso significa que las dos seeds que tu wallet SSP generó son usables desde cualquier otra wallet compatible con BIP48 (Sparrow, Electrum, los descriptores de Bitcoin Core) — no solo desde SSP misma.
- BIP48 arregla un problema que tenía la spec anterior de multisig (BIP45): separa limpiamente las llaves para distintos tipos de script (legacy, P2SH-wrapped SegWit, native SegWit, Taproot), de modo que una sola seed phrase puede contenerlas todas sin colisión.
- No necesitas lidiar manualmente con rutas de derivación para usar SSP. Deberías saber que existen para que "recuperación de wallet" no se sienta como magia — y para entender a qué corresponde realmente tu seed.
Un recorrido de 30 segundos por las rutas de derivación
Antes de que BIP48 tuviera significado, la maquinaria subyacente tenía que existir. Esa maquinaria es BIP32: wallets hierarchical deterministic (HD). La idea central es que una llave maestra — derivada de una seed phrase — puede producir un árbol infinito de llaves hijas, de manera determinista. Recorre una ruta específica por el árbol y siempre terminas en la misma llave hija. Recorre una distinta y terminas en otra.
Las rutas se ven así:
m / purpose' / coin_type' / account' / change / index
Por ejemplo, la ruta BIP44 m / 44' / 0' / 0' / 0 / 0 alcanza la primera dirección de recepción de la primera cuenta de Bitcoin bajo reglas BIP44. Cambia el coin_type a 60' y estás en el espacio de Ethereum; cambia el purpose a 84' y estás en el espacio BIP84 (native SegWit); y así. El apóstrofo (') es derivación hardened — el hijo no puede invertirse de vuelta al padre. Cada segmento después del maestro es un número de 32 bits, particionado por convención.
Esta es la parte que se suele pasar por alto: la ruta es metadata, no un secreto. Cualquiera que conozca tu ruta y tu llave privada (o llave extendida) puede derivar las mismas direcciones. La ruta le dice a la wallet dónde mirar. La seed le dice qué hay ahí.
Para un repaso amistoso de qué es la seed misma, el post de seed phrase best practices es prerequisito.
Qué especifica BIP48
BIP48 vive en m / 48' / coin_type' / account' / script_type' / change / index. La adición interesante es script_type' — el penúltimo segmento.
Ese segmento codifica qué tipo de output multisig corresponde a la ruta:
0'→ P2SH (multisig legacy)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ multisig equivalente a Taproot (por enmiendas BIP48)
Esto importa porque en la práctica el mismo conjunto de cosigners m-of-n produce direcciones distintas on-chain según qué script de output se use. Sin BIP48, una wallet podría usar silenciosamente un tipo, el software de recuperación podría asumir otro, y el resultado son dos wallets que parecen deberían derivar las mismas monedas — pero no lo hacen, porque están computando direcciones distintas.
BIP48 también fija el segmento purpose' en 48', así las rutas multisig no pueden colisionar con rutas single-sig BIP44/BIP49/BIP84. Una seed puede contener una wallet single-sig en BIP84 y una wallet multisig 2-of-2 en BIP48, sin interferencia. Cada una vive en su propio subárbol.
Más allá de la ruta en sí, BIP48 especifica cómo deben ordenarse las llaves públicas de los cosigners ("xpubs") al construir el output multisig. La regla canónica es ordenamiento lexicográfico de las llaves públicas antes de meterlas en el redeem script. Eso elimina ambigüedad — cada wallet conforme con BIP48 que construya desde los mismos xpubs computa la misma dirección. Sin esa regla, dos wallets podrían combinar las mismas llaves en órdenes distintos y terminar en direcciones distintas con la misma regla de redención.
Si quieres leer la spec literal, vive en el repo de Bitcoin BIPs (bips/bip-0048.mediawiki).
Cómo usa SSP BIP48 en la práctica
Cuando configuras una wallet SSP, se generan dos seed phrases — una en la extensión del navegador, una en la app móvil SSP Key. Cada seed phrase corresponde a una llave privada maestra. Desde cada maestra, SSP deriva la ruta BIP48 para la chain relevante (Bitcoin, Ethereum, Flux y el resto del conjunto soportado por SSP) en script_type' = 2' (native SegWit en Bitcoin; formas canónicas equivalentes en las otras chains donde aplique).
Las xpubs de ambos firmantes son entonces intercambiadas. Cada lado tiene ahora el mismo conjunto de dos xpubs, ordenadas lexicográficamente por BIP48. A partir de ese par, cada lado computa independientemente la misma dirección. Las dos mitades nunca comparten una llave privada — solo llaves públicas se mueven entre dispositivos.
Cuando recibes dinero, la dirección que se te muestra es la dirección derivada por BIP48 calculada a partir de ambas xpubs. Cuando gastas, cada dispositivo firma la misma transacción bajo su propia llave privada. El redeem script on-chain referencia ambas llaves públicas; la red comprueba ambas firmas. Ese es todo el protocolo.
La razón por la que esto importa en un escenario de recuperación: si SSP, como producto, desapareciera mañana, tú aún tendrías dos seed phrases conformes con BIP48. Cargar ambas en Sparrow (o en cualquier otra wallet capaz de multisig que soporte las rutas BIP48 que SSP usa) reconstruye la misma wallet, en las mismas direcciones, con plena capacidad de gasto. La wallet no vive dentro de SSP — vive on-chain, y las seeds más la spec BIP48 alcanzan para llegar a ella desde donde sea.
Esa propiedad es buena parte de por qué la pieza de self-custody-without-cold-storage trata una wallet SSP 2-of-2 como una wallet seria y no como una curiosidad de sabor custodial. Es recuperable a partir de estándares abiertos.
Por qué BIP48 sobre BIP45 (y no BIP44)
La spec multisig anterior era BIP45. Fue un primer intento honesto: m / 45' / cosigner_index' / change / index, con cosigner_index' codificando qué cosigner eres en la wallet. En retrospectiva tenía dos problemas.
Primero, cosigner_index' horneaba un orden dentro de la propia ruta. Eso significaba que el orden en que se añadieron los firmantes afectaba la derivación, lo que hacía frágil el setup conjunto — equivocas el orden y derivas direcciones distintas a las de tu co-firmante. BIP48 resuelve esto removiendo el cosigner index de la ruta por completo y dejando que el ordenamiento lexicográfico de las llaves públicas lo maneje.
Segundo, BIP45 no separaba por tipo de script. La misma ruta se reusaría tanto si la wallet usaba multisig P2SH legacy como multisig SegWit-wrapped. Eso creaba el mismo problema de colisión-de-direcciones-pero-no-son-las-mismas-monedas descrito arriba.
BIP44, la spec HD más general, nunca pretendió cubrir multisig. Sobrecargar BIP44 con rutas multisig creaba sus propios conflictos. BIP48 fue el arreglo explícito: un purpose number dedicado, un slot de script-type explícito, y un ordenamiento determinista de llaves. Hoy la mayoría de wallets multisig modernas convergen en él; es el estándar de facto.
Para la historia más profunda de cómo esto conecta con el siguiente capítulo de multisig — agregación Schnorr, donde múltiples firmas se comprimen en una — el siguiente artículo de esta serie, Schnorr signatures and multisig aggregation, retoma el hilo.
Qué significa esto para la interoperabilidad
La prueba más limpia de "¿es esta wallet multisig realmente self-custodial?" es: ¿puedo recuperarla sin el software de la wallet? Si la respuesta es sí — usando seeds documentadas, una ruta de derivación documentada y herramientas estándar — la wallet es genuinamente tuya. Si la respuesta es no, la wallet tiene elementos custodial ocultos.
La conformidad con BIP48 de SSP es lo que nos permite responder sí. Las seed phrases son BIP39 (mnemónico estándar), la derivación es BIP48, la construcción de direcciones es canónica BIP48. Cualquier wallet que hable los mismos estándares puede reconstruir la wallet.
Por eso la introducción Meet SSP Wallet enmarca SSP como "self-custody con multisig 2-of-2" en vez de como un servicio gestionado. Los estándares por debajo son la razón por la que ese encuadre es honesto.
Qué significa esto para ti
Tres conclusiones:
- No tienes que memorizar rutas para usar SSP. El número
m/48'/0'/0'/2'/0/0no es algo que un usuario normal deba escribir nunca. Pero saber que existe es lo que hace que "puedo recuperar esta wallet sin SSP" sea una afirmación real en vez de marketing. - Tus dos seeds son interoperables. Si alguna vez necesitas recuperar en una wallet multisig de terceros, BIP48 más tus dos seeds BIP39 más el
coin_typede la chain es la receta. El checklist de self-custody nombra esto como el paso de ensayo por una razón. - Una wallet multisig que no usa BIP48 (o similar) merece cuestionarse. Si un producto no puede decirte exactamente cómo se derivan las direcciones a partir de tus llaves, eso no es self-custody — es custodia con pasos extra. Cumplir con estándares es lo que hace verificable la afirmación de "tus llaves, tus monedas".
