Wallet

Un portafoglio Bitcoin può fare riferimento a un programma wallet o a un file wallet.

I programmi wallet creano chiavi pubbliche per ricevere satoshi e utilizzano le chiavi private corrispondenti per spendere quei satoshi. I file wallet memorizzano le chiavi private e (facoltativamente) altre informazioni relative alle transazioni per il programma wallet.

I programmi wallet e i file wallet sono trattati di seguito in sottosezioni separate e questo documento cerca di rendere sempre chiaro se stiamo parlando di programmi wallet o di file wallet.

Programmi di Wallet

Consentire la ricezione e la spesa di satoshi è l'unica caratteristica essenziale del software wallet, ma un particolare programma di wallet non ha bisogno di fare entrambe le cose. Due programmi wallet possono funzionare insieme, un programma che distribuisce chiavi pubbliche per ricevere satoshi e un altro programma che firma le transazioni spendendo quei satoshi.

I programmi wallet devono anche interagire con la rete peer-to-peer per ottenere informazioni dalla catena di blocchi e per trasmettere nuove transazioni. Tuttavia, i programmi che distribuiscono chiavi pubbliche o firmano transazioni non devono necessariamente interagire con la rete peer-to-peer.

Nota: parliamo genericamente di distribuire le chiavi pubbliche. In molti casi, gli hash P2PKH o P2SH verranno distribuiti al posto delle chiavi pubbliche, con le chiavi pubbliche effettive distribuite solo quando gli output che controllano vengono spesi.

Portafogli Full-Service

Il portafoglio più semplice è un programma che svolge tutte e tre le funzioni: genera chiavi private, ricava le chiavi pubbliche corrispondenti, aiuta a distribuire quelle chiavi pubbliche secondo necessità, monitora gli output spesi per quelle chiavi pubbliche, crea e firma le transazioni spendendo tali output e trasmette le transazioni firmate.

Il vantaggio principale dei portafogli full-service è che sono facili da usare. Un singolo programma fa tutto ciò che l'utente necessità per ricevere e spendere satoshi.

Lo svantaggio principale dei portafogli full-service è che memorizzano le chiavi private su un dispositivo connesso a Internet. La violazione di tali dispositivi è un evento comune e una connessione Internet facilita la trasmissione di chiavi private da un dispositivo compromesso a un utente malintenzionato.

Per proteggere dal furto, molti programmi di portafoglio offrono agli utenti la possibilità di crittografare i file del portafoglio che contengono le chiavi private. Questo protegge le chiavi private quando non vengono utilizzate, ma non può proteggere da un attacco progettato per acquisire la chiave crittografica o per leggere le chiavi decodificate dalla memoria.

Portafogli Signing-Only

Per aumentare la sicurezza, le chiavi private possono essere generate e archiviate da un programma wallet separato che opera in un ambiente più sicuro. Questi programmi “di sola firma” funzionano in combinazione con un portafoglio in rete che interagisce con la rete peer-to-peer.

I programmi in genere utilizzano la creazione di chiavi deterministiche (descritta in una sottosezione successiva) per creare chiavi private e pubbliche principali che possono creare chiavi private e pubbliche secondarie.

Alla prima esecuzione, il portafoglio di sola firma crea una chiave privata genitore e trasferisce la chiave pubblica corrispondente al portafoglio in rete.

Il wallet in rete utilizza la chiave pubblica padre per ricavare chiavi pubbliche secondarie, opzionalmente aiuta a distribuirle, monitora gli output spesi per quelle chiavi pubbliche, crea transazioni non firmate spendendo tali output e trasferisce le transazioni senza firma al portafoglio di sola firma.

Spesso agli utenti viene data la possibilità di rivedere i dettagli delle transazioni non firmate (in particolare i dettagli di output) utilizzando il portafoglio di sola firma.

Dopo la fase di revisione facoltativa, il portafoglio di sola firma utilizza la chiave privata padre per derivare le chiavi private secondarie appropriate e firma le transazioni, restituendo le transazioni firmate al portafoglio in rete.

Il portafoglio in rete trasmette quindi le transazioni firmate alla rete peer-to-peer.

Le seguenti sottosezioni descrivono le due varianti più comuni di portafogli Signing-Only: portafogli offline e portafogli hardware.

Portafogli offline

Diversi programmi portafogli full-service fungono anche da due portafogli separati: un'istanza di programma che funge da portafoglio di sola firma (spesso chiamato "portafoglio offline") e l'altra istanza di programma che funge da portafoglio in rete (spesso chiamato "portafoglio online" o "watching-only wallet").

