Multisig single-signer: cómo SSP hace que dos dispositivos se sientan como una wallet

Si has estado con esta serie desde qué es multisig, conoces el protocolo: más de una llave privada debe firmar antes de que el dinero se mueva. Has visto el selector m-of-n, el cableado BIP48, el horizonte de agregación Schnorr, y la comparación social-recovery. Todo eso es la maquinaria. Este artículo es sobre la experiencia.

La crítica histórica honesta a multisig es que ha sido hostil de usar. Múltiples wallets, intercambio manual de PSBT, software coordinador, fiestas de firma — el protocolo era sólido, pero la UX era un castigo. Single-signer multisig es la idea de producto que arregla esto: una wallet que usa una regla de gasto multisig completa on-chain, pero se siente — para la persona que la usa — como una sola wallet con un solo botón. SSP está construido alrededor de esta idea.

TL;DR

• "Single-signer" no significa una llave. Significa que el protocolo aún tiene m de n llaves, pero la UX de firma se colapsa en un solo flujo. El usuario firma en un solo lugar; la wallet maneja la coordinación dispositivo-a-dispositivo.
• La forma específica de SSP: una extensión de navegador, una app móvil (SSP Key), una identidad de wallet. Haces clic en Send, confirmas en el teléfono, la transacción se transmite. Suceden dos firmas; experimentas una.
• La victoria es que el beneficio del umbral (resistencia al robo, sin punto único de fallo) se preserva mientras el coste de coordinación baja casi al de UX single-sig.
• El coste es que esto solo funciona mientras ambos dispositivos sean alcanzables. En el momento en que la UX tenga que exponer la multi-naturaleza — recuperación, reemplazo de dispositivo, restauración en un tercero — la abstracción se rompe, por diseño.
• Este patrón es lo más cercano a una respuesta "sin compromisos" para self-custody en solitario a escala retail. Es la apuesta de SSP, y cada vez más la apuesta de cada producto multisig moderno (Coinbase Wallet, la historia de custodia en evolución de Phantom, el flujo smart-account de Safe en Ethereum).

El ideal single-signer: lo que los usuarios realmente quieren

Si preguntas a un usuario de self-custody qué quiere, obtienes respuestas que se contradicen:

• "Quiero mis monedas a salvo." — Implica multisig, hardware, redundancia.
• "Quiero firmar una transacción en cinco segundos." — Implica un solo dispositivo, un toque.
• "Quiero recuperarme si pierdo algo." — Implica backups de seed, redundancia.
• "Nunca quiero escribir una seed de nuevo." — Implica custodia de llaves gestionada por plataforma.
• "Quiero que sea barato." — Implica una huella on-chain mínima.

Estos objetivos no se alinean todos. La historia del diseño de wallets de self-custody es la historia de qué objetivos honrar y cuáles rechazar educadamente. Las hardware wallets honran seguridad y recuperación al coste de UX. Las wallets smart-contract honran UX y recuperación al coste de alcance cross-chain. Las hot wallets puras honran UX y barato al coste de seguridad.

Single-signer multisig es un intento de honrar los cinco — parcialmente — separando la semántica de protocolo de la semántica de interfaz. La wallet sigue haciendo el baile multisig completo on-chain; el usuario simplemente no tiene que participar en ese baile más de una vez por transacción.

Cómo lo entrega SSP

La implementación específica de SSP, en cristiano:

1. En la configuración, instalas la extensión de navegador y la app móvil (SSP Key). Cada una genera su propia seed, que respaldas por separado (este es el paso del checklist del primer 1000). Los dos dispositivos intercambian llaves públicas; desde ese punto, comparten una identidad de wallet a nivel de protocolo.
2. En la firma diaria, haces clic en Send en la extensión del navegador, revisas la transacción y apruebas. La extensión construye una transacción parcialmente firmada y empuja una notificación a tu teléfono. La app móvil muestra los detalles de la transacción, tocas aprobar y la app produce la segunda firma. La extensión combina ambas firmas y transmite. Tiempo total: unos 8 segundos cuando ambos dispositivos están frente a ti.
3. Al recibir, la dirección mostrada es la dirección multisig derivada por BIP48 de ambos xpubs. La escaneas o copias; el remitente no ve nada inusual. Desde su lado parece cualquier otra dirección cripto.
4. En el balance, la wallet te muestra saldos, historial, fees, etc., idénticamente a una wallet single-sig. No hay una "pantalla multisig" separada. La forma del protocolo es invisible durante el uso normal.

La elección clave de diseño es que la segunda firma es la única multi-naturaleza en la que el usuario tiene que pensar. La configuración son dos dispositivos, la firma es un toque extra, y esa es toda la superficie del protocolo multisig desde la perspectiva del usuario.

Un detalle pequeño pero importante: la extensión de navegador SSP y SSP Key no están co-ubicadas. Están en distintos OS, distinto hardware, distintas superficies de ataque. Esto es lo que hace que la configuración de dos firmas sea una barrera real contra el robo y no solo un bache de UX. (Lo desempaquetamos en la pieza de siete modos de fallo y en Qué es 2-of-2 multisig.)

Lo que el usuario nunca ve

Mucho trabajo va en mantener al usuario lejos de tener que manejar la plomería multisig. Específicamente:

