Multisig single-signer : comment SSP fait que deux appareils ressemblent à un portefeuille

Si vous suivez cette série depuis ce qu'est le multisig, vous connaissez le protocole : plus d'une clé privée doit signer avant que l'argent ne bouge. Vous avez vu le sélecteur m-of-n, le câblage BIP48, l'horizon d'agrégation Schnorr, et la comparaison avec la social-recovery. Tout cela, c'est la mécanique. Cet article porte sur l'expérience.

La critique historique honnête du multisig, c'est qu'il a été hostile à l'usage. Plusieurs portefeuilles, échange manuel de PSBT, logiciel coordinateur, séances de signature — le protocole était solide, mais l'UX était une punition. Single-signer multisig est l'idée de produit qui répare ça : un portefeuille qui utilise une règle de dépense multisig complète on-chain, mais qui se ressent — pour la personne qui l'utilise — comme un seul portefeuille avec un seul bouton. SSP est bâti autour de cette idée.

TL;DR

• « Single-signer » ne signifie pas une clé. Cela signifie que le protocole a toujours m clés sur n, mais que l'UX de signature est ramassée en un seul flux. L'utilisateur signe à un seul endroit ; le portefeuille gère la coordination entre appareils.
• La forme spécifique de SSP : une extension de navigateur, une app mobile (SSP Key), une identité de portefeuille. Vous cliquez sur Send, vous confirmez sur le téléphone, la transaction est diffusée. Deux signatures ont lieu ; vous en vivez une.
• Le gain, c'est que le bénéfice de seuil (résistance au vol, pas de point unique de défaillance) est préservé pendant que le coût de coordination tombe presque au niveau de l'UX single-sig.
• Le coût, c'est que ça ne marche qu'aussi longtemps que vos deux appareils sont atteignables. Dès que l'UX doit exposer la multi-itude — récupération, remplacement d'appareil, restauration chez un tiers — l'abstraction casse, par design.
• Ce schéma est ce qui se rapproche le plus d'une réponse « sans compromis » à la self-custody solo à l'échelle retail. C'est le pari de SSP, et de plus en plus le pari de tout produit multisig moderne (Coinbase Wallet, l'histoire de custody en évolution de Phantom, le flux smart-account de Safe sur Ethereum).

L'idéal single-signer : ce que les utilisateurs veulent vraiment

Si on demande à un utilisateur de self-custody ce qu'il veut, on obtient des réponses qui se contredisent :

• « Je veux mes pièces en sécurité. » — Implique multisig, hardware, redondance.
• « Je veux signer une transaction en cinq secondes. » — Implique un seul appareil, un tap.
• « Je veux pouvoir récupérer si je perds quelque chose. » — Implique des backups de seed, de la redondance.
• « Je ne veux plus jamais écrire de seed. » — Implique de la custody de clé gérée par plateforme.
• « Je veux que ce soit bon marché. » — Implique une empreinte on-chain minimale.

Ces objectifs ne s'alignent pas tous. L'histoire du design des portefeuilles self-custody, c'est l'histoire des objectifs à honorer et de ceux qu'on doit poliment refuser. Les hardware wallets honorent sécurité et récupération au prix de l'UX. Les portefeuilles smart-contract honorent UX et récupération au prix de la portée cross-chain. Les hot wallets purs honorent UX et bon marché au prix de la sécurité.

Single-signer multisig est une tentative d'honorer les cinq — partiellement — en séparant la sémantique de protocole de la sémantique d'interface. Le portefeuille fait toujours la danse multisig complète on-chain ; l'utilisateur n'a juste plus à y participer plus d'une fois par transaction.

Comment SSP livre ça

L'implémentation concrète de SSP, en clair :