Il portafoglio offline è così chiamato perché è concepito per essere eseguito su un dispositivo che non si connette a nessuna rete, riducendo notevolmente il numero di vettori di attacco. Se questo è il caso, di solito è l'utente a gestire tutti i trasferimenti di dati utilizzando supporti rimovibili come le unità USB.

L’iter di lavoro dell'utente è simile al seguente:

(Offline) Disabilita tutte le connessioni di rete su un dispositivo e installa il software wallet. Avvia il software wallet in modalità offline per creare le chiavi private e pubbliche padre. Copia la chiave pubblica padre su un supporto rimovibile.

(Online) Installa il software del wallet su un altro dispositivo, questo connesso a Internet, e importa la chiave pubblica del genitore dal supporto rimovibile. Come con un portafoglio completo, ricava le chiavi pubbliche per ricevere i pagamenti. Quando è pronto a spendere satoshi, inserisce i dettagli di output e salva la transazione non firmata generata dal wallet su un supporto rimovibile.

(Offline) Apre la transazione non firmata nell'istanza offline, esamina i dettagli di output per assicurarsi che mostri l'importo corretto per l'indirizzo corretto. Ciò impedisce al malware sul portafoglio online di ingannare l'utente nella firma di una transazione che paga un aggressore. Dopo la revisione, firma la transazione e la salva su un supporto rimovibile.

(Online) Apre la transazione firmata nell'istanza online in modo che possa trasmetterla alla rete peer-to-peer.

Il vantaggio principale dei portafogli offline è la possibilità di migliorare notevolmente la sicurezza. Finché il portafoglio offline non viene compromesso e l'utente rivede tutte le transazioni in uscita prima della firma, i satoshi dell'utente sono sicuri anche se il portafoglio online è compromesso.

Lo svantaggio principale dei portafogli offline è il tempo necessario per eseguire tutti i passaggi. Per la massima sicurezza, è richiesto all'utente di dedicare un dispositivo alle sole attività offline. Il dispositivo offline deve essere avviato ogni volta che vengono spesi i fondi e l'utente deve copiare fisicamente i dati dal dispositivo online al dispositivo offline e viceversa.

Portafogli hardware

I portafogli hardware sono dispositivi dedicati all'esecuzione di un portafoglio di sola firma. La loro specificità consente loro di eliminare molte delle vulnerabilità presenti nei sistemi operativi progettati per uso generale, consentendo loro di comunicare in modo sicuro direttamente con altri dispositivi in modo che gli utenti non debbano trasferire i dati manualmente. L’iter di lavoro dell'utente è simile al seguente:

(Hardware) Crea chiavi private e pubbliche principali. Collega il portafoglio hardware ad un dispositivo di rete in modo che possa ottenere la chiave pubblica padre.

(In rete) Come con un portafoglio completo, ricava le chiavi pubbliche per ricevere i pagamenti. Quando è pronto a spendere i satoshi, inserisce i dettagli della transazione, collega il portafoglio hardware e fa clic su Spendi. Il wallet in rete invierà automaticamente i dettagli della transazione al portafoglio hardware.

(Hardware) Rivede i dettagli della transazione sullo schermo del portafoglio hardware. Alcuni portafogli hardware possono richiedere una passphrase o un numero PIN per fornire ulteriore sicurezza. Il portafoglio hardware firma la transazione e la carica nel portafoglio in rete.

(In rete) Il portafoglio in rete riceve la transazione firmata dal portafoglio hardware e la trasmette alla rete.

Il vantaggio principale dei portafogli hardware è la loro possibilità di migliorare notevolmente la sicurezza sui portafogli full-service con molto meno lavoro per l’utente dei portafogli offline.

Lo svantaggio principale dei portafogli hardware è il loro costo e disponibiltà. Anche se la seccatura è inferiore a quella dei portafogli offline, l'utente deve comunque acquistare un dispositivo hardware e portarlo con sé ogni volta che è necessario effettuare una transazione utilizzando il portafoglio di sola firma.

Portafogli Distributing-Only

Sono programmi wallet eseguiti in ambienti difficili da proteggere, come i server Web, possono essere progettati per distribuire le chiavi pubbliche (inclusi gli indirizzi P2PKH o P2SH) e nulla più. Esistono due modi comuni per progettare questi portafogli minimalisti:

P

Utilizzare una chiave pubblica padre per creare chiavi pubbliche secondarie. Per evitare il riutilizzo delle chiavi, è necessario utilizzare un metodo per garantire che la stessa chiave pubblica non venga distribuita due volte.

File di portafoglio

I portafogli Bitcoin al loro interno sono una raccolta di chiavi private. Queste raccolte sono memorizzate digitalmente in un file o possono anche essere fisicamente archiviate su pezzi di carta.

Formati chiave privata

Le chiavi private vengono utilizzate per sbloccare Satoshi da un particolare indirizzo. In Bitcoin, una chiave privata in formato standard è semplicemente un numero a 256 bit, tra i valori:

0x01 e 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAE DCE6 AF48 A03B BFD2 5E8C D036 4140, rappresentando quasi l'intero intervallo di valori 2^256-1. La gamma è regolata dallo standard di crittografia ECDSA secp256k1 utilizzato da Bitcoin.

Wallet Import Format (WIF)

Per evitare errori di battitura nella trascrizione delle chiavi private o per questioni operative è possibile importare un formato di file rappresentante il wallet (WIF).

WIF utilizza la codifica base58Check su una chiave privata, riducendo notevolmente le possibilità di errore di copia, proprio come gli indirizzi standard di Bitcoin.

1.Prendi una chiave privata

2.Aggiungi un byte 0x80 di fronte ad essa per gli indirizzi mainnet o 0xef per gli indirizzi testnet.

3.Aggiungi un byte 0x01 dopo se deve essere usato con chiavi pubbliche compresse (descritto in una successiva sottosezione). Nulla viene aggiunto se viene utilizzato con chiavi pubbliche non compresse.

4.Eseguire un hash SHA-256 sulla chiave estesa.

5.Eseguire un hash SHA-256 sul risultato dell'hash SHA-256.

6.Prendi i primi quattro byte del secondo hash SHA-256; questo è il checksum.

7.Aggiungere i quattro byte di checksum dal punto 5 alla fine della chiave estesa dal punto 2.

8.Converti il risultato da una stringa di byte in una stringa Base58 usando la codifica Base58Check

Il processo è facilmente reversibile, usando la funzione di decodifica di Base58 e rimuovendo il padding.

Formati di chiave pubblica

Le chiavi pubbliche Bitcoin ECDSA rappresentano un punto su una particolare curva ellittica (EC) definita in secp256k1. Nella loro forma tradizionale non compressa, le chiavi pubbliche contengono un byte di identificazione, una coordinata X a 32 byte e una coordinata Y a 32 byte. L'illustrazione estremamente semplificata di seguito mostra un tale punto sulla curva ellittica utilizzata da Bitcoin, y^2 = x^3 + 7, su un campo di numeri contigui.

(Secp256k1 in realtà modula le coordinate con un grande primo, che produce un campo di interi non contigui e una trama significativamente meno chiara, sebbene i principi siano gli stessi).

Una riduzione di quasi il 50% delle dimensioni della chiave pubblica può essere realizzata senza modificare alcun fondamento facendo cadere la coordinata Y. Questo è possibile perché solo due punti lungo la curva condividono qualsiasi particolare coordinata X, quindi la coordinata Y a 32 byte può essere sostituita con un singolo bit che indica se il punto è su ciò che appare nell'illustrazione come il lato "superiore" o il “fondo”.

Nessun dato viene perso creando queste chiavi pubbliche compresse: solo una piccola quantità di CPU è necessaria per ricostruire la coordinata Y e accedere alla chiave pubblica non compressa. Entrambe le chiavi pubbliche non compresse e compresse sono descritte nella documentazione ufficiale di secp256k1 e supportate di default nella libreria OpenSSL ampiamente utilizzata.

Poiché sono facili da utilizzare e poiché riducono quasi della metà lo spazio della catena di blocchi utilizzato per memorizzare le chiavi pubbliche per ogni output esaurito, le chiavi pubbliche compresse sono l'impostazione predefinita in Bitcoin Core e sono l'impostazione predefinita consigliata per tutti i software Bitcoin.

Tuttavia, la versione Bitcoin Core precedente alla 0.6 utilizzava chiavi non compresse. Ciò crea alcune complicazioni, poiché la forma hash di una chiave non compressa è diversa dalla forma hash di una chiave compressa, quindi la stessa chiave funziona con due indirizzi P2PKH diversi. Ciò significa anche che la chiave deve essere inviata nel formato corretto nello script della firma in modo che corrisponda all'hash nello script pubkey dell'output precedente.

