Finora in questa serie abbiamo coperto cos'è multisig e quale soglia scegliere. Entrambi gli articoli descrivevano il comportamento di un wallet multisig — m di n chiavi firmano, la chain controlla la soglia, il denaro si muove. Nessuno diceva molto su come il wallet è effettivamente costruito sotto. Questo è l'articolo che lo fa.
La versione corta: quando SSP crea un wallet per te, non si limita a generare due chiavi casuali e basta. Le genera in un modo che segue uno standard documentato chiamato BIP48, in modo che il wallet risultante sia interoperabile, recuperabile in software diverso da SSP, e prevedibile da ispezionare on-chain. Questo è l'articolo che spiega cos'è BIP48, perché esiste, e perché "questo wallet usa BIP48" è una delle frasi più noiose e importanti del multisig.
TL;DR
- Un percorso di derivazione è la strada da una singola seed phrase a una chiave specifica (e indirizzo) in un wallet. Percorsi standardizzati come BIP44 / BIP48 permettono a software diversi di arrivare alle stesse chiavi dalla stessa seed.
- BIP48 è la spec specifica per i wallet multisig. Dice: ecco il percorso di derivazione canonico per le
mchiavi che compongono un wallet 2-of-3, 3-of-5, ecc., attraverso i principali tipi di script di output. - SSP usa BIP48. Questo significa che le due seed che il tuo wallet SSP ha generato sono usabili da qualsiasi altro wallet compatibile BIP48 (Sparrow, Electrum, i descriptor di Bitcoin Core) — non solo da SSP.
- BIP48 risolve un problema che la spec multisig precedente (BIP45) aveva: separa pulitamente le chiavi per i diversi tipi di script (legacy, P2SH-wrapped SegWit, native SegWit, Taproot) in modo che una singola seed phrase possa tenerle tutte senza collisione.
- Non hai bisogno di gestire manualmente i percorsi di derivazione per usare SSP. Dovresti sapere che esistono in modo che "recupero del wallet" non sembri magia — e per capire a cosa la tua seed corrisponde davvero.
Un tour di 30 secondi dei percorsi di derivazione
Prima che BIP48 avesse alcun significato, la macchineria sottostante doveva esistere. Quella macchineria è BIP32: wallet hierarchical deterministic (HD). L'idea centrale è che una chiave master — derivata da una seed phrase — può produrre un albero infinito di chiavi figlie, in modo deterministico. Percorri un cammino specifico nell'albero e arrivi sempre alla stessa chiave figlia. Percorri uno diverso e arrivi a un'altra.
I percorsi hanno questo aspetto:
m / purpose' / coin_type' / account' / change / index
Per esempio, il percorso BIP44 m / 44' / 0' / 0' / 0 / 0 raggiunge il primo indirizzo di ricezione del primo account di Bitcoin sotto le regole BIP44. Cambia il coin_type in 60' e sei nello spazio Ethereum; cambia il purpose in 84' e sei nello spazio BIP84 (native SegWit); e così via. L'apice (') è la derivazione hardened — il figlio non può essere invertito al padre. Ogni segmento dopo il master è un numero a 32 bit, partizionato per convenzione.
Questa è la parte che si tende a saltare: il percorso è metadata, non un segreto. Chiunque conosca il tuo percorso e la tua chiave privata (o chiave estesa) può derivare gli stessi indirizzi. Il percorso dice al wallet dove guardare. La seed gli dice cosa c'è.
Per un ripasso amichevole su cos'è la seed stessa, il post di seed phrase best practices è il prerequisito.
Cosa specifica BIP48
BIP48 vive a m / 48' / coin_type' / account' / script_type' / change / index. L'aggiunta interessante è script_type' — il penultimo segmento.
Quel segmento codifica quale tipo di output multisig il percorso serve:
0'→ P2SH (multisig legacy)1'→ P2SH-wrapped SegWit (P2WSH-in-P2SH)2'→ native SegWit (P2WSH)3'→ multisig equivalente a Taproot (per emendamenti BIP48)
Questo conta perché in pratica lo stesso insieme di cosigner m-of-n produce indirizzi diversi on-chain a seconda di quale script di output viene usato. Senza BIP48, un wallet potrebbe usare silenziosamente un tipo, il software di recupero assumerne un altro, e il risultato sono due wallet che sembrano dovrebbero derivare le stesse monete — ma non lo fanno, perché stanno calcolando indirizzi diversi.
BIP48 fissa anche il segmento purpose' a 48', quindi i percorsi multisig non possono collidere con i percorsi single-sig BIP44/BIP49/BIP84. Una seed può contenere un wallet single-sig a BIP84 e un wallet multisig 2-of-2 a BIP48, senza interferenza. Ciascuno vive nel proprio sottoalbero.
Oltre al percorso stesso, BIP48 specifica come le chiavi pubbliche dei cosigner ("xpub") devono essere ordinate quando si costruisce l'output multisig. La regola canonica è ordinamento lessicografico delle chiavi pubbliche prima di entrare nel redeem script. Questo rimuove l'ambiguità — ogni wallet conforme a BIP48 che costruisce dagli stessi xpub calcola lo stesso indirizzo. Senza quella regola, due wallet potrebbero combinare le stesse chiavi in ordini diversi e finire a indirizzi diversi con la stessa regola di redeem.
Se vuoi leggere la spec letterale, vive nel repo Bitcoin BIPs (bips/bip-0048.mediawiki).
Come SSP usa BIP48 in pratica
Quando configuri un wallet SSP, vengono generate due seed phrase — una sull'estensione del browser, una sull'app mobile SSP Key. Ogni seed phrase corrisponde a una chiave privata master. Da ogni master, SSP deriva il percorso BIP48 per la chain rilevante (Bitcoin, Ethereum, Flux e il resto del set supportato da SSP) a script_type' = 2' (native SegWit su Bitcoin; forme canoniche equivalenti sulle altre chain dove applicabile).
Gli xpub di entrambi i firmatari vengono poi scambiati. Ogni lato ha ora lo stesso set di due xpub, ordinati lessicograficamente per BIP48. Da quella coppia, ogni lato calcola indipendentemente lo stesso indirizzo. Le due metà non condividono mai una chiave privata — solo le chiavi pubbliche si muovono tra i dispositivi.
Quando ricevi denaro, l'indirizzo mostrato è l'indirizzo derivato BIP48 calcolato da entrambi gli xpub. Quando spendi, ogni dispositivo firma la stessa transazione con la propria chiave privata. Il redeem script on-chain riferimenti entrambe le chiavi pubbliche; la rete controlla entrambe le firme. Questo è tutto il protocollo.
Il motivo per cui questo conta in uno scenario di recupero: se SSP, come prodotto, sparisse domani, tu avresti ancora due seed phrase conformi a BIP48. Caricare entrambe in Sparrow (o in qualsiasi altro wallet capace di multisig che supporti i percorsi BIP48 che SSP usa) ricostruisce lo stesso wallet, agli stessi indirizzi, con piena capacità di spesa. Il wallet non vive dentro SSP — vive on-chain, e le seed più la spec BIP48 bastano per raggiungerlo da qualsiasi luogo.
Questa proprietà è gran parte del perché il pezzo self-custody-without-cold-storage tratta un wallet SSP 2-of-2 come un wallet serio anziché come una curiosità dal sapore custodial. È recuperabile da standard aperti.
Perché BIP48 sopra BIP45 (e non BIP44)
La spec multisig precedente era BIP45. Era un primo tentativo onesto: m / 45' / cosigner_index' / change / index, con cosigner_index' che codifica quale cosigner sei nel wallet. In retrospettiva aveva due problemi.
Primo, cosigner_index' cuociva un ordine nel percorso stesso. Questo voleva dire che l'ordine in cui i firmatari venivano aggiunti influiva sulla derivazione, il che rendeva fragile il setup congiunto — sbagli l'ordine e derivi indirizzi diversi dal tuo cosigner. BIP48 risolve questo rimuovendo del tutto il cosigner index dal percorso e lasciando che l'ordinamento lessicografico delle chiavi pubbliche se ne occupi.
Secondo, BIP45 non separava per tipo di script. Lo stesso percorso sarebbe stato riusato sia che il wallet usasse multisig P2SH legacy o multisig SegWit-wrapped. Questo creava lo stesso problema di collisione-di-indirizzi-ma-non-le-stesse-monete descritto sopra.
BIP44, la spec HD più generale, non ha mai preteso di coprire il multisig. Sovraccaricare BIP44 con percorsi multisig creava i propri conflitti. BIP48 è stata la correzione esplicita: un purpose number dedicato, uno slot di script-type esplicito e un ordinamento deterministico delle chiavi. Oggi la maggior parte dei wallet multisig moderni converge su di esso; è lo standard de facto.
Per la storia più profonda di come questo si collega al prossimo capitolo del multisig — l'aggregazione Schnorr, in cui più firme si comprimono in una — il prossimo articolo di questa serie, Schnorr signatures and multisig aggregation, riprende il filo.
Cosa significa questo per l'interoperabilità
Il test più pulito di "questo wallet multisig è davvero self-custodial?" è: posso recuperarlo senza il software del wallet? Se la risposta è sì — usando seed documentate, un percorso di derivazione documentato e strumenti standard — il wallet è genuinamente tuo. Se la risposta è no, il wallet ha elementi custodial nascosti.
La conformità di SSP a BIP48 è ciò che ci permette di rispondere sì. Le seed phrase sono BIP39 (mnemonico standard), la derivazione è BIP48, la costruzione di indirizzo è canonica BIP48. Qualsiasi wallet che parli gli stessi standard può ricostruire il wallet.
Per questo l'introduzione Meet SSP Wallet inquadra SSP come "self-custody con multisig 2-of-2" anziché come un servizio gestito. Gli standard sotto sono la ragione per cui quell'inquadramento è onesto.
Cosa significa questo per te
Tre conclusioni:
- Non devi memorizzare i percorsi per usare SSP. Il numero
m/48'/0'/0'/2'/0/0non è qualcosa che un utente normale dovrebbe mai digitare. Ma sapere che esiste è ciò che rende "posso recuperare questo wallet senza SSP" un'affermazione reale invece che marketing. - Le tue due seed sono interoperabili. Se un giorno ti serve recuperare in un wallet multisig di terze parti, BIP48 più le tue due seed BIP39 più il
coin_typedella chain è la ricetta. Il checklist di self-custody nomina questo come passo di prova per una ragione. - Un wallet multisig che non usa BIP48 (o simili) merita di essere messo in discussione. Se un prodotto non può dirti esattamente come gli indirizzi sono derivati dalle tue chiavi, non è self-custody — è custodia con passaggi extra. La conformità agli standard è ciò che rende verificabile l'affermazione "le tue chiavi, le tue monete".