• PSBT (Partially Signed Bitcoin Transactions) son las estructuras de datos voluminosas que se mueven entre los dispositivos cofirmantes. En un setup multisig tradicional las copias y pegas manualmente. SSP las serializa y transmite por su propio canal de coordinación; el usuario ve una notificación, no una cadena base64.
• El intercambio de xpubs de cosigner es un evento único de configuración. En multisig tradicional, importas xpubs de cada cosigner explícitamente. SSP lo envuelve en el flujo de emparejamiento al configurar; confirmas un código QR o un código de seis dígitos y nunca tocas el material subyacente.
• Estimación de fees, manejo de cambio y rotación de direcciones los maneja la wallet exactamente como lo hacen las wallets single-sig, a pesar de que la wallet misma es multisig por debajo.
• El redeem script — el script BIP48-canónico que describe la regla multisig — lo construye la wallet automáticamente. Los usuarios no lo ven, no lo aprueban línea por línea, no necesitan saber que existe. (Pueden verlo en un explorador de bloques si miran, lo cual es la propiedad "mostrar tu trabajo" más limpia de las wallets multisig.)

Toda esa abstracción es trabajo necesario, pero también es el riesgo — cada vez que el protocolo se oculta del usuario, la wallet asume la responsabilidad de hacer bien la parte oculta. El trabajo de auditoría de SSP (Halborn) trata en gran medida exactamente sobre estas rutas de código invisibles.

Cuándo deja de sentirse single-signer

La abstracción no es perfecta, y es importante saber dónde se rompe. La UX single-signer aguanta mientras ambos dispositivos estén disponibles. Las grietas aparecen cuando uno no lo está:

• Reemplazo de dispositivo. Cuando cambias de teléfono, el nuevo dispositivo tiene que volver a emparejarse. Es un paso de coordinación multisig único que sí es visible — la wallet te guía mostrando ambos dispositivos uno al otro de nuevo.
• Recuperación de seed. Si un dispositivo es destruido, lo recuperas desde su seed phrase en un dispositivo nuevo, luego re-emparejas. El hecho de que tienes dos seeds (una por dispositivo) se vuelve visible en este momento de una manera que no lo era durante el uso normal.
• Recuperación cross-software. Si alguna vez cargas tus dos seeds SSP en una wallet multisig de terceros (Sparrow, Electrum, etc.), toda la plomería multisig se vuelve visible — eso es una feature, no un bug, porque es lo que prueba que tu wallet es interoperable, pero no es la UX de SSP.
• Gastar cuando un dispositivo está offline. La wallet no puede cofirmar sin ambos dispositivos; eso es el protocolo. Verás un estado "esperando la segunda firma" hasta que el otro dispositivo se conecte.

Los tres primeros son lo suficientemente infrecuentes para no degradar realmente la UX media. El cuarto es el punto de fricción más común — y el punto de fricción correcto. Si la wallet te dejara gastar sin el segundo dispositivo, ya no sería una wallet 2-of-2. Esa fricción es la seguridad; no puedes ingeniarla para que desaparezca sin quitar la propiedad por la que estabas pagando.

Diseñando alrededor de la UX single-signer

Tres principios de diseño que SSP — y otros productos multisig modernos — siguen para mantener esta abstracción ajustada:

1. Los dos cosigners deben vivir en distintas superficies de amenaza. Una wallet que pone ambas llaves cofirmantes en el mismo OS realmente no provee el beneficio de seguridad; solo extiende una sola superficie de ataque sobre dos cerraduras. La división de SSP entre extensión de navegador y app móvil esto lo impone naturalmente.
2. El canal de coordinación debe ser infalsificable. El PSBT que una extensión de navegador envía a la app móvil debe estar criptográficamente vinculado a la wallet correcta y a la transacción correcta; de lo contrario la abstracción se convierte en su propia superficie de ataque. SSP firma y valida este material a nivel de protocolo.
3. El contrato del usuario debe ser honesto sobre lo que se oculta. Wallets que dicen "experiencia single-signer totalmente trustless" sin explicar qué pasa en la recuperación preparan a los usuarios para una sorpresa desagradable. El onboarding de SSP recorre explícitamente ambas seeds, ambos backups y ambos escenarios de recuperación — la abstracción se oculta durante el uso pero se expone durante el onboarding para que no te embosca después.

Las wallets de account abstraction en Ethereum tienen una cuarta herramienta: la capa smart-contract. Con ERC-4337, una wallet puede absorber fees de gas, batchear transacciones y presentar una UX aún más "tipo single-signer" e implementar multisig por debajo. SSP no tiene esa capa en Bitcoin (sin smart contracts), así que la abstracción se apoya más en ingeniería de UX que en absorción chain-side. Ambos caminos son válidos; el de Ethereum es más flexible al coste de ser específico de la chain, el de SSP es más portable al coste de más trabajo de UI.

Qué significa esto para ti

Tres conclusiones:

1. La experiencia "se siente como una sola wallet" es la feature titular, no multisig en sí. Si tu amigo pregunta "¿SSP es una wallet multisig?", la respuesta técnicamente cierta es sí, pero la respuesta útil es "es una wallet de 2 dispositivos donde un toque en el teléfono confirma un gasto". Eso captura lo que la gente realmente siente.
2. La fricción que sí ves está haciendo trabajo real. Cada vez que SSP te pide confirmar en el teléfono, está imponiendo el protocolo que detiene a un laptop comprometido de vaciar tus fondos. Esa fricción es la razón principal por la que estás usando una wallet 2-of-2 en primer lugar en vez de una hot wallet.
3. Trata la abstracción como un contrato, no como magia. El artículo final de esta serie, Modos de fallo multisig y cómo SSP los mitiga, recorre qué pasa cuando cada pieza de la abstracción se rompe — pérdida de dispositivo, compromiso de llave, caída del servidor de firma. Léelo una vez. La abstracción está bien diseñada, pero entender los modos de fallo es lo que te hace el tipo de usuario de self-custody para el que es toda esta serie.