Se sei stato con questa serie da cos'è multisig, conosci il protocollo: più di una chiave privata deve firmare prima che il denaro si muova. Hai visto il selettore m-of-n, il cablaggio BIP48, l'orizzonte dell'aggregazione Schnorr, e il confronto con social-recovery. Tutto questo è la meccanica. Questo articolo riguarda l'esperienza.
La critica storica onesta al multisig è che è stato ostile da usare. Wallet multipli, scambio manuale di PSBT, software coordinatore, feste di firma — il protocollo era solido, ma la UX era una punizione. Single-signer multisig è l'idea di prodotto che ripara questo: un wallet che usa una regola di spesa multisig completa on-chain, ma si sente — per la persona che lo usa — come un singolo wallet con un singolo pulsante. SSP è costruito attorno a questa idea.
TL;DR
- "Single-signer" non significa una chiave. Significa che il protocollo ha ancora
mdinchiavi, ma la UX di firma è collassata in un singolo flusso. L'utente firma in un posto; il wallet gestisce il coordinamento dispositivo-dispositivo. - La forma specifica di SSP: un'estensione del browser, una app mobile (SSP Key), un'identità di wallet. Clicchi Send, confermi sul telefono, la transazione viene trasmessa. Due firme accadono; ne vivi una.
- La vittoria è che il beneficio di soglia (resistenza al furto, nessun single-point-of-failure) è preservato mentre il costo di coordinamento scende vicino alla UX single-sig.
- Il costo è che questo funziona solo finché entrambi i tuoi dispositivi sono raggiungibili. Nel momento in cui la UX deve esporre la multi-ità — recupero, sostituzione di dispositivo, ripristino su terzi — l'astrazione si rompe, per design.
- Questo pattern è la cosa più vicina a una risposta "senza compromessi" per la self-custody solo a scala retail. È la scommessa di SSP, e sempre più la scommessa di ogni prodotto multisig moderno (Coinbase Wallet, la storia di custody in evoluzione di Phantom, il flusso smart-account di Safe su Ethereum).
L'ideale single-signer: cosa vogliono davvero gli utenti
Se chiedi a un utente self-custody cosa vuole, ottieni risposte che si contraddicono:
- "Voglio le mie monete al sicuro." — Implica multisig, hardware, ridondanza.
- "Voglio firmare una transazione in cinque secondi." — Implica un singolo dispositivo, un tocco.
- "Voglio recuperare se perdo qualcosa." — Implica backup di seed, ridondanza.
- "Non voglio mai più scrivere una seed." — Implica custody di chiave gestita da piattaforma.
- "Voglio che sia economico." — Implica un'impronta on-chain minima.
Questi obiettivi non si allineano tutti. La storia del design dei wallet self-custody è la storia di quali obiettivi onorare e quali rifiutare educatamente. I wallet hardware onorano sicurezza e recupero al costo della UX. I wallet smart-contract onorano UX e recupero al costo della portata cross-chain. I wallet puramente hot onorano UX ed economicità al costo della sicurezza.
Single-signer multisig è un tentativo di onorare tutti e cinque — parzialmente — separando la semantica del protocollo dalla semantica dell'interfaccia. Il wallet continua a fare la danza multisig completa on-chain; l'utente semplicemente non deve partecipare a quella danza più di una volta per transazione.
Come SSP lo consegna
L'implementazione specifica di SSP, in italiano semplice:
- Al setup, installi l'estensione del browser e la app mobile (SSP Key). Ciascuna genera la propria seed, di cui fai backup separatamente (questo è il passo del checklist dei primi 1000). I due dispositivi si scambiano chiavi pubbliche; da quel punto in poi, condividono un'identità di wallet a livello protocollo.
- Alla firma quotidiana, clicchi Send nell'estensione del browser, controlli la transazione e approvi. L'estensione costruisce una transazione parzialmente firmata e spinge una notifica al tuo telefono. L'app mobile mostra i dettagli della transazione, tocchi approva, e l'app produce la seconda firma. L'estensione combina entrambe le firme e trasmette. Tempo totale: circa 8 secondi quando entrambi i dispositivi sono davanti a te.
- Alla ricezione, l'indirizzo mostrato è l'indirizzo multisig derivato da BIP48 da entrambi gli xpubs. Lo scansioni o copi; il mittente non vede nulla di insolito. Dal suo lato sembra qualsiasi altro indirizzo cripto.
- All'accredito, il wallet ti mostra saldi, cronologia, fee e così via, identicamente a un wallet single-sig. Non c'è una "schermata multisig" separata. La forma del protocollo è invisibile durante l'uso normale.
La scelta di design chiave è che la seconda firma è la sola multi-ità a cui l'utente deve mai pensare. Setup sono due dispositivi, firma è un tocco extra, e quella è l'intera superficie del protocollo multisig dal punto di vista dell'utente.
Un dettaglio piccolo ma importante: l'estensione del browser SSP e SSP Key non sono co-localizzate. Sono su OS diversi, hardware diverso, superfici di attacco diverse. È questo che fa del setup a due firme una barriera reale al furto e non solo un dosso UX. (Lo sviluppiamo nel pezzo sui sette modi di fallimento e in Cos'è multisig 2-of-2.)
Cosa l'utente non vede mai
Molto lavoro va nel tenere l'utente lontano dal dover maneggiare l'idraulica multisig. Specificamente:
- PSBT (Partially Signed Bitcoin Transactions) sono le strutture dati corpose che si muovono tra i dispositivi cofirmanti. In un setup multisig tradizionale le copi e incolli manualmente. SSP le serializza e trasmette sul proprio canale di coordinamento; l'utente vede una notifica, non una stringa base64.
- Lo scambio di xpubs di cosigner è un evento di setup una tantum. In multisig tradizionale, importi xpubs da ciascun cosigner esplicitamente. SSP avvolge questo nel flusso di pairing al setup; confermi un QR code o un codice a sei cifre e non tocchi mai il materiale sottostante.
- Stima delle fee, gestione del resto e rotazione degli indirizzi sono gestite dal wallet esattamente come i wallet single-sig fanno, nonostante il wallet stesso sia multisig sotto il cofano.
- Il redeem script — lo script BIP48-canonico che descrive la regola multisig — è costruito automaticamente dal wallet. Gli utenti non lo vedono, non lo approvano riga per riga, non hanno bisogno di sapere che esiste. (Possono vederlo su un block explorer se guardano, che è la più pulita proprietà "mostra il tuo lavoro" dei wallet multisig.)
Tutta quell'astrazione è lavoro necessario, ma è anche il rischio — ogni volta che il protocollo è nascosto all'utente, il wallet si assume la responsabilità di fare bene la parte nascosta. Il lavoro di audit di SSP (Halborn) è in gran parte proprio su questi percorsi di codice invisibili.
Quando smette di sentirsi single-signer
L'astrazione non è perfetta, ed è importante sapere dove si rompe. La UX single-signer regge mentre entrambi i dispositivi sono disponibili. Le crepe compaiono quando uno non lo è:
- Sostituzione del dispositivo. Quando cambi telefono, il nuovo dispositivo deve essere ri-accoppiato. È un passo di coordinamento multisig una tantum che è davvero visibile — il wallet ti guida mostrando di nuovo entrambi i dispositivi l'uno all'altro.
- Recupero da seed. Se un dispositivo è distrutto, lo recuperi dalla sua seed phrase su un nuovo dispositivo, poi ri-accoppi. Il fatto che hai due seed (una per dispositivo) diventa visibile in questo momento in un modo che non lo era durante l'uso normale.
- Recupero cross-software. Se un giorno carichi le tue due seed SSP in un wallet multisig di terze parti (Sparrow, Electrum, ecc.), tutta l'idraulica multisig diventa visibile — è una feature, non un bug, perché è ciò che prova che il tuo wallet è interoperabile, ma non è la UX SSP.
- Spendere quando un dispositivo è offline. Il wallet non può cofirmare senza entrambi i dispositivi; quello è il protocollo. Vedrai uno stato "in attesa della seconda firma" finché l'altro dispositivo non torna online.
I primi tre sono abbastanza infrequenti da non degradare davvero la UX media. Il quarto è il punto di attrito più comune — e il punto di attrito corretto. Se il wallet ti lasciasse spendere senza il secondo dispositivo, non sarebbe più un wallet 2-of-2. Quell'attrito è la sicurezza; non puoi ingegnerizzarlo via senza rimuovere la proprietà per cui stavi pagando.
Progettare attorno alla UX single-signer
Tre principi di design che SSP — e altri prodotti multisig moderni — seguono per mantenere stretta questa astrazione:
- I due cosigner devono vivere su superfici di minaccia diverse. Un wallet che mette entrambe le chiavi cofirmanti sullo stesso OS non sta davvero fornendo il beneficio di sicurezza; sta solo spalmando una singola superficie d'attacco su due serrature. La divisione di SSP tra estensione del browser e app mobile lo impone naturalmente.
- Il canale di coordinamento deve essere non falsificabile. Il PSBT che un'estensione di browser invia all'app mobile deve essere crittograficamente legato al wallet giusto e alla transazione giusta; altrimenti l'astrazione diventa la sua stessa superficie d'attacco. SSP firma e valida questo materiale a livello protocollo.
- Il contratto con l'utente deve essere onesto su ciò che è nascosto. I wallet che dicono "esperienza single-signer totalmente trustless" senza spiegare cosa succede al recupero preparano gli utenti a una brutta sorpresa. L'onboarding di SSP percorre esplicitamente entrambe le seed, entrambi i backup ed entrambi gli scenari di recupero — l'astrazione è nascosta durante l'uso ma esposta durante l'onboarding per non sorprenderti dopo.
I wallet di account abstraction su Ethereum hanno un quarto strumento: lo strato smart-contract. Con ERC-4337, un wallet può assorbire le fee del gas, batchare transazioni e presentare una UX ancora più "single-signer-like" e implementare multisig sotto il cofano. SSP non ha quello strato su Bitcoin (niente smart contract), quindi l'astrazione si appoggia di più all'ingegneria UX che all'assorbimento chain-side. Entrambi i percorsi sono validi; quello Ethereum è più flessibile al costo di essere specifico della chain, quello SSP è più portabile al costo di più lavoro di UI.
Cosa significa questo per te
Tre conclusioni:
- L'esperienza "sembra un wallet solo" è la feature in prima pagina, non il multisig in sé. Se un tuo amico chiede "SSP è un wallet multisig?", la risposta tecnicamente vera è sì, ma la risposta utile è "è un wallet a 2 dispositivi dove un tocco sul telefono conferma una spesa". Quello cattura ciò che la gente sente davvero.
- L'attrito che vedi sta facendo lavoro reale. Ogni volta che SSP ti chiede di confermare sul telefono, sta applicando il protocollo che impedisce a un laptop compromesso di svuotarti i fondi. Quell'attrito è la ragione principale per cui stai usando un wallet 2-of-2 anziché un hot wallet in primo luogo.
- Tratta l'astrazione come un contratto, non come magia. L'articolo finale di questa serie, Modi di fallimento multisig e come SSP li mitiga, percorre cosa succede quando ogni pezzo dell'astrazione si rompe — perdita di dispositivo, compromissione di chiave, outage del server di firma. Leggilo una volta. L'astrazione è ben progettata, ma capire i modi di fallimento è ciò che ti rende il tipo di utente self-custody per cui esiste tutta questa serie.