Per questo motivo, Bitcoin Core utilizza diversi byte identificatori per aiutare i programmi a identificare come dovrebbero essere utilizzate le chiavi:

•Le chiavi private pensate per essere utilizzate con chiavi pubbliche compresse hanno aggiunto 0x01 prima di essere codificate in Base-58. (Vedi la sezione relativa alla codifica della chiave privata sopra).

•Le chiavi pubbliche non compresse iniziano con 0x04; le chiavi pubbliche compresse iniziano con 0x03 o 0x02 a seconda che siano maggiori o minori del punto medio della curva. Questi prefissi sono tutti usati nella documentazione ufficiale di secp256k1.

Hierarchical Deterministic Key Creation

Il protocollo gerarchico di creazione e trasferimento di chiavi deterministiche (protocollo HD) semplifica notevolmente i backup dei wallet, elimina la necessità di ripetute comunicazioni tra più programmi utilizzando lo stesso wallet, consente la creazione di account figli che possona operare in modo indipendente, dà a ciascun account principale la possibilità di monitorare o controlla i propri figli anche se l'account figlio è compromesso e divide ciascun account in parti ad accesso completo e ad accesso limitato, in modo che utenti o programmi non attendibili possano ricevere o monitorare i pagamenti senza poterli spendere.

Il protocollo HD sfrutta la funzione di creazione di chiavi pubbliche ECDSA, point (), che prende un intero grande (la chiave privata) e lo trasforma in un punto grafico (la chiave pubblica):

point (private_key) == public_key

A causa del modo in cui point () funziona, è possibile creare una chiave pubblica secondaria combinando una chiave pubblica esistente (principale) con un'altra chiave pubblica creata da qualsiasi valore intero (i). Questa chiave pubblica figlio è la stessa chiave pubblica che verrebbe creata dalla funzione point () se si aggiungesse il valore i alla chiave privata originale (padre) e poi si trovasse il resto di quella somma divisa da una costante globale utilizzata da tutti i Bitcoin software (p):

point ((parent_private_key + i)% p) == parent_public_key + point (i)

Ciò significa che due o più programmi indipendenti che concordano su una sequenza di numeri interi possono creare una serie di coppie di chiavi figlio univoche da una singola coppia di chiavi genitore senza ulteriori comunicazioni. Inoltre, il programma che distribuisce nuove chiavi pubbliche per ricevere il pagamento può farlo senza alcun accesso alle chiavi private, consentendo al programma di distribuzione delle chiavi pubbliche di funzionare su una piattaforma possibilmente non sicura come un server web pubblico.

Le chiavi pubbliche secondarie possono anche creare le proprie chiavi pubbliche figlio (chiavi pubbliche nipote) ripetendo le operazioni di derivazione della chiave figlio:

point ((child_private_key + i)% p) == child_public_key + point (i)

Indipendentemente dalla creazione di chiavi pubbliche secondarie o di chiavi pubbliche ulteriormente discese, una sequenza prevedibile di valori interi non sarebbe migliore dell'utilizzo di una singola chiave pubblica per tutte le transazioni, poiché chiunque conosca una chiave pubblica secondaria potrebbe trovare tutte le altre chiavi pubbliche secondarie create dalla stessa chiave pubblica genitore. Invece, un seme casuale può essere utilizzato per generare deterministicamente la sequenza di valori interi in modo che la relazione tra le chiavi pubbliche figlio sia invisibile a chiunque non abbia quel seme.

Il protocollo HD utilizza un singolo seed root  per creare una gerarchia di figli, nipoti e altre chiavi discendenti con valori interi non linkabili generabili deterministicamente. Ogni chiave figlio riceve anche un seme generato dal suo genitore, chiamato chain code, quindi la compromissione di chain code non compromette necessariamente la sequenza per l'intera gerarchia, consentendo al master chain code di continuare ad essere utile anche se , ad esempio, un programma di distribuzione di chiavi pubbliche basato sul web viene violato.

Come illustrato sopra, la derivazione della chiave HD richiede quattro input:

-La chiave privata padre e la chiave pubblica padre sono normali chiavi ECDSA a 256 bit non compresse.

-Il codice della catena padre è 256 bit di dati apparentemente casuali.

-Il numero di indice è un numero intero a 32 bit specificato dal programma.

Nella forma normale mostrata nell'illustrazione sopra, il codice di catena padre, la chiave pubblica padre e il numero di indice vengono inseriti in un hash crittografico a una via (HMAC-SHA512) per produrre 512 bit di dati deterministicamente-generati-ma-apparentemente-casuali. I 256 bit apparentemente casuali sul lato destro dell'output dell'hash vengono utilizzati come un nuovo codice di catena figlio. I 256 bit apparentemente casuali sul lato sinistro dell'output dell'hash vengono utilizzati come valore intero da combinare con la chiave privata padre o la chiave pubblica padre per, rispettivamente, creare una chiave privata figlio o una chiave pubblica secondaria:

child_private_key == (parent_private_key + lefthand_hash_output)% G

child_public_key == point ((parent_private_key + lefthand_hash_output)% G)

child_public_key == point (child_private_key) == parent_public_key + point (lefthand_hash_output)

Specificando numeri di indice diversi verranno create diverse chiavi figlio non scollegabili dalle stesse chiavi parent. La ripetizione della procedura per le chiavi figlio utilizzando il codice catena figlio creerà le chiavi nipoti scollegabili.

Poiché la creazione di chiavi figlio richiede sia una chiave che un codice catena, la chiave e il codice catena insieme sono chiamati la chiave estesa. Una chiave privata estesa e la corrispondente chiave pubblica estesa hanno lo stesso codice catena. La chiave privata principale (principale di livello superiore) e il codice catena principale derivano da dati casuali, come illustrato di seguito.

Come illustrato sopra, la derivazione della chiave HD richiede quattro input:

-La chiave privata padre e la chiave pubblica padre sono normali chiavi ECDSA a 256 bit non compresse.

-Il codice della catena padre è 256 bit di dati apparentemente casuali.

-Il numero di indice è un numero intero a 32 bit specificato dal programma.

Nella forma normale mostrata nell'illustrazione sopra, il codice di catena padre, la chiave pubblica padre e il numero di indice vengono inseriti in un hash crittografico a una via (HMAC-SHA512) per produrre 512 bit di dati deterministicamente-generati-ma-apparentemente-casuali. I 256 bit apparentemente casuali sul lato destro dell'output dell'hash vengono utilizzati come un nuovo codice di catena figlio. I 256 bit apparentemente casuali sul lato sinistro dell'output dell'hash vengono utilizzati come valore intero da combinare con la chiave privata padre o la chiave pubblica padre per, rispettivamente, creare una chiave privata figlio o una chiave pubblica secondaria:

child_private_key == (parent_private_key + lefthand_hash_output)% G

child_public_key == point ((parent_private_key + lefthand_hash_output)% G)

child_public_key == point (child_private_key) == parent_public_key + point (lefthand_hash_output)

Specificando numeri di indice diversi verranno create diverse chiavi figlio non scollegabili dalle stesse chiavi parent. La ripetizione della procedura per le chiavi figlio utilizzando il codice catena figlio creerà le chiavi nipoti scollegabili.

Poiché la creazione di chiavi figlio richiede sia una chiave che un codice catena, la chiave e il codice catena insieme sono chiamati la chiave estesa. Una chiave privata estesa e la corrispondente chiave pubblica estesa hanno lo stesso codice catena. La chiave privata principale (principale di livello superiore) e il codice catena principale derivano da dati casuali, come illustrato di seguito.

Un seme radice (root seed) viene creato da 128 bit, 256 bit o 512 bit di dati casuali. Questo root seed di soli 128 bit è l'unico dato di cui l'utente ha bisogno per eseguire il backup al fine di ricavare ogni chiave creata da un particolare programma wallet utilizzando impostazioni particolari.

Avvertenza: al momento della stesura di questo documento, non è previsto che i programmi wallet HD siano completamente compatibili, pertanto gli utenti devono utilizzare lo stesso programma wallet HD con le stesse impostazioni relative a HD per un root seed specifico.

Il root seed viene sottoposto a hash per creare 512 bit di dati apparentemente casuali, da cui vengono creati la chiave privata principale e il codice catena principale (insieme, la chiave privata estesa principale). La chiave pubblica principale è derivata dalla chiave privata principale che utilizza point (), che, insieme al codice catena principale, è la chiave pubblica estesa principale. Le chiavi principali estese sono funzionalmente equivalenti alle altre chiavi estese, è solo la loro posizione nella parte superiore della gerarchia che li rende speciali.

Hardened Keys

Le hardened keys (chiavi “rinforzate”) risolvono un potenziale problema con le normali chiavi estese. Se un utente malintenzionato ottiene un normale codice di catena padre e una chiave pubblica padre, può ottenere con brute force tutti i codici di catena derivati da esso. Se l'attaccante ottiene anche un figlio, un nipote o una chiave privata ulteriormente discendente, può usare il codice catena per generare tutte le chiavi private estese che discendono da quella chiave privata, come mostrato nelle generazioni di nipoti e pronipoti dell'illustrazione sotto.

La formula “rinforzata”, illustrata sopra, combina insieme il numero indice, il codice catena padre e la chiave privata genitore per ricavare i dati per generare il codice catena figlio e la chiave privata figlio. Questa formula rende impossibile creare chiavi pubbliche secondarie senza conoscere la chiave privata genitore. In altre parole, le chiavi pubbliche estese dei genitori non possono creare chiavi pubbliche secondarie potenziate.

Per questo motivo, una chiave privata estesa “rinforzata” è meno funzionale di una normale chiave privata estesa, tuttavia, le chiavi private estese e “rinforzate” creano un firewall attraverso il quale non possono accadere compromessi di derivazione delle chiavi multilivello. Poiché le chiavi pubbliche estese su hardened child non possono generare da sole codici catena di grandchild, la compromissione di una chiave pubblica estesa genitore non può essere combinato con la compromissione di una chiave privata grandchild per creare chiavi private estese di grandchild.

Il protocollo HD utilizza numeri di indice diversi per indicare se deve essere generata una chiave normale o rinforzata. I numeri di indice da 0x00 a 0x7fffffff (da 0 a 2^31-1) genereranno una chiave normale; i numeri di indice da 0x80000000 a 0xffffffff generano una chiave rinforzata. Per semplificare le descrizioni, molti sviluppatori usano il simbolo primo per indicare i tasti temprati, quindi la prima chiave normale (0x00) è 0 e la prima chiave indurita (0x80000000) è 0' .

(Gli sviluppatori di Bitcoin tipicamente usano l'apostrofo ASCII piuttosto che il simbolo primo unicode, una convenzione che d'ora in poi seguiremo).

Questa descrizione compatta è ulteriormente combinata con le barre precedute da m o M per indicare la gerarchia e il tipo di chiave, con m essendo una chiave privata e M una chiave pubblica. Ad esempio, m / 0 '/ 0/122' si riferisce al 123 ° figlio privato hardened (per numero di indice) del primo figlio normale (per indice) del primo figlio hardened (per indice) della chiave privata principale. La seguente gerarchia illustra la notazione primaria e i firewall chiave induriti.

I portafogli che seguono il protocollo BIP32 HD creano solo figli “rinforzati” della chiave privata principale (m) per impedire che una chiave secondaria compromessa, comprometta la chiave principale. Poiché non ci sono figli normali per le chiavi principali, la chiave pubblica principale non viene utilizzata nei portafogli HD. Tutte le altre chiavi possono avere figli normali, pertanto è possibile utilizzare le chiavi pubbliche estese corrispondenti.

Il protocollo HD descrive anche un formato di serializzazione per chiavi pubbliche estese e chiavi private estese. Per i dettagli, consultare la sezione relativa al portafoglio nel riferimento dello sviluppatore o BIP32 per le specifiche del protocollo HD completo.

Conservare i root seed

I root seed nel protocollo HD sono 128, 256 o 512 bit di dati casuali che devono essere salvati con precisione. Per rendere più conveniente l'utilizzo di metodi di backup non digitali, come la memorizzazione o la copiatura manuale, BIP39 definisce un metodo per la creazione di un seme radice a 512 bit da una pseudo-frase (mnemonica) di parole comuni in linguaggio naturale che era a sua volta creato da 128 a 256 bit di entropia e opzionalmente protetto da una password.

Il numero di parole generate è correlato alla quantità di entropia utilizzata:

Entropia Bits - Parole

128 - 12

160 - 15

192 - 18

224 - 21

256 - 24

La passphrase può essere di qualsiasi lunghezza. Viene semplicemente aggiunta alla pseudo-frase mnemonica, quindi sia il mnemonico che la password vengono sottoposti a hash 2.048 volte utilizzando HMAC-SHA512, dando come risultato un seme apparentemente casuale a 512 bit. Poiché qualsiasi input alla funzione hash crea un seed a 512 bit apparentemente casuale, non esiste un modo fondamentale per dimostrare che l'utente ha inserito la password corretta, consentendo eventualmente all'utente di proteggere un seed anche se sottoposto a coercizione.