1. À la configuration, vous installez l'extension de navigateur et l'app mobile (SSP Key). Chacune génère sa propre seed, que vous sauvegardez séparément (c'est l'étape de la check-list des 1000 premiers). Les deux appareils échangent leurs clés publiques ; à partir de ce moment, ils partagent une identité de portefeuille au niveau du protocole.
2. À la signature quotidienne, vous cliquez sur Send dans l'extension de navigateur, vous revoyez la transaction et vous approuvez. L'extension construit une transaction partiellement signée et pousse une notification sur votre téléphone. L'app mobile affiche les détails de la transaction, vous tapez approuver, et l'app produit la seconde signature. L'extension combine les deux signatures et diffuse. Temps total écoulé : environ 8 secondes quand les deux appareils sont devant vous.
3. À la réception, l'adresse affichée est l'adresse multisig dérivée par BIP48 des deux xpubs. Vous la scannez ou copiez ; l'expéditeur ne voit rien d'inhabituel. De son côté ça ressemble à n'importe quelle autre adresse crypto.
4. Au règlement, le portefeuille vous affiche soldes, historique, frais, etc., à l'identique d'un portefeuille single-sig. Il n'y a pas d'« écran multisig » séparé. La forme du protocole est invisible en usage normal.

Le choix de design clé, c'est que la seconde signature est la seule multi-itude à laquelle l'utilisateur a à penser. La configuration, c'est deux appareils ; la signature, un tap supplémentaire ; et ça, c'est toute la surface du protocole multisig du point de vue utilisateur.

Un détail petit mais important : l'extension de navigateur SSP et SSP Key ne sont pas co-localisées. Elles sont sur des OS différents, du hardware différent, des surfaces d'attaque différentes. C'est ce qui fait que la configuration à deux signatures est une vraie barrière au vol et pas juste un dos-d'âne d'UX. (On le décortique dans la pièce sur les sept modes de défaillance et dans Qu'est-ce que le multisig 2-of-2.)

Ce que l'utilisateur ne voit jamais

Beaucoup de travail va à tenir l'utilisateur loin de la plomberie multisig. Concrètement :

• PSBT (Partially Signed Bitcoin Transactions) sont les structures de données costaudes qui circulent entre les appareils cosignataires. Dans un setup multisig traditionnel, on les copie-colle à la main. SSP les sérialise et les transmet via son propre canal de coordination ; l'utilisateur voit une notification, pas une chaîne base64.
• L'échange de xpubs cosigner est un événement de configuration unique. En multisig traditionnel, on importe les xpubs de chaque cosigner explicitement. SSP enveloppe ça dans le flux d'appairage à la configuration ; vous confirmez un QR code ou un code à six chiffres et ne touchez jamais le matériau sous-jacent.
• L'estimation des frais, la gestion du change et la rotation d'adresse sont prises en charge par le portefeuille exactement comme un portefeuille single-sig, bien que le portefeuille lui-même soit multisig sous le capot.
• Le redeem script — le script BIP48-canonique décrivant la règle multisig — est construit automatiquement par le portefeuille. Les utilisateurs ne le voient pas, ne l'approuvent pas ligne à ligne, n'ont pas besoin de savoir qu'il existe. (Ils peuvent le voir sur un block explorer s'ils regardent, c'est la propriété « montrez votre travail » la plus propre des portefeuilles multisig.)

Toute cette abstraction est du travail nécessaire, mais c'est aussi le risque — chaque fois que le protocole est caché à l'utilisateur, le portefeuille assume la responsabilité de bien faire la partie cachée. Le travail d'audit de SSP (Halborn) porte largement précisément sur ces chemins de code invisibles.

Quand ça cesse de paraître single-signer

L'abstraction n'est pas parfaite, et il faut savoir où elle casse. L'UX single-signer tient tant que les deux appareils sont disponibles. Les fissures apparaissent quand l'un ne l'est pas :

• Remplacement d'appareil. Quand vous changez de téléphone, le nouvel appareil doit être réappairé. C'est une étape de coordination multisig ponctuelle qui est réellement visible — le portefeuille vous guide en montrant à nouveau les deux appareils l'un à l'autre.
• Récupération de seed. Si un appareil est détruit, vous le récupérez depuis sa seed phrase sur un nouvel appareil, puis ré-appairez. Le fait que vous ayez deux seeds (une par appareil) devient visible à ce moment-là d'une manière qui ne l'était pas en usage normal.
• Récupération cross-software. Si vous chargez un jour vos deux seeds SSP dans un portefeuille multisig tiers (Sparrow, Electrum, etc.), toute la plomberie multisig devient visible — c'est une feature, pas un bug, parce que c'est ce qui prouve que votre portefeuille est interopérable, mais ce n'est pas l'UX SSP.
• Dépenser quand un appareil est hors-ligne. Le portefeuille ne peut pas cosigner sans les deux appareils ; c'est le protocole. Vous verrez un état « en attente de la seconde signature » jusqu'à ce que l'autre appareil revienne en ligne.

Les trois premiers sont assez peu fréquents pour ne pas vraiment dégrader l'UX moyenne. Le quatrième est le point de friction le plus courant — et le point de friction correct. Si le portefeuille vous laissait dépenser sans le second appareil, ce ne serait plus un portefeuille 2-of-2. Cette friction, c'est la sécurité ; vous ne pouvez pas l'éliminer par l'ingénierie sans supprimer la propriété pour laquelle vous payez.

Concevoir autour de l'UX single-signer

Trois principes de design que SSP — et d'autres produits multisig modernes — suivent pour garder cette abstraction serrée :

1. Les deux cosigners doivent vivre dans des surfaces de menace différentes. Un portefeuille qui place les deux clés cosignataires sur le même OS ne fournit pas vraiment le bénéfice de sécurité ; il étale juste une seule surface d'attaque sur deux verrous. La séparation SSP entre extension de navigateur et app mobile l'impose naturellement.
2. Le canal de coordination doit être infalsifiable. Le PSBT qu'une extension de navigateur envoie à l'app mobile doit être cryptographiquement lié au bon portefeuille et à la bonne transaction ; sinon l'abstraction devient sa propre surface d'attaque. SSP signe et valide ce matériau au niveau protocole.
3. Le contrat utilisateur doit être honnête sur ce qui est caché. Les portefeuilles qui annoncent une « expérience single-signer totalement trustless » sans expliquer ce qui se passe à la récupération préparent les utilisateurs à une mauvaise surprise. L'onboarding SSP parcourt explicitement les deux seeds, les deux backups et les deux scénarios de récupération — l'abstraction est cachée pendant l'usage mais exposée pendant l'onboarding pour ne pas vous embusquer plus tard.

Les portefeuilles d'account abstraction sur Ethereum disposent d'un quatrième outil : la couche smart-contract. Avec ERC-4337, un portefeuille peut absorber les frais de gas, batcher des transactions et présenter une UX encore plus « single-signer » tout en implémentant le multisig dessous. SSP n'a pas cette couche sur Bitcoin (pas de smart contracts), donc l'abstraction s'appuie davantage sur l'ingénierie UX que sur l'absorption côté chaîne. Les deux voies sont valides ; celle d'Ethereum est plus flexible au prix d'être spécifique à la chaîne, celle de SSP est plus portable au prix de plus de travail UI.

Ce que ça signifie pour vous

Trois conclusions :

1. L'expérience « ressemble à un seul portefeuille » est la feature phare, pas le multisig en lui-même. Si votre ami demande « SSP est un portefeuille multisig ? », la réponse techniquement vraie est oui, mais la réponse utile est « c'est un portefeuille à 2 appareils où un tap sur le téléphone confirme une dépense ». C'est ça que les gens ressentent vraiment.
2. La friction que vous voyez bel et bien fait un vrai travail. Chaque fois que SSP vous demande de confirmer sur le téléphone, il applique le protocole qui empêche un laptop compromis de vider vos fonds. Cette friction est la raison principale pour laquelle vous utilisez un portefeuille 2-of-2 plutôt qu'un hot wallet au départ.
3. Traitez l'abstraction comme un contrat, pas comme de la magie. Le dernier article de cette série, Modes de défaillance multisig et comment SSP les atténue, parcourt ce qui se passe quand chaque pièce de l'abstraction casse — perte d'appareil, compromission de clé, panne du serveur de signature. Lisez-le une fois. L'abstraction est bien faite, mais comprendre les modes de défaillance, c'est ce qui fait de vous le genre d'utilisateur de self-custody pour qui cette série a été écrite.