name: Il Funzionamento Interno dei Wallet Bitcoin goal: Esplorare i principi crittografici che si celano dietro i wallet Bitcoin. objectives:

Definire le nozioni teoriche necessarie per comprendere gli algoritmi crittografici utilizzati in Bitcoin.
Comprendere a fondo la costruzione di un wallet gerarchico-deterministico.
Sapere come identificare e ridurre i rischi associati alla gestione di un wallet.
Capire i principi delle funzioni hash, delle chiavi crittografiche e delle firme digitali.

Un Viaggio nel Cuore dei wallet Bitcoin

Scopri i segreti dei wallet Bitcoin gerarchico-deterministici con il nostro corso CYP201! Che tu sia un utente o un appassionato che cerca di approfondire la conoscenza, questo corso offre un'immersione completa nel funzionamento di questi strumenti che tutti noi usiamo quotidianamente.

Impara i meccanismi delle funzioni hash, delle firme digitali (ECDSA e Schnorr), delle frasi mnemoniche, delle chiavi crittografiche e della creazione di indirizzi di ricezione, esplorando al contempo strategie di sicurezza avanzate.

Questo corso ti farà comprendere la struttura di un wallet Bitcoin, ma non solo: ti preparerà anche di immergerti nell'affascinante mondo della crittografia.

Con una chiara pedagogia, oltre 60 diagrammi esplicativi e esempi concreti, CYP201 ti permetterà di capire dalla A alla Z come funziona il tuo wallet, così da poter navigare l'universo Bitcoin con fiducia. Prendi il controllo dei tuoi UTXO oggi, comprendendo come funzionano i wallet HD!

Introduzione

Introduzione al Corso

Benvenuto al corso CYP201, dove esploreremo a fondo il funzionamento dei wallet gerarchico-deterministici. Questo corso è progettato per chiunque voglia comprendere le basi tecniche dell'uso di Bitcoin, sia che si tratti di utenti occasionali, appassionati illuminati o futuri esperti.

L'obiettivo di questa formazione è fornirti le chiavi per padroneggiare gli strumenti che utilizzi quotidianamente. I wallet HD, che sono al centro della tua esperienza utente, si basano su concetti a volte complessi, che cercheremo di rendere accessibili. Insieme semplificheremo questa difficoltà!

Prima di immergerci nei dettagli della costruzione e del funzionamento dei wallet Bitcoin, inizieremo con alcuni capitoli sulle primitive crittografiche da conoscere, necessarie per proseguire. Inizieremo con le funzioni hash crittografiche, fondamentali sia per i wallet sia per il protocollo Bitcoin stesso. Scoprirai le loro principali caratteristiche, le funzioni specifiche utilizzate in Bitcoin e, in un capitolo più tecnico, imparerai in dettaglio il funzionamento della regina delle funzioni hash: SHA256.

Successivamente, discuteremo il funzionamento degli algoritmi di firma digitale che utilizzi ogni giorno per proteggere i tuoi UTXO. Bitcoin ne utilizza due: ECDSA e il protocollo Schnorr. Imparerai le primitive matematiche alla base di questi algoritmi e come garantiscono la sicurezza delle transazioni.

Una volta acquisita una buona comprensione di questi elementi di crittografia, passeremo finalmente al cuore del corso: i wallet gerarchico-deterministici! Prima, c'è una sezione dedicata alle frasi mnemoniche, le sequenze di 12 o 24 parole che ti permettono di creare e ripristinare i wallet. Scoprirai come queste parole vengono generate da una fonte di entropia e come facilitano l'uso di Bitcoin.

La formazione continuerà con lo studio della passphrase BIP39, il seed (da non confondere con la frase mnemonica), la master chain code e la master key. Vedremo in dettaglio cosa sono questi elementi, i loro rispettivi ruoli e come vengono calcolati.

Infine, partendo dalla master key, scopriremo come vengono derivate le coppie di chiavi crittografiche, in modo gerarchico e deterministico, fino agli indirizzi di ricezione.

CYP201 ti permetterà di utilizzare il tuo software wallet con fiducia, migliorando al contempo le tue capacità di riconoscere e mitigare i rischi. Preparati a diventare un vero esperto di wallet Bitcoin!

Funzioni Hash

Introduzione alle Funzioni Hash

Il primo tipo di algoritmi crittografici utilizzati in Bitcoin comprende le funzioni hash. Esse svolgono un ruolo essenziale a diversi livelli del protocollo e all'interno dei wallet. Scopriamo insieme cosa è una funzione hash, nonché come viene usata in Bitcoin.

Definizione e Principio di Hashing

L'hashing è un processo che trasforma informazioni di lunghezza arbitraria in un'altra informazione di lunghezza fissa attraverso una funzione hash crittografica. In altre parole, una funzione hash prende un input di qualsiasi dimensione e lo converte in un'impronta digitale di dimensione fissa, chiamata "hash". L'hash può anche essere talvolta definito come "digest", "condensed", o "hashed".

La funzione hash SHA256, ad esempio, produce un hash di lunghezza fissa di 256 bit. Se usiamo l'input "PlanB", un messaggio di lunghezza arbitraria, l'hash generato sarà la seguente impronta digitale di 256 bit:

24f1b93b68026bfc24f5c8265f287b4c940fb1664b0d75053589d7a4f821b688

Caratteristiche delle Funzioni Hash

Queste funzioni hash crittografiche hanno diverse caratteristiche essenziali che le rendono particolarmente utili nel contesto di Bitcoin e altri sistemi informatici:

Irreversibilità (o resistenza alla preimmagine)
Resistenza alla manomissione (effetto valanga)
Resistenza alle collisioni
Resistenza alla seconda preimmagine

1. Irreversibilità (resistenza alla preimmagine):

Irreversibilità significa che è facile calcolare l'hash a partire dalle informazioni in input, ma il calcolo inverso, ovvero trovare l'input partendo dall'hash, è praticamente impossibile. Questa proprietà rende le funzioni di hash perfette per creare impronte digitali uniche senza compromettere le informazioni originali. Questa caratteristica viene spesso definita funzione unidirezionale

Nell'esempio dato, ottenere l'hash 24f1b9… conoscendo l'input "PlanB" è semplice e veloce. Tuttavia, trovare il messaggio "PlanB" conoscendo solo 24f1b9… è impossibile.

È pertanto impossibile trovare una preimmagine $m$ per un hash $h$ tale per cui $h = \text{HASH}(m)$ , dove $\text{HASH}$ è una funzione hash crittografica.

2. Resistenza alla manomissione (effetto valanga)

La seconda caratteristica è la resistenza alla manomissione, nota anche come effetto valanga. Questa caratteristica si osserva in una funzione hash perché un minimo cambiamento nel messaggio di input comporta un radicale cambiamento nell'hash di output.

Se torniamo al nostro esempio con l'input "PlanB" e la funzione SHA256, abbiamo visto che l'hash generato è il seguente:

24f1b93b68026bfc24f5c8265f287b4c940fb1664b0d75053589d7a4f821b688

Se facciamo un cambiamento molto lieve all'input usando questa volta "Planb", il semplice passaggio da una "B" maiuscola a una "b" minuscola altera completamente l'output dell'hash SHA256:

bb038b4503ac5d90e1205788b00f8f314583c5e22f72bec84b8735ba5a36df3f

Questa proprietà garantisce che la seppur minima alterazione del messaggio originale diventa immediatamente rilevabile, poiché non cambia solo una piccola parte dell'hash, ma l'intero output. Questo può essere di interesse in vari campi per verificare l'integrità di messaggi, software o anche transazioni Bitcoin.

3. Resistenza alle Collisioni

La terza caratteristica è la resistenza alle collisioni. Una funzione hash è resistente alle collisioni se è computazionalmente impossibile trovare 2 messaggi diversi che producono lo stesso output dalla funzione di hash. Formalmente, è difficile trovare due messaggi distinti $m_1$ e $m_2$ tali per cui:

 $\text{HASH}(m_1) = \text{HASH}(m_2)$

In realtà è matematicamente inevitabile che esistano collisioni per le funzioni hash, perché la quantità degli input può essere maggiore ai possibili output. Questo è noto come il principio dei cassetti di Dirichlet: se $n$ oggetti sono distribuiti in $m$ cassetti, con $m < n$ , allora almeno un cassetto conterrà necessariamente due o più oggetti. Per una funzione hash, questo principio si applica perché il numero di messaggi possibili è (quasi) infinito, mentre il numero di hash possibili è finito ( $2^{256}$ nel caso di SHA256).

Non significa che non ci siano collisioni per le funzioni hash, ma piuttosto che una buona funzione hash rende trascurabile la probabilità di trovare una collisione. Questa caratteristica, ad esempio, non è più verificata sugli algoritmi SHA-0 e SHA-1, predecessori di SHA-2, per i quali sono state trovate collisioni. SHA-0 e SHA-1 sono quindi ora sconsigliate e spesso considerate obsolete. Per una funzione hash di $n$ bit, la resistenza alle collisioni è dell'ordine di $2^{\frac{n}{2}}$ , in conformità con l'attacco del compleanno. Ad esempio, per SHA256 ( $n = 256$ ), la complessità di trovare una collisione è dell'ordine di $2^{128}$ tentativi. In termini pratici, ciò significa che, per trovare una collisione, si devono passare $2^{128}$ messaggi diversi attraverso la funzione.

4. Resistenza alla Seconda Preimmagine

La resistenza alla seconda preimmagine è un'altra caratteristica importante delle funzioni hash. Afferma che, dato un messaggio $m_1$ e il suo hash $h$ , è computazionalmente impraticabile trovare un altro messaggio $m_2 \neq m_1$ tale per cui:

 $\text{HASH}(m_1) = \text{HASH}(m_2)$

La resistenza alla seconda preimmagine è in qualche modo simile alla resistenza alle collisioni, eccetto che qui l'attacco è più difficile, perché l'attaccante non può scegliere liberamente $m_1$ .

Applicazioni delle Funzioni Hash in Bitcoin

La funzione hash più utilizzata nel protocollo Bitcoin è SHA256 ("Secure Hash Algorithm 256 bits"). Progettata all'inizio degli anni 2000 dalla NSA e standardizzata dal NIST, produce come output un hash di 256 bit.

Questa funzione è utilizzata in molti ambiti di Bitcoin. A livello del protocollo, è coinvolta nel meccanismo di Proof-of-Work, dove viene applicata in un doppio hashing per cercare una parziale collisione tra l'header di un blocco candidato (creato da un miner) e il target di difficoltà. Se questa parziale collisione viene trovata, il blocco candidato diventa valido e può essere aggiunto alla blockchain.

SHA256 è anche utilizzata nella costruzione di un Merkle Tree, che è il sistema usato per registrare le transazioni nei blocchi. Questa struttura si trova anche nel protocollo Utreexo, che permette di ridurre la dimensione dell'UTXO Set. Con l'introduzione di Taproot nel 2021, inoltre, SHA256 è sfruttato in MAST (Merkelised Alternative Script Tree), che permette di rivelare solo le condizioni di spesa effettivamente utilizzate in uno script, senza divulgare le altre opzioni possibili. È anche utilizzato nel calcolo degli identificatori di transazione, nella trasmissione di pacchetti sulla rete P2P, nelle firme digitali... Infine e questo è di particolare interesse in questa formazione, SHA256 è utilizzato a livello applicativo per la generazione dei wallet e la derivazione di indirizzi.

La maggior parte delle volte, quando si incontra l'uso di SHA256 in Bitcoin, si tratta di un doppio hash SHA256, notato "HASH256", che consiste semplicemente nell'applicare SHA256 due volte consecutivamente:

HASH256(m) = SHA256(SHA256(m))

Anche se oggi un singolo SHA256 è considerato crittograficamente sicuro, questa pratica del doppio hashing aggiunge un ulteriore strato di sicurezza contro certi potenziali attacchi.

Un'altra funzione hash disponibile nel linguaggio Script, utilizzata per derivare indirizzi di ricezione, è la funzione RIPEMD160. Questa funzione produce un hash di 160 bit (quindi più corto di SHA256) ed è generalmente combinata con SHA256 per formare la funzione HASH160:

 $\text{HASH160}(m) = \text{RIPEMD160}(\text{SHA256}(m))$

La combinazione è utilizzata per generare hash più corti, in particolare nella creazione di certi indirizzi Bitcoin che rappresentano hash di chiavi o hash di script, così come per produrre impronte digitali delle chiavi.

Infine, solo a livello applicativo, talvolta viene utilizzata anche la funzione SHA512, che gioca indirettamente un ruolo nella derivazione delle chiavi per i wallet. Tale funzione è molto simile a SHA256 nel suo funzionamento; entrambe appartengono alla stessa famiglia SHA2, ma SHA512 produce, come indica il nome, un hash di 512 bit rispetto ai 256 bit di SHA256. Ne dettaglieremo l'uso nei capitoli successivi.

Ora conosci le basi essenziali sulle funzioni di hashing per seguire la formazione. Nel prossimo capitolo propongo di scoprire più in dettaglio il funzionamento della funzione che è al cuore di Bitcoin: SHA256. Lo dissezioneremo per capire come raggiunge le caratteristiche che abbiamo descritto qui. Il prossimo capitolo è piuttosto lungo e tecnico, ma non è essenziale per seguire il resto della formazione. Quindi, se hai difficoltà a comprenderlo, non preoccuparti e passa direttamente al capitolo seguente, che sarà molto più accessibile.

Il Funzionamento Interno di SHA256

905eb320-f15b-5fb6-8d2d-5bb447337deb Abbiamo precedentemente visto che le funzioni di hashing possiedono importanti caratteristiche che giustificano il loro uso nel protocollo Bitcoin. Esaminiamo ora i meccanismi interni di queste funzioni, che conferiscono loro queste proprietà e, per farlo, propongo di dissezionare il funzionamento di SHA256. Le funzioni SHA256 e SHA512 appartengono alla stessa famiglia SHA2. Il loro meccanismo si basa su una costruzione specifica chiamata Merkle-Damgård construction. Anche RIPEMD160 utilizza questo stesso tipo di costruzione.

Come promemoria, abbiamo un messaggio di dimensione arbitraria come input per SHA256, e lo passeremo attraverso la funzione per ottenere un hash di 256 bit come output.

Pre-elaborazione dell'input

Come prima cosa dobbiamo preparare il nostro messaggio di input $m$ in modo che abbia una lunghezza standard che sia un multiplo di 512 bit. Questo passaggio è cruciale per il corretto funzionamento dell'algoritmo nelle fasi successive. Per fare ciò, si inizia con una fase, che prevede l'aggiunta di bit di padding. Aggiungiamo prima un bit separatore 1 al messaggio, seguito da un certo numero di bit 0. Il numero di bit 0 aggiunti è calcolato in modo che la lunghezza totale del messaggio dopo questa aggiunta sia congruente a 448 modulo 512. La lunghezza $L$ del messaggio con i bit di padding è uguale a:

 $L \equiv 448 \mod 512$

$\text{mod}$ , che sta per modulo, è un'operazione matematica che, tra due numeri interi, restituisce il resto della divisione euclidea del primo per il secondo. Per esempio: $16 \mod 5 = 1$ . È un'operazione ampiamente utilizzata in crittografia.

Il padding assicura che, dopo aver aggiunto i 64 bit nel passaggio successivo, la lunghezza totale del messaggio equalizzato sarà un multiplo di 512 bit. Se il messaggio iniziale ha una lunghezza di $M$ bit, il numero ( $N$ ) di bit 0 da aggiungere è quindi:

 $N = (448 - (M + 1) \mod 512) \mod 512$

Per esempio, se il messaggio iniziale è di 950 bit, il calcolo sarebbe il seguente:

 $\begin{align*} M & = 950 \\ M + 1 & = 951 \\ (M + 1) \mod 512 & = 951 \mod 512 \\ & = 951 - 512 \cdot \left\lfloor \frac{951}{512} \right\rfloor \\ & = 951 - 512 \cdot 1 \\ & = 951 - 512 \\ & = 439 \\ \\ 448 - (M + 1) \mod 512 & = 448 - 439 \\ & = 9 \\ \\ N & = (448 - (M + 1) \mod 512) \mod 512 \\ N & = 9 \mod 512 \\ & = 9 \end{align*}$

Così, avremmo 9 0 in aggiunta al separatore 1. I nostri bit di padding da aggiungere direttamente dopo il nostro messaggio $M$ saranno quindi:

1000 0000 00

Dopo aver aggiunto i bit di padding al nostro messaggio $M$ , aggiungiamo anche una rappresentazione a 64 bit della lunghezza originale del messaggio $M$ , espressa in binario. Questo consente alla funzione hash di essere sensibile all'ordine dei bit e alla lunghezza del messaggio.

Se torniamo al nostro esempio con un messaggio iniziale di 950 bit, convertiamo il numero decimale 950 in binario, ottenendo 1110 1101 10. Completiamo questo numero con zeri alla base per raggiungere un totale di 64 bit. Nel nostro esempio, otteniamo:

0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1011 0110

Questa dimensione viene aggiunta seguendo le necessità della fase di padding. Pertanto, il messaggio dopo la nostra pre-elaborazione consiste di tre parti:

Il messaggio originale $M$ ;
un bit 1 seguito da diversi bit 0 che completa il padding;
una rappresentazione di 64 bit della lunghezza di $M$ per formare il padding con la dimensione.

Inizializzazione delle Variabili

SHA256 utilizza otto variabili di stato iniziali, indicate da $A$ a $H$ , ognuna di 32 bit. Queste variabili sono inizializzate con costanti specifiche, che sono le parti frazionarie delle radici quadrate dei primi otto numeri primi. Utilizzeremo questi valori successivamente durante il processo di hashing:

$A = 0x6a09e667$
$B = 0xbb67ae85$
$C = 0x3c6ef372$
$D = 0xa54ff53a$
$E = 0x510e527f$
$F = 0x9b05688c$
$G = 0x1f83d9ab$
$H = 0x5be0cd19$

SHA256 utilizza anche altre 64 costanti, indicate da $K_0$ to $K_{63}$ , che sono le parti frazionarie delle radici cubiche dei primi 64 numeri primi:

 $K[0 \ldots 63] = \begin{pmatrix} 0x428a2f98, & 0x71374491, & 0xb5c0fbcf, & 0xe9b5dba5, \\ 0x3956c25b, & 0x59f111f1, & 0x923f82a4, & 0xab1c5ed5, \\ 0xd807aa98, & 0x12835b01, & 0x243185be, & 0x550c7dc3, \\ 0x72be5d74, & 0x80deb1fe, & 0x9bdc06a7, & 0xc19bf174, \\ 0xe49b69c1, & 0xefbe4786, & 0x0fc19dc6, & 0x240ca1cc, \\ 0x2de92c6f, & 0x4a7484aa, & 0x5cb0a9dc, & 0x76f988da, \\ 0x983e5152, & 0xa831c66d, & 0xb00327c8, & 0xbf597fc7, \\ 0xc6e00bf3, & 0xd5a79147, & 0x06ca6351, & 0x14292967, \\ 0x27b70a85, & 0x2e1b2138, & 0x4d2c6dfc, & 0x53380d13, \\ 0x650a7354, & 0x766a0abb, & 0x81c2c92e, & 0x92722c85, \\ 0xa2bfe8a1, & 0xa81a664b, & 0xc24b8b70, & 0xc76c51a3, \\ 0xd192e819, & 0xd6990624, & 0xf40e3585, & 0x106aa070, \\ 0x19a4c116, & 0x1e376c08, & 0x2748774c, & 0x34b0bcb5, \\ 0x391c0cb3, & 0x4ed8aa4a, & 0x5b9cca4f, & 0x682e6ff3, \\ 0x748f82ee, & 0x78a5636f, & 0x84c87814, & 0x8cc70208, \\ 0x90befffa, & 0xa4506ceb, & 0xbef9a3f7, & 0xc67178f2 \end{pmatrix}$

Divisione dell'Input

Ora che abbiamo un input equalizzato, passeremo alla fase più importante di elaborazione dell'algoritmo SHA256: la funzione di compressione. Questo passaggio è molto importante, poiché è questo che che conferisce principalmente alla funzione hash le sue proprietà crittografiche che abbiamo studiato nel capitolo precedente.

Iniziamo dividendo il nostro messaggio equalizzato (risultato dei passaggi di pre-elaborazione) in diversi blocchi $P$ da 512 bit ciascuno. Se il nostro messaggio equalizzato ha una dimensione totale di $n \times 512$ bit, avremo quindi $n$ blocchi, ciascuno di 512 bit. Ogni blocco da 512 bit sarà elaborato individualmente dalla funzione di compressione, che consiste in 64 round di operazioni successive. Chiamiamo questi blocchi $P_1$ , $P_2$ , $P_3$ ...

Operazioni Logiche

Prima di esplorare in dettaglio la funzione di compressione, è importante comprendere le operazioni logiche di base utilizzate. Queste operazioni, basate sull'algebra booleana, operano a livello di bit. Le operazioni logiche di base utilizzate sono:

Congiunzione (AND): denotata $\le$ , corrisponde a un "AND" logico.
Disgiunzione (OR): denotata $\lor$ , corrisponde a un "OR" logico.
Negazione (NOT): denotata $\lnot$ , corrisponde a un "NOT" logico.

Da queste operazioni di base possiamo definire operazioni più complesse, come "Exclusive OR" (XOR) denotato $\oplus$ , ampiamente utilizzato in crittografia. Ogni operazione logica può essere rappresentata da una tabella di riscontro, che indica il risultato per tutte le possibili combinazioni di valori di input binari (due operandi $p$ e $q$ ). Per XOR ( $\oplus$ ):

$p$	$q$	$p \oplus q$
0	0	0
0	1	1
1	0	1
1	1	0

Per AND ( $\le$ ):

$p$	$q$	$p \le q$
0	0	0
0	1	0
1	0	0
1	1	1

Per NOT ( $\lnot p$ ):

$p$	$\lnot p$
0	1
1	0

Prendiamo un esempio per capire il funzionamento di XOR a livello di bit. Se abbiamo due numeri binari di 6 bit:

$a = 101100$
$b = 001000$

Avremo:

 $a \oplus b = 101100 \oplus 001000 = 100100$

Applicando XOR bit per bit:

Posizione Bit	$a$	$b$	$a \oplus b$
1	1	0	1
2	0	0	0
3	1	1	0
4	1	0	1
5	0	0	0
6	0	0	0

Il risultato è quindi $100100$ .

Oltre alle operazioni logiche, la funzione di compressione utilizza operazioni di bit-shifting, che giocano un ruolo essenziale nel far girare i bit nell'algoritmo.

Prima di tutto, c'è l'operazione logical-right-shift, denotata $ShR_n(x)$ , che sposta tutti i bit di $x$ a destra di $n$ posizioni, riempiendo con zeri i bit lasciati vuoti a sinistra.

Per esempio, per $x = 101100001$ (su 9 bit) e $n = 4$ :

 $ShR_4(101100001) = 000010110$

Schematicamente, l'operazione di logical-right-shift potrebbe essere vista così:

Un'altra operazione utilizzata in SHA256 per la manipolazione dei bit è right-circular-rotation, denotata $RotR_n(x)$ , che sposta i bit di $x$ a destra di $n$ posizioni, reinserendo i bit spostati all'inizio della stringa. Per esempio, per $x = 101100001$ (su 9 bit) e $n = 4$ :

 $RotR_4(101100001) = 000110110$

Schematicamente, l'operazione right-circular-rotation potrebbe essere vista così:

Funzione di Compressione

Ora che abbiamo compreso le operazioni di base, esaminiamo in dettaglio la funzione di compressione per SHA256.

Nel passaggio precedente, abbiamo diviso il nostro input in diversi pezzi da 512 bit $P$ . Per ogni blocco da 512 bit $P$ , abbiamo:

Le parole del messaggio $W_i$ : con $i$ compreso tra 0 e 63.
Le costanti $K_i$ : con $i$ compreso tra 0 e 63, come definite nel passaggio precedente.
Le variabili di stato $A, B, C, D, E, F, G, H$ : inizializzate con i valori dal passaggio precedente.

Le prime 16 parole, da $W_0$ fino a $W_{15}$ , sono estratte direttamente dal blocco elaborato di 512 bit $P$ . Ogni parola $W_i$ consiste di 32 bit consecutivi del blocco. Quindi, ad esempio, prendiamo il nostro primo pezzo di input $P_1$ , e lo dividiamo ulteriormente in pezzi più piccoli da 32 bit che chiamiamo parole.

Le successive 48 parole ( $W_{16}$ fino a $W_{63}$ ) sono generate utilizzando la seguente formula:

 $W_i = W_{i-16} + \sigma_0(W_{i-15}) + W_{i-7} + \sigma_1(W_{i-2}) \mod 2^{32}$

Con:

$\sigma_0(x) = RotR_7(x) \oplus RotR_{18}(x) \oplus ShR_3(x)$
$\sigma_1(x) = RotR_{17}(x) \oplus RotR_{19}(x) \oplus ShR_{10}(x)$

In questo caso, $x$ è uguale a $W_{i-15}$ per $\sigma_0(x)$ e $W_{i-2}$ per $\sigma_1(x)$ .

Una volta determinate tutte le parole $W_i$ per il nostro blocco di 512 bit, possiamo passare alla funzione di compressione, che consiste nell'eseguire le operazioni 64 volte.

CYP201 Per ogni round $i$ da 0 a 63, abbiamo tre diversi tipi di input. Primo, $W_i$ che abbiamo appena determinato, in parte costituito dal nostro pezzo di messaggio $P_n$ . Successivamente, le 64 costanti $K_i$ . Infine usiamo le variabili di stato $A$ , $B$ , $C$ , $D$ , $E$ , $F$ , $G$ e $H$ , che cambieranno, evolvendosi, durante il processo di hashing per avere un valore diverso ad ogni round di compressione. Tuttavia, per il primo pezzo $P_1$ , usiamo le costanti iniziali date in precedenza.

Eseguiamo quindi le seguenti operazioni sui nostri input:

Function $\Sigma_0$ :

 $\Sigma_0(A) = RotR_2(A) \oplus RotR_{13}(A) \oplus RotR_{22}(A) -- **Function $\Sigma_1$:**$

\Sigma_1(E) = RotR_6(E) \oplus RotR_{11}(E) \oplus RotR_{25}(E)

 $- **Function $Ch$ ("_Choose_"):**$

Ch(E, F, G) = (E \le F) \oplus (\lnot E \le G)

 $- **Function $Maj$ ("_Majority_"):**$

Maj(A, B, C) = (A \le B) \oplus (A \le C) \oplus (B \le C)

 $Calcoliamo quindi 2 variabili temporanee: - $temp1$:$

temp1 = H + \Sigma_1(E) + Ch(E, F, G) + K_i + W_i \mod 2^{32}

 $- $temp2$:$

temp2 = \Sigma_0(A) + Maj(A, B, C) \mod 2^{32}

 $Successivamente aggiorniamo le variabili di stato come segue:$

\begin{cases} H = G \ G = F \ F = E \ E = D + temp1 \mod 2^{32} \ D = C \ C = B \ B = A \ A = temp1 + temp2 \mod 2^{32} \end{cases}

 $Il diagramma seguente rappresenta un round della funzione di compressione SHA256 come appena descritto: ![CYP201](/courses/cyp201/assets/fr/010.webp) - Le frecce indicano il flusso dei dati; - i riquadri rappresentano le operazioni eseguite; - il simbolo $+$ circondato rappresenta l'addizione modulo $2^{32}$. Possiamo già osservare che questo round produce nuove variabili di stato $A$, $B$, $C$, $D$, $E$, $F$, $G$ e $H$. Queste nuove variabili serviranno come input per il round successivo, che a sua volta produrrà nuove variabili $A$, $B$, $C$, $D$, $E$, $F$, $G$ e $H$, da utilizzare per il round seguente. Questo processo continua fino al 64° round. Dopo i 64 round, aggiorniamo i valori iniziali delle variabili di stato aggiungendoli ai valori finali alla fine dell'ultimo round:$

\begin{cases} A = A_{\text{initial}} + A \mod 2^{32} \ B = B_{\text{initial}} + B \mod 2^{32} \ C = C_{\text{initial}} + C \mod 2^{32} \ D = D_{\text{initial}} + D \mod 2^{32} \ E = E_{\text{initial}} + E \mod 2^{32} \ F = F_{\text{initial}} + F \mod 2^{32} \ G = G_{\text{initial}} + G \mod 2^{32} \ H = H_{\text{initial}} + H \mod 2^{32} \end{cases}

 $Questi valori di $A$, $B$, $C$, $D$, $E$, $F$, $G$ e $H$ risultanti dall'ultimo round, serviranno come valori iniziali per il blocco successivo, $P_2$. Per questo blocco $P_2$, replichiamo lo stesso processo di compressione con 64 round, poi aggiorniamo le variabili per il blocco $P_3$, e così via fino all'ultimo blocco del nostro input equalizzato. Dopo aver processato tutti i blocchi del messaggio, concateniamo i valori finali delle variabili $A$, $B$, $C$, $D$, $E$, $F$, $G$ e $H$ per formare l'hash finale a 256 bit della nostra funzione di hashing:$

\text{Hash} = A \Vert B \Vert C \Vert D \Vert E \Vert F \Vert G \Vert H

 $Ogni variabile è un intero a 32 bit, quindi la loro concatenazione produce sempre un risultato a 256 bit, indipendentemente dalla dimensione del nostro input dato inizialmente alla funzione di hashing. ### Come sono Rispettate le Proprietà Crittografiche Ma allora, come è possibile che questa funzione sia irreversibile, resistente alle collisioni e resistente alle manomissioni? Per la resistenza alle manomissioni, è abbastanza semplice da capire. Vengono eseguiti così tanti calcoli in cascata, che dipendono sia dall'input che dalle costanti, che la minima modifica del messaggio iniziale cambia completamente il percorso preso, e quindi cambia completamente l'hash di output. Questo è ciò che si chiama effetto valanga, proprietà in parte garantita dalla miscelazione degli stati intermedi con gli stati iniziali per ogni pezzo. Successivamente, quando si discute di una funzione hash crittografica, il termine "irreversibilità" non è generalmente utilizzato. Si parla piuttosto di "resistenza alla pre-immagine", la quale specifica che, per un dato $y$, è difficile trovare un $x$ tale per cui $h(x) = y$. La resistenza alla pre-immagine è garantita dalla complessità algebrica e dalla forte non-linearità delle operazioni eseguite nella funzione di compressione, così come dalla perdita di certe informazioni nel processo. Ad esempio, per un dato risultato di un'addizione modulo, ci sono diversi operandi possibili:$

3+2 \mod 10 = 5 \ 7+8 \mod 10 = 5 \ 5+10 \mod 10 = 5

 $In questo esempio, conoscendo solo il modulo utilizzato (10) e il risultato (5), non si può determinare con certezza quali siano gli operandi corretti utilizzati nell'addizione. Si dice che ci sono molteplici congruenze modulo 10. Per l'operazione XOR ci troviamo di fronte al medesimo problema. Ricordiamo la tabella di riscontro per questa operazione: qualsiasi output a 1 bit può essere determinato da due diverse configurazioni di input che hanno esattamente la stessa probabilità di essere i valori corretti. Nessuno può pertanto determinare con certezza gli operandi di un XOR, conoscendo solo il suo risultato. Aumentando la dimensione degli operandi XOR, aumenta esponenzialmente il numero di input possibili, se si parte conoscendo solo il risultato finale. Oltretutto XOR è spesso utilizzato insieme ad altre operazioni a livello di bit, come l'operazione $\text{RotR}$, che aggiungono ancora più possibili interpretazioni al risultato. La funzione di compressione utilizza anche l'operazione $\text{ShR}$, la quale rimuove una parte delle informazioni di base, che poi diventa impossibile recuperare in seguito. Ancora una volta, non esiste un modo per invertire questa operazione che sia lineare o algebrico. Tutte queste operazioni unidirezionali e di rimozione di informazioni sono utilizzate molto frequentemente nelle funzioni di compressione. Il numero di input possibili per un dato output è quindi pressoché infinito e ogni tentativo di calcolo inverso, porterebbe a equazioni con un numero molto elevato di incognite, destinato ad aumentare esponenzialmente ad ogni passo. Infine, per rispettare la resistenza alle collisioni, entrano in gioco diversi parametri, con la pre-elaborazione del messaggio originale che gioca un ruolo essenziale. Senza la pre-elaborazione potrebbe essere più facile trovare collisioni sulla funzione. Anche se, teoricamente, le collisioni esistono (a causa del principio del buco della serratura), la struttura della funzione di hash, combinata con le proprietà sopra menzionate, rende la probabilità di trovare una collisione estremamente bassa. Affinché una funzione hash sia resistente alle collisioni, è essenziale che: - L'output sia imprevedibile: qualsiasi prevedibilità può essere sfruttata per trovare collisioni più velocemente di un attacco brute force. La funzione assicura che ogni bit dell'output dipenda in modo non banale dall'input. In altre parole: la funzione è progettata in modo che ogni bit del risultato finale abbia una probabilità indipendente di essere 0 o 1, anche se questa indipendenza non è assoluta nella pratica. - La distribuzione degli hash sia pseudo-casuale: questo garantisce che gli hash siano uniformemente distribuiti. - La dimensione dell'hash sia sostanziale: più grande è lo spazio possibile per i risultati, più difficile è trovare una collisione. I crittografi progettano queste funzioni valutando i migliori attacchi possibili per trovare collisioni, poi aggiustando i parametri per rendere questi attacchi inefficaci. ### Costruzione di Merkle-Damgård La struttura di SHA256 si basa sulla costruzione di Merkle-Damgård, che consente di trasformare una funzione di compressione in una funzione hash che può elaborare messaggi di lunghezza arbitraria. Questo è esattamente ciò che abbiamo appena visto. Alcune vecchie funzioni hash come SHA1 o MD5, che utilizzano questa specifica costruzione, sono tuttavia vulnerabili agli attacchi di estensione della lunghezza, una è una tecnica che permette a un attaccante che conosce l'hash di un messaggio $M$ e la lunghezza di $M$ (senza conoscere il messaggio stesso) di calcolare l'hash di un messaggio $M'$ formato concatenando $M$ con contenuti aggiuntivi. Anche se SHA256 utilizza lo stesso tipo di costruzione, è teoricamente resistente a questo tipo di attacco, a differenza di SHA1 e MD5. Questo potrebbe spiegare il mistero del doppio hashing implementato in tutto il protocollo Bitcoin da Satoshi Nakamoto. Per evitare questo tipo di attacco, Satoshi potrebbe aver preferito utilizzare un doppio SHA256:$

\text{HASH256}(m) = \text{SHA256}(\text{SHA256}(m))

 $Il doppio hash migliora la sicurezza contro potenziali attacchi legati alla struttura di Merkle-Damgård, ma non aumenta la sicurezza del processo di hashing in termini di resistenza alle collisioni. Inoltre, anche se SHA256 fosse stato vulnerabile all'attacco dell'estensione della lunghezza, non avrebbe avuto un impatto grave, poiché tutti i casi d'uso delle funzioni hash in Bitcoin coinvolgono dati pubblici. Un attacco di estensione della lunghezza potrebbe essere utile per un attaccante, solo se i dati hashati sono privati e l'utente ha utilizzato la funzione hash come meccanismo di autenticazione per questi dati, simile a un MAC. L'implementazione del doppio hashing rimane un mistero nella progettazione di Bitcoin. Ora che abbiamo esaminato in dettaglio il funzionamento delle funzioni hash, in particolare SHA256, che è ampiamente utilizzata in Bitcoin, ci concentreremo più specificamente sugli algoritmi di derivazione crittografica utilizzati a livello applicativo, specialmente per derivare le chiavi per il tuo wallet. ## Gli algoritmi utilizzati per la derivazione <chapterId>cc668121-7789-5e99-bf5e-1ba085f4f5f2</chapterId> A livello applicativo, oltre alle funzioni hash, nel protocollo Bitcoin vengono utilizzati algoritmi di derivazione crittografica per generare dati sicuri a partire da input iniziali. Sebbene questi algoritmi si basino sulle funzioni hash, servono a scopi diversi, specialmente in termini di autenticazione e generazione di chiavi. Gli algoritmi che vedremo, mantengono alcune delle caratteristiche delle funzioni hash, come l'irreversibilità, la resistenza alla manomissione e la resistenza alle collisioni. Nella generazione dei wallet Bitcoin vengono principalmente utilizzati 2 algoritmi di derivazione: - **HMAC (_Hash-based Message Authentication Code_)** - **PBKDF2 (_Password-Based Key Derivation Function 2_)** Esploreremo insieme il funzionamento e il ruolo di ciascuno di essi. ### HMAC-SHA512 HMAC è un algoritmo crittografico che calcola un codice di autenticazione basato sulla combinazione di una funzione hash e una chiave segreta. Bitcoin utilizza HMAC-SHA512, la variante di HMAC che utilizza la funzione hash SHA512. Abbiamo già visto nel capitolo precedente che SHA512 fa parte della stessa famiglia di funzioni di SHA256, ma produce un output di 512 bit. Ecco il suo schema operativo generale con $m$ che rappresenta il messaggio di input e $K$ una chiave segreta: ![CYP201](/courses/cyp201/assets/fr/011.webp) Studiamo in dettaglio cosa succede all'interno di questa scatola nera che è HMAC-SHA512. La funzione HMAC-SHA512 con: - $m$: il messaggio di dimensione arbitraria scelto dall'utente (primo input); - $K$: la chiave segreta arbitraria scelta dall'utente (secondo input); - $K'$: la chiave $K$ equalizzata per adeguarsi alla dimensione $B$ dei blocchi della funzione hash (1024 bit per SHA512, o 128 byte); - $\text{SHA512}$: la funzione hash SHA512; - $\oplus$: l'operazione XOR (exclusive or); - $\Vert$: l'operatore di concatenazione, che collega stringhe di bit da un'estremità all'altra; - $\text{opad}$: costante composta dal byte $0x5c$ ripetuto 128 volte - $\text{ipad}$: costante composta dal byte $0x36$ ripetuto 128 volte Prima di calcolare l'HMAC, è necessario equalizzare la chiave e le costanti secondo la dimensione del blocco $B$. Se la chiave $K$ è, ad esempio, più corta di 128 byte, viene riempita con zeri fino a raggiungere la dimensione $B$. Se $K$ è più lunga di 128 byte, viene compressa usando SHA512, e poi vengono aggiunti zeri fino a raggiungere 128 byte. In questo modo si ottiene una chiave equalizzata denominata $K'$. I valori di $\text{opad}$ e $\text{ipad}$ si ottengono ripetendo i loro differenti byte base ($0x5c$ per $\text{opad}$, $0x36$ per $\text{ipad}$) fino a raggiungere la dimensione $B$. Quindi, con $B = 128$ byte, abbiamo:$

\text{opad} = \underbrace{0x5c5c\ldots5c}_{128 \ \text{bytes}}

 $Una volta processato l'input, l'algoritmo HMAC-SHA512 è definito dalla seguente equazione:$

\text{HMAC-SHA512}(K,m) = \text{SHA512} \left( (K' \oplus \text{opad}) \parallel \text{SHA512} \left( (K' \oplus \text{ipad}) \parallel m \right) \right)

 $L'equazione si scompone nei seguenti passaggi: - XOR della chiave modificata $K'$ con $\text{ipad}$ per ottenere $\text{iKpad}$; - XOR della chiave modificata $K'$ con $\text{opad}$ per ottenere $\text{oKpad}$; - Concatenazione di $\text{iKpad}$ con il messaggio $m$. - Hash di questo risultato con SHA512 per ottenere un hash intermedio $H_1$. - Concatenazione di $\text{oKpad}$ con $H_1$. - Hash di questo risultato con SHA512 per ottenere il risultato finale $H_2$. Tutti i passaggi possono essere riassunti schematicamente come segue: ![CYP201](/courses/cyp201/assets/fr/012.webp) In Bitcoin, il risultato di HMAC è utilizzato in particolare per la derivazione delle chiavi nei wallet HD (gerarchico-deterministici, ne parleremo più dettagliatamente nei prossimi capitoli) e come componente di PBKDF2. ### PBKDF2 PBKDF2 (_Password-Based Key Derivation Function 2_) è un algoritmo di derivazione delle chiavi progettato per aumentare la sicurezza delle password. L'algoritmo applica alla password una funzione pseudo-randomica (in questo caso HMAC-SHA512) e un sale crittografico, per poi ripetere l'operazione un certo numero di volte, al fine di produrre una chiave. In Bitcoin PBKDF2 è utilizzata per generare il seed di un wallet HD a partire da una frase mnemonica e una passphrase (ma ne parleremo più dettagliatamente nei prossimi capitoli). Il processo PBKDF2 è il seguente, con: - $m$: la frase mnemonica dell'utente; - $s$: la passphrase opzionale per aumentare la sicurezza (campo vuoto se non c'è passphrase); - $n$: il numero di iterazioni della funzione che, nel nostro caso, è 2048. La funzione PBKDF2 è definita iterativamente. Ogni iterazione prende il risultato della precedente, lo passa attraverso HMAC-SHA512 e combina i risultati successivi per produrre la chiave finale:$

\text{PBKDF2}(m, s) = \text{HMAC-SHA512}^{2048}(m, s)

y^2 = x^3 + ax + b

 $### secp256k1 Per utilizzare ECDSA o Schnorr è necessario scegliere i parametri della curva ellittica, ovvero i valori di $a$ e $b$ nell'equazione della curva. Esistono diversi standard di curve ellittiche che hanno la reputazione di essere sicuri dal punto di vista crittografico. Il più noto è la curva _secp256r1_, definita e raccomandata dal NIST (_National Institute of Standards e Technology_). Nonostante ciò, Satoshi Nakamoto, l'inventore di Bitcoin, ha scelto di non utilizzare questa curva. La ragione di questa scelta è sconosciuta, ma alcuni credono che abbia preferito trovare un'alternativa perché i parametri di questa curva potrebbero potenzialmente contenere un backdoor. Il protocollo Bitcoin utilizza pertanto lo standard **_secp256k1_**. Questa curva è definita dai parametri $a = 0$ e $b = 7$. La sua equazione è quindi:$

y^2 = x^3 + 7

 $La rappresentazione grafica nel campo dei numeri reali appare così: ![CYP201](/courses/cyp201/assets/fr/015.webp) Tuttavia, in crittografia lavoriamo con insiemi finiti di numeri. Più precisamente lavoriamo sul campo finito $\mathbb{F}_p$, che è il campo degli interi modulo di un numero primo $p$. **Definizione**: un numero primo è un intero naturale maggiore o uguale a 2 che può essere diviso solo da due numeri interi positivi: 1 e se stesso. Il numero 7 è ad esempio un numero primo, poiché può essere diviso solo per 1 e 7. Il numero 8 invece non è primo, perché può essere diviso per 1, 2, 4 e 8. Il numero primo $p$ utilizzato nel protocollo Bitcoin per definire il campo finito è molto grande. È scelto in modo tale che l'ordine del campo (cioè, il numero di elementi in $\mathbb{F}_p$) sia sufficientemente grande da garantire sicurezza crittografica. Il numero primo $p$ utilizzato è: ```text p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F ``` In notazione decimale, questo corrisponde a:$

p = 2^{256} - 2^{32} - 977

 $L'equazione della nostra curva ellittica, nella realtà, diventa così:$

y^2 \equiv x^3 + 7 \mod p

 $Dato che questa curva è definita sul campo finito $\mathbb{F}_p$, non assomiglia più a una curva continua ma piuttosto a un insieme discreto di punti. Ecco come appare per esempio la curva utilizzata in Bitcoin per un $p$ molto piccolo, $p = 17$: ![CYP201](/courses/cyp201/assets/fr/016.webp) In questo esempio, ho intenzionalmente limitato il campo finito a $p = 17$ per motivi didattici, ma bisogna immaginare che quello utilizzato in Bitcoin sia immensamente più grande, quasi $2^{256}$. Utilizziamo un campo finito di interi modulo $p$ per garantire l'accuratezza delle operazioni sulla curva. Le curve ellittiche espresse nel campo dei numeri reali, sono infatti soggette a imprecisioni a causa degli errori di arrotondamento durante i calcoli computazionali. Se vengono eseguite numerose operazioni sulla curva, questi errori si accumulano e il risultato finale può essere incorretto o difficile da riprodurre. L'uso esclusivo di interi positivi garantisce una perfetta accuratezza dei calcoli e quindi la riproducibilità del risultato. La matematica delle curve ellittiche sui campi finiti è analoga a quella applicata nel campo dei numeri reali, con l'adattamento che tutte le operazioni sono eseguite modulo $p$. Per semplificare le spiegazioni continueremo nei capitoli seguenti a illustrare i concetti utilizzando una curva definita su numeri reali, tenendo presente che, in pratica, la curva è definita su un campo finito. Se desideri approfondire le basi matematiche della crittografia moderna, ti consiglio anche di consultare questo altro corso su Plan ₿ Network: https://planb.network/courses/d2fd9fc0-d9ed-4a87-9fa3-0fdbb3937e28 ## Calcolo della Chiave Pubblica a partire dalla Chiave Privata <chapterId>fcb2bd58-5dda-5ecf-bb8f-ad1a0561ab4a</chapterId> Come visto in precedenza, gli algoritmi di firma digitale del protocollo Bitcoin si basano su una coppia di chiavi, privata e pubblica, che sono matematicamente collegate. Esploriamo insieme quale sia questo legame matematico e come vengono generate. ### La Chiave Privata La chiave privata è semplicemente un numero casuale o pseudo-casuale. Nel caso di Bitcoin questo numero è di 256 bit. Il numero di possibilità per una chiave privata Bitcoin è quindi teoricamente $2^{256}$. **Nota**: Un "numero pseudo-casuale" è un numero che possiede proprietà vicine a quelle di un numero veramente casuale ma è generato da un algoritmo deterministico. Tuttavia, nella pratica, ci sono solo $n$ punti distinti sulla nostra curva ellittica secp256k1, dove $n$ è l'ordine del punto generatore $G$ della curva. Vedremo più avanti a cosa corrisponde questo numero, ma ricorda semplicemente che una chiave privata valida è un intero compreso tra $1$ e $n-1$, sapendo che $n$ è un numero vicino ma leggermente inferiore a $2^{256}$. Pertanto, ci sono alcuni numeri a 256 bit che non sono validi per diventare una chiave privata in Bitcoin, specificamente, tutti i numeri tra $n$ e $2^{256}$. Se la generazione del numero casuale (la chiave privata) produce un valore $k$ tale che $k \geq n$, è considerato non valido, e deve essere generato un nuovo valore casuale. Il numero di possibilità per una chiave privata Bitcoin è quindi circa $n$, che è un numero vicino a $1.158 \times 10^{77}$. Questo numero è così grande che se scegli una chiave privata a caso, è statisticamente quasi impossibile capitare sulla chiave privata di un altro utente. Per darti un'idea della scala, il numero di possibili chiavi private su Bitcoin è di un ordine di grandezza vicino a quello degli atomi stimati nell'universo osservabile. Come vedremo nei prossimi capitoli, oggi, la maggior parte delle chiavi private utilizzate in Bitcoin non sono generate casualmente ma sono il risultato della derivazione deterministica da una frase mnemonica, essa stessa pseudo-casuale (questa è la famosa frase di 12 o 24 parole). Questa informazione non cambia nulla per l'uso di algoritmi di firma come ECDSA, ma aiuta a riconcentrare la nostra divulgazione su Bitcoin. Per il proseguimento della spiegazione, la chiave privata sarà denotata dalla lettera minuscola $k$. ### La Chiave Pubblica La chiave pubblica è un punto sulla curva ellittica, denotato dalla lettera maiuscola $K$, e viene calcolata dalla chiave privata $k$. Questo punto $K$ è rappresentato da una coppia di coordinate $(x, y)$ sulla curva ellittica, ogni coordinata essendo un intero modulo $p$, il numero primo che definisce il campo finito $\mathbb{F}_p$. Una chiave pubblica non compressa è rappresentata in pratica da 520 bit (o 65 byte), corrispondenti a due numeri a 256 bit ($x$ e $y$) posti uno di seguito all'altro. Questi numeri sono l'ascissa ($x$) e l'ordinata ($y$) del nostro punto su secp256k1, preceduti dal prefisso $0x04$ di 8 bit. Tuttavia è possibile rappresentare la chiave pubblica in una forma compressa utilizzando solo 33 byte (264 bit) mantenendo solo l'ascissa $x$ del nostro punto sulla curva e un byte che indica la parità di $y$. Questo è ciò che è noto come chiave pubblica compressa. Parlerò di più di questo negli ultimi capitoli di questo corso. Ma ciò che devi ricordare è che una chiave pubblica $K$ è un punto descritto da $x$ e $y$. Per calcolare il punto $K$ che corrisponde alla nostra chiave pubblica, utilizziamo l'operazione di moltiplicazione scalare sulle curve ellittiche, definita come un'addizione ripetuta ($k$ volte) del punto generatore $G$:$

K = k \cdot G

 $dove: - $k$ è la chiave privata (un intero casuale tra $1$ e $n-1$); - $G$ è il punto di generazione della curva ellittica, utilizzato da tutti i partecipanti della rete Bitcoin; - $\cdot$ rappresenta la moltiplicazione scalare sulla curva ellittica, che equivale ad aggiungere il punto $G$ a se stesso $k$ volte. Il fatto che, nel protocollo Bitcoin, questo punto $G$ sia comune a tutte le chiavi pubbliche permette di avere la certezza che la stessa chiave privata $k$ ci darà sempre la stessa chiave pubblica $K$: ![CYP201](/courses/cyp201/assets/fr/017.webp) La caratteristica principale di questa operazione è che si tratta di una funzione unidirezionale. È facile calcolare la chiave pubblica $K$ conoscendo la chiave privata $k$ e il punto di generazione $G$, ma è praticamente impossibile calcolare la chiave privata $k$ conoscendo solo la chiave pubblica $K$ e il punto $G$. Trovare $k$ a partire da $K$ e $G$ equivale a risolvere il problema del logaritmo discreto sulle curve ellittiche, un problema matematicamente difficile per il quale non è noto alcun algoritmo efficiente. Anche i calcolatori più potenti contemporanei non sono in grado di risolvere questo problema in un tempo ragionevole. ![CYP201](/courses/cyp201/assets/fr/018.webp) ### Addizione e Raddoppio dei Punti sulle Curve Ellittiche Il concetto di addizione sulle curve ellittiche è definito geometricamente. Se abbiamo due punti $P$ e $Q$ sulla curva, l'operazione $P + Q$ viene calcolata tracciando una linea che passa per $P$ e $Q$. Questa linea intersecherà necessariamente la curva in un terzo punto $R'$. Prendiamo poi l'immagine speculare di questo punto rispetto all'asse x per ottenere il punto $R$, che è il risultato dell'addizione:$

P + Q = R

 $Graficamente, ciò può essere rappresentato come segue: ![CYP201](/courses/cyp201/assets/fr/019.webp) Il raddoppio di un punto, ovvero l'operazione $P + P$, si ottiene tracciando la tangente alla curva nel punto $P$. Questa tangente interseca la curva in un altro punto $S'$. Prendiamo poi l'immagine speculare di questo punto rispetto all'asse x per ottenere il punto $S$, che è il risultato del raddoppio:$

2P = S

 $Graficamente, ciò è mostrato come: ![CYP201](/courses/cyp201/assets/fr/020.webp) Utilizzando queste operazioni di addizione e raddoppio, possiamo eseguire la moltiplicazione scalare di un punto per un intero $k$, denotata $kP$, eseguendo ripetuti raddoppi e addizioni. Supponiamo ad esempio di aver scelto una chiave privata $k = 4$. Per calcolare la chiave pubblica associata, eseguiamo:$

K = k \cdot G = 4G

 $Graficamente, ciò corrisponde a eseguire una serie di addizioni e raddoppi: - Si calcola $2G$ raddoppiando $G$. - Poi si calcola $4G$ raddoppiando $2G$. ![CYP201](/courses/cyp201/assets/fr/021.webp) Se vogliamo per esempio calcolare il punto $3G$, dobbiamo prima calcolare il punto $2G$ raddoppiando il punto $G$, poi sommare $G$ e $2G$. Per eseguire la somma tra $G$ e $2G$, basta tracciare la linea che collega questi due punti, recuperare l'unico punto $-3G$ all'intersezione tra questa linea e la curva ellittica, e poi determinare $3G$ come l'opposto di $-3G$. Avremo:$

G + G = 2G

2G + G = 3G

 $Graficamente, ciò sarebbe rappresentato come segue: ![CYP201](/courses/cyp201/assets/fr/022.webp) ### Funzione Unidirezionale Grazie a queste operazioni possiamo capire perché è facile derivare una chiave pubblica da una chiave privata, ma il contrario è praticamente impossibile. Ritorniamo al nostro esempio semplificato. Con una chiave privata $k = 4$. Per calcolare la chiave pubblica associata, eseguiamo:$

K = k \cdot G = 4G

 $Siamo quindi stati in grado di calcolare facilmente la chiave pubblica $K$ conoscendo $k$ e $G$. Ora: se qualcuno conosce solo la chiave pubblica $K$, si trova di fronte al problema del logaritmo discreto: trovare $k$ tale per cui $K = k \cdot G$. Questo specifico problema è considerato di difficile soluzione, perché non esiste un algoritmo efficiente per risolverlo sulle curve ellittiche, che è ciò che garantisce la sicurezza degli algoritmi ECDSA e Schnorr. Naturalmente, in questo esempio semplificato con $k = 4$, sarebbe possibile trovare $k$ tramite tentativi ed errori, poiché il numero di possibilità è basso. Ma nella pratica $k$ è un intero a 256 bit, il che rende il numero di possibilità astronomicamente grande (circa $1.158 \times 10^{77}$). È da considerarsi impraticabile trovare $k$ attraverso tentativi di brute force. ## Firmare con la Chiave Privata <chapterId>bb07826f-826e-5905-b307-3d82001fb778</chapterId> Ora che sai come derivare una chiave pubblica da una chiave privata, puoi già ricevere bitcoin utilizzando questa coppia di chiavi come condizione di spesa. Ma come spenderli? Per spendere bitcoin dovrai sbloccare lo _scriptPubKey_ associato al tuo UTXO, per dimostrare che sei effettivamente il legittimo proprietario. Per farlo devi produrre una firma $s$ che corrisponda alla chiave pubblica $K$ presente nello _scriptPubKey_ utilizzando la chiave privata $k$, la quale a sua volta è stata inizialmente utilizzata per calcolare $K$. La firma digitale è quindi la prova inconfutabile che sei in possesso della chiave privata associata alla chiave pubblica che esponi. ### Parametri della Curva Ellittica Per fornire una firma digitale, tutti i partecipanti devono prima concordare sui parametri della curva ellittica utilizzata. Nel caso di Bitcoin, i parametri di **secp256k1** sono i seguenti: Il campo finito $\mathbb{Z}_p$ definito da:$

p = 2^{256} - 2^{32} - 977

 $```text p = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F ``` $p$ è un numero primo molto grande leggermente inferiore a $2^{256}$. La curva ellittica $y^2 = x^3 + ax + b$ su $\mathbb{Z}_p$ definita da:$

a = 0, \quad b = 7

 $Il punto di generazione o punto di origine $G$: ```text G = 0x0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 ``` Questo numero è la forma compressa che fornisce solo l'ascissa del punto $G$. Il prefisso `02` all'inizio determina quale dei due valori aventi questa ascissa $x$ deve essere utilizzato come punto di origine. L'ordine $n$ di $G$ (il numero di punti esistenti) e il cofattore $h$: ```text n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 ``` $n$ è un numero molto grande leggermente inferiore a $p$.$

h=1

 $$h$ è il cofattore o il numero di sottogruppi. Non approfondirò cosa rappresenta qui, poiché è abbastanza complesso e, nel caso di Bitcoin, non dobbiamo prenderlo in considerazione poiché è uguale a $1$. Tutte queste informazioni sono pubbliche e note a tutti i partecipanti. Grazie ad esse, gli utenti sono in grado di effettuare una firma digitale e verificarla. ### Firma con ECDSA L'algoritmo ECDSA consente a un utente di firmare un messaggio utilizzando la propria chiave privata, in modo tale che chiunque conosca la corrispondente chiave pubblica possa verificare la validità della firma, senza che la chiave privata venga mai rivelata. Nel contesto Bitcoin il messaggio da firmare dipende dal _sighash_ scelto dall'utente. È _sighash_ che determinerà quali parti della transazione sono coperte dalla firma. Parlerò più dettagliatamente di questo nel prossimo capitolo. Ecco i passaggi per generare una firma ECDSA: Come primo passo calcoliamo l'hash ($e$) del messaggio che deve essere firmato. Il messaggio $m$ viene quindi passato attraverso una funzione hash crittografica, generalmente SHA256 o doppio SHA256 nel caso di Bitcoin:$

e = \text{HASH}(m)

 $Successivamente, calcoliamo un nonce. In crittografia un nonce è semplicemente un numero generato in modo casuale, o pseudo-casuale, che viene utilizzato una sola volta. Ciò significa che ogni volta che viene effettuata una nuova firma digitale con questa coppia di chiavi, sarà molto importante utilizzare un nonce diverso, altrimenti, comprometterà la sicurezza della chiave privata. È quindi sufficiente determinare un intero casuale e unico $r$ tale per cui $1 \leq r \leq n-1$, dove $n$ è l'ordine del punto di origine $G$ sulla curva ellittica. Poi calcoleremo il punto $R$ sulla curva ellittica con le coordinate $(x_R, y_R)$ tale per cui:$

R = r \cdot G

 $Estraiamo il valore dell'ascissa del punto $R$ ($x_R$). Questo valore rappresenta la prima parte della firma. Infine calcoliamo la seconda parte della firma $s$ in questo modo:$

s = r^{-1} \left( e + k \cdot x_R \right) \mod n

 $dove: - $r^{-1}$ è l'inverso modulare di $r$ modulo $n$, cioè un intero tale per cui $r \cdot r^{-1} \equiv 1 \mod n$; - $k$ è la chiave privata dell'utente; - $e$ è l'hash del messaggio; - $n$ è l'ordine del punto di generazione $G$ della curva ellittica. La firma è quindi semplicemente la concatenazione di $x_R$ e $s$:$

\text{SIG} = x_R \Vert s

 $### Verifica della Firma ECDSA Per verificare una firma $(x_R, s)$, chiunque conosca la chiave pubblica $K$ e i parametri della curva ellittica può procedere in questo modo: Innanzitutto verifica che $x_R$ e $s$ siano nell'intervallo $[1, n-1]$. Questo assicura che la firma rispetti i vincoli matematici del gruppo ellittico. Se ciò non avviene, chi effettua la verifica rifiuta immediatamente la firma come non valida. Poi calcola l'hash del messaggio:$

e = \text{HASH}(m)

 $Calcola l'inverso modulare di $s$ modulo $n$:$

s^{-1} \mod n

 $Calcola due valori scalari $u_1$ e $u_2$ in questo modo:$

\begin{align*} u_1 &= e \cdot s^{-1} \mod n \ u_2 &= x_R \cdot s^{-1} \mod n \end{align*}

 $Infine calcola il punto $V$ sulla curva ellittica tale per cui:$

V = u_1 \cdot G + u_2 \cdot K

 $La firma è valida solo se $x_V \equiv x_R \mod n$, dove $x_V$ è la coordinata $x$ del punto $V$. Infatti, combinando $u_1 \cdot G$ e $u_2 \cdot K$, si ottiene un punto $V$ che, se la firma è valida, deve corrispondere al punto $R$ utilizzato durante la firma (modulo $n$). ### Firma con il Protocollo Schnorr Lo schema di firma Schnorr è un'alternativa a ECDSA che offre molti vantaggi. È possibile utilizzarlo in Bitcoin dal 2021, con l'introduzione di Taproot e i modelli di script P2TR. Proprio come ECDSA, lo schema Schnorr consente di firmare un messaggio utilizzando una chiave privata, in modo tale che la firma possa essere verificata da chiunque conosca la corrispondente chiave pubblica. Nel caso di Schnorr si utilizza esattamente la stessa curva di ECDSA, con gli stessi parametri. Le chiavi pubbliche, tuttavia, sono rappresentate in modo leggermente diverso rispetto a ECDSA. Sono infatti definite solo dalla coordinata $x$ del punto sulla curva ellittica. A differenza di ECDSA, dove le chiavi pubbliche compresse sono rappresentate da 33 byte (con un byte per il prefisso che indica la parità di $y$), Schnorr utilizza chiavi pubbliche di 32 byte corrispondenti solo alla coordinata $x$ del punto $K$, assumendo che $y$ sia pari per default. Questa rappresentazione semplificata riduce la dimensione delle firme e facilita alcune ottimizzazioni negli algoritmi di verifica. La chiave pubblica è quindi la coordinata $x$ del punto $K$:$

\text{pk} = K_x

 $Il primo passo per generare una firma è l'hash del messaggio ma, a differenza di ECDSA, viene fatto con altri valori e si utilizza una funzione di hash etichettata per evitare collisioni in contesti diversi. Una funzione di hash etichettata implica semplicemente l'aggiunta di un "tag" arbitrario agli input della funzione di hash insieme ai dati del messaggio. ![CYP201](/courses/cyp201/assets/fr/023.webp) Oltre al messaggio, vengono passati nella funzione etichettata anche la coordinata $x$ della chiave pubblica $K_x$, così come un punto $R$ calcolato dal nonce $r$ ($R=r \cdot G$) che è a sua volta un intero univoco per ogni firma, calcolato deterministicamente dalla chiave privata e dal messaggio per evitare vulnerabilità legate al riutilizzo del nonce. Proprio come per la chiave pubblica, anche per descrivere $R$ viene considerata solo la coordinata $x$ del nonce $R_x$. Il risultato di questo hashing notato $e$ è chiamato "challenge":$

e = \text{HASH}(\text{``BIP0340/challenge''}, R_x \Vert K_x \Vert m) \mod n

 $Qui, $\text{HASH}$ è la funzione di hash SHA256, e $\text{``BIP0340/challenge''}$ è il tag specifico per l'hashing. Alla fine viene calcolato il parametro $s$, dalla chiave privata $k$, dal nonce $r$ e dal challenge $e$:$

s = (r + e \cdot k) \mod n

 $La firma è quindi semplicemente la coppia $Rx$ e $s$.$

\text{SIG} = R_x \Vert s

 $### Verifica della Firma Schnorr La verifica di una firma Schnorr è più semplice di quella effettuata con ECDSA. Ecco i passaggi per verificare la firma $(R_x, s)$ con la chiave pubblica $K_x$ e il messaggio $m$: Prima verifichiamo che $K_x$ sia un intero valido e minore di $p$. Se è così recuperiamo il corrispondente punto sulla curva con $K_y$ pari. Estraiamo anche $R_x$ e $s$ separando la firma $\text{SIG}$. Poi controlliamo che $R_x < p$ e $s < n$ (l'ordine della curva). Successivamente calcoliamo il challenge $e$ nello stesso modo in cui l'ha fatto chi ha firmato il messaggio:$

e = \text{HASH}(\text{``BIP0340/challenge''}, R_x \Vert K_x \Vert m) \mod n

 $Poi calcoliamo un punto di riferimento sulla curva in questo modo:$

R' = s \cdot G - e \cdot K

 $Infine, verifichiamo che $R'_x = R_x$. Se le due coordinate x corrispondono, allora la firma $(R_x, s)$ è effettivamente valida con la chiave pubblica $K_x$. ### Perché funziona? Il firmatario ha calcolato $s = r + e \cdot k \mod n$, quindi $R' = s \cdot G - e \cdot K$ dovrebbe essere uguale al punto originale $R$, perché:$

s \cdot G = (r + e \cdot k) \cdot G = r \cdot G + e \cdot k \cdot G

 $Poiché $K = k \cdot G$, abbiamo $e \cdot k \cdot G = e \cdot K$. Quindi:$

R' = r \cdot G = R

 $Pertanto abbiamo:$

R'_x = R_x

\text{CS} = \frac{\text{ENT}}{32}

 $dove $\text{ENT}$ rappresenta la lunghezza dell'entropia in bit, e $\text{CS}$ la lunghezza del checksum in bit. In un'entropia di 256 bit, ad esempio, si prendono i primi 8 bit dell'hash per formare il checksum:$

\text{CS} = \frac{256}{32} = 8 \text{ bit}

 $Una volta calcolato, il checksum viene concatenato con l'entropia per ottenere una sequenza di bit estesa indicata con $\text{ENT} \Vert \text{CS}$ ("concatenare" significa mettere di seguito). ![CYP201](/courses/cyp201/assets/fr/036.webp) ### Corrispondenza tra l'Entropia e la Frase Mnemonica Il numero di parole nella frase mnemonica dipende dalla dimensione dell'entropia iniziale, come illustrato nella seguente tabella con: - $\text{ENT}$: la dimensione in bit dell'entropia; - $\text{CS}$: la dimensione in bit del checksum; - $w$: il numero di parole nella frase mnemonica risultante.$

\begin{array}{|c|c|c|c|} \hline \text{ENT} & \text{CS} & \text{ENT} \Vert \text{CS} & w \ \hline 128 & 4 & 132 & 12 \ 160 & 5 & 165 & 15 \ 192 & 6 & 198 & 18 \ 224 & 7 & 231 & 21 \ 256 & 8 & 264 & 24 \ \hline \end{array}

 $Per un'entropia di 256 bit, ad esempio, il risultato $\text{ENT} \Vert \text{CS}$ è di 264 bit e produce una mnemonica di 24 parole. ### Conversione della Sequenza Binaria in una Frase Mnemonica La sequenza di bit $\text{ENT} \Vert \text{CS}$ viene quindi divisa in segmenti di 11 bit. Ogni segmento di 11 bit, una volta convertito in decimale, corrisponde a un numero tra 0 e 2047, che designa la posizione di una parola [in una lista di 2048 parole standardizzata dal BIP39](https://github.com/Planb-Network/bitcoin-educational-content/blob/dev/resources/bet/bip39-wordlist//courses/cyp201/assets/BIP39-WORDLIST.pdf). ![CYP201](/courses/cyp201/assets/fr/037.webp) Se prendiamo ad esempio un'entropia di 128 bit, il checksum è di 4 bit e quindi la sequenza totale misura 132 bit, che viene poi divisa in 12 segmenti di 11 bit (i bit arancioni designano il checksum): ![CYP201](/courses/cyp201/assets/fr/038.webp) Ogni segmento è poi convertito in un numero decimale che rappresenta una parola nella lista. Il segmento binario `01011010001` dell'esempio è equivalente in decimale a `721`. Aggiungendo 1 per allinearsi con l'indicizzazione della lista (che inizia da 1 e non da 0), si ottiene il rango della parola `722`, che nella lista corrisponde alla parola "*focus*". ![CYP201](/courses/cyp201/assets/fr/039.webp) Lo stesso tipo di corrispondenza è ripetuta per ciascuno dei 12 segmenti, al fine di ottenere una frase di 12 parole. ![CYP201](/courses/cyp201/assets/fr/040.webp) ### Caratteristiche del Dizionario BIP39 Una particolarità del dizionario BIP39 è che nessuna parola condivide le stesse prime quattro lettere nello stesso ordine con un'altra. Questo significa che annotare solo le prime quattro lettere di ogni parola è sufficiente per identificarla con certezza e, quindi, salvare la mnemonica. Può essere interessante per risparmiare spazio, specialmente per coloro che desiderano inciderla su un supporto metallico. La lista di 2048 parole esiste in diverse lingue. Non sono semplici traduzioni, ma parole distinte per ogni lingua. Tuttavia, è fortemente consigliato attenersi alla versione inglese, poiché le versioni in altre lingue generalmente non sono supportate dal software wallet. ### Quale Lunghezza Scegliere per la Tua Frase Mnemonica? Per determinare la lunghezza ottimale della tua mnemonica, devi considerare la reale sicurezza che essa fornisce. Una frase di 12 parole assicura 128 bit di sicurezza, mentre una frase di 24 ne offre 256. Tuttavia, questa differenza a livello di frase non migliora la sicurezza complessiva di un wallet Bitcoin, poiché le chiavi private derivate dalla frase beneficiano solo di 128 bit di sicurezza. Come abbiamo infatti visto in precedenza, le chiavi private Bitcoin sono generate da numeri casuali (o derivate da una fonte casuale) compresi tra $1$ e $n-1$, dove $n$ rappresenta l'ordine del punto di origine $G$ sulla curva secp256k1, un numero leggermente inferiore a $2^{256}$. Si potrebbe quindi pensare che queste chiavi private offrano 256 bit di sicurezza, ma la loro sicurezza risiede nella difficoltà di trovare una chiave privata a partire dalla chiave pubblica associata, complessità stabilita dal problema matematico del logaritmo discreto sulle curve ellittiche (_ECDLP_). Ad oggi l'algoritmo più noto per risolvere questo problema è l'algoritmo rho di Pollard, che riduce il numero di operazioni necessarie per violare una chiave alla radice quadrata della sua dimensione. Per le chiavi a 256 bit, come quelle utilizzate su Bitcoin, l'algoritmo rho di Pollard riduce quindi la complessità a $2^{128}$ operazioni:$

O(\sqrt{2^{256}}) = O(2^{128})

 $Ne consegue che una chiave privata utilizzata su Bitcoin offra 128 bit di sicurezza. Scegliere una frase di 24 parole non aggiunge protezione al wallet, poiché i 256 bit di sicurezza della frase sono irrilevanti, se le chiavi derivate offrono solo 128 bit di sicurezza. Per illustrare questo principio, è come avere una casa con due porte: una porta di legno vecchia e una porta blindata. In caso di effrazione la porta blindata non sarebbe di alcuna utilità, poiché un intruso passerebbe attraverso la porta di legno. Questa è una situazione analoga. Una frase di 12 parole, che offre quindi 128 bit di sicurezza, è attualmente sufficiente per proteggere i tuoi bitcoin da qualsiasi tentativo di furto. Finché l'algoritmo di firma digitale non cambia, per utilizzare chiavi più grandi o per affidarsi a un problema matematico diverso da ECDLP, una frase di 24 parole rimane superflua. Inoltre, una frase più lunga aumenta il rischio di perdita durante il backup: un backup che è due volte più corto è sempre più facile da gestire. Per approfondire e imparare concretamente come generare manualmente una frase mnemonica di prova, ti consiglio di scoprire questo tutorial: https://planb.network/tutorials/wallet/backup/generate-mnemonic-phrase-47507d90-e6af-4cac-b01b-01a14d7a8228 Prima di continuare con la derivazione del wallet dalla frase mnemonica, ti presenterò nel capitolo seguente la passphrase BIP39, poiché gioca un ruolo nel processo di derivazione ed è allo stesso livello della frase mnemonica. ## La passphrase <chapterId>6a51b397-f3b5-5084-b151-cef94bc9b93f</chapterId> Come abbiamo appena visto, i wallet HD sono generati da una frase mnemonica che tipicamente consiste di 12 o 24 parole. Questa frase è molto importante perché permette il ripristino di tutte le chiavi di un wallet in caso il dispositivo fisico (come un hardware wallet, ad esempio) venga perso. Bisogna però considerare che costituisce un unico punto di fallimento perché, se viene compromessa, un attaccante potrebbe rubare tutti i bitcoin. Qui entra in gioco la passphrase BIP39. ### Cos'è una passphrase BIP39? La passphrase è una password opzionale, che puoi scegliere liberamente, aggiunta alla frase mnemonica nel processo di derivazione delle chiavi, per migliorare la sicurezza del wallet. Attenzione però: la passphrase non deve essere confusa con il PIN del tuo hardware wallet o la password usata per sbloccare l'accesso al tuo file sul tuo computer. A differenza di tutti questi elementi, la passphrase gioca un ruolo nella derivazione delle chiavi del tuo wallet. **Questo significa che, senza di essa, non sarai mai in grado di recuperare i tuoi bitcoin.** La passphrase lavora in tandem con la mnemonica, modificando il seed da cui vengono generate le chiavi. In questo scenario, anche se qualcuno ottiene la tua frase di 12 o 24 parole, senza la passphrase non può accedere ai tuoi fondi. Usare una passphrase crea essenzialmente un nuovo wallet con chiavi distinte. Modificare (anche leggermente) la passphrase genera un wallet diverso. ![CYP201](/courses/cyp201/assets/fr/041.webp) ### Perché dovresti usare una passphrase? La passphrase è arbitraria e si può comporre con qualsiasi combinazione di caratteri scelta dall'utente. Usare una passphrase offre quindi diversi vantaggi. Prima di tutto, riduce tutti i rischi associati alla compromissione della frase mnemonica richiedendo un secondo fattore per accedere ai fondi (effrazione, accesso alla tua casa, ecc.). Poi può essere usata strategicamente per creare un wallet esca, per affrontare attacchi fisici orchestrati per rubare i tuoi fondi, come il famigerato "_attacco con chiave inglese da 5 dollari_". In uno scenario del genere, l'idea è di avere un wallet senza passphrase contenente solo una piccola quantità di bitcoin, abbastanza per soddisfare un potenziale aggressore, mentre si ha un wallet nascosto. Quest'ultimo utilizza la stessa frase mnemonica ma è protetto con una passphrase aggiuntiva. Infine, l'uso di una passphrase è interessante quando si desidera avere il controllo sulla casualità con cui un wallet HD viene generato. ### Come scegliere una buona passphrase? Affinché la passphrase sia efficace, deve essere sufficientemente lunga e casuale. Come per una password forte, raccomando di scegliere una passphrase il più lunga e casuale possibile, un insieme di lettere, numeri e simboli da rendere inefficace qualsiasi attacco brute force. È inoltre importante salvare correttamente questa passphrase, allo stesso modo della mnemonica. **Perderla significa perdere l'accesso ai propri bitcoin**. Sconsiglio vivamente di ricordarla soltanto a memoria, poiché ciò aumenta in modo irragionevole il rischio di perdita. L'ideale è scriverla su un supporto fisico (carta o metallo) separato dalla frase mnemonica. Questo backup deve ovviamente essere conservato in un luogo diverso da dove si conserva la mnemonica per prevenire che entrambi vengano compromessi simultaneamente. ![CYP201](/courses/cyp201/assets/fr/042.webp) Nella sezione seguente scopriremo come questi due elementi alla base del tuo wallet — la frase mnemonica e la passphrase — vengono utilizzati per derivare le coppie di chiavi usate negli _scriptPubKey_ che bloccano i tuoi UTXO. # Creazione di Wallet Bitcoin <partId>9c25e767-7eae-50b8-8c5f-679d8fc83bab</partId> ## Creazione del Seed e della Chiave Master <chapterId>63093760-2010-5691-8d0e-9a04732ae557</chapterId> Una volta generati la frase mnemonica e la passphrase opzionale, può iniziare il processo di derivazione di un wallet gerarchico-deterministico. La mnemonica viene prima convertita in un seed che costituisce la base di tutte le chiavi del wallet. ![CYP201](/courses/cyp201/assets/fr/043.webp) ### Il Seed di un Wallet HD Lo standard BIP39 definisce il seed come una sequenza di 512 bit, che serve come punto di partenza per la derivazione di tutte le chiavi di un wallet HD. Il seed è derivato dalla frase mnemonica e dalla passphrase opzionale, utilizzando l'algoritmo **PBKDF2** (_Password-Based Key Derivation Function 2_) di cui abbiamo già discusso nel capitolo 3.3. In questa funzione di derivazione, utilizzeremo i seguenti parametri: - $m$ : la frase mnemonica; - $p$ : una passphrase opzionale scelta dall'utente per aumentare la sicurezza del seed. Se non c'è una passphrase, il campo viene lasciato vuoto; - $\text{PBKDF2}$ : la funzione di derivazione con $\text{HMAC-SHA512}$ e $2048$ iterazioni; - $s$: i 512 bit del seed del wallet. Indipendentemente dalla lunghezza della mnemonica scelta (132 bit o 264 bit), la funzione PBKDF2 produrrà sempre un output di 512 bit, pertanto il seed sarà sempre di questa dimensione. ### Schema di Derivazione del Seed con PBKDF2 L'equazione che segue illustra la derivazione del seed dalla frase mnemonica e dalla passphrase:$

s = \text{PBKDF2}_{\text{HMAC-SHA512}}(m, p, 2048)

 $![CYP201](/courses/cyp201/assets/fr/044.webp) Il valore del seed è quindi influenzato dal valore della mnemonica e della passphrase. Cambiando la passphrase si ottiene un seed diverso. Con la stessa frase mnemonica e passphrase, però, viene sempre generato lo stesso seed, poiché PBKDF2 è una funzione deterministica. Questo garantisce che, attraverso i nostri backup, possano essere recuperate le stesse coppie di chiavi. **Nota:** Nel linguaggio comune, il termine "seed" si riferisce spesso, per abuso di linguaggio, alla mnemonica. In assenza di una passphrase, infatti, il seed è semplicemente la codifica della frase mnemonica. Tuttavia, come abbiamo visto nella realtà tecnica dei wallet, il seed e la frase mnemonica sono effettivamente due elementi distinti. Ora che abbiamo il nostro seed possiamo continuare con la derivazione del nostro wallet Bitcoin. ### Master Key e Master Chain Code Una volta ottenuto il seed, il passo successivo nella derivazione di un wallet HD coinvolge il calcolo della chiave privata master e della master chain code, che rappresenteranno il livello 0 del nostro wallet. Per ottenere la chiave privata master e la master chain code, viene applicata al seed la funzione HMAC-SHA512, utilizzando una chiave fissa "_Bitcoin Seed_" identica per tutti gli utenti Bitcoin. Questa costante è scelta per garantire che le derivazioni delle chiavi siano specifiche per Bitcoin. Ecco gli elementi: - $\text{HMAC-SHA512}$: la funzione di derivazione; - $s$: il seed del wallet da 512 bit; - $\text{"Bitcoin Seed"}$: la costante di derivazione comune per tutti i wallet Bitcoin.$

\text{output} = \text{HMAC-SHA512}(\text{"Bitcoin Seed"}, s)

 $L'output di questa funzione è quindi di 512 bit. Viene poi diviso in 2 parti: - I 256 bit a sinistra formano la **chiave privata master**; - I 256 bit a destra formano la **master chain code**. Matematicamente, questi due valori possono essere notati come segue con $k_M$ che rappresenta la chiave privata master e $C_M$ la master chain code:$

k_M = \text{HMAC-SHA512}(\text{"Bitcoin Seed"}, s)_{[:256]}

C_M = \text{HMAC-SHA512}(\text{"Bitcoin Seed"}, s)_{[256:]}

\text{hash} = \text{HMAC-SHA512}(C_{\text{PAR}}, k_{\text{PAR}} \cdot G \Vert i)

 $In questo calcolo osserviamo che la nostra funzione HMAC prende due input: prima la chain code genitore, poi la concatenazione dell'indice con la chiave pubblica associata alla chiave privata genitore. La chiave pubblica genitore è utilizzata perché stiamo cercando di derivare una chiave figlia normale, non una hardened. Ora abbiamo un $\text{hash}$ di 64 byte che divideremo in 2 parti da 32 byte ciascuna: $h_1$ e $h_2$:$

\text{hash} = h_1 \Vert h_2

h_1 = \text{hash}{[:32]} \quad, \quad h_2 = \text{hash}{[32:]}

 $La chiave privata figlia $k_{\text{CHD}}^n$ è quindi calcolata come segue:$

k_{\text{CHD}}^n = \text{parse256}(h_1) + k_{\text{PAR}} \mod n

 $In questo calcolo l'operazione $\text{parse256}(h_1)$ consiste nell'interpretare i primi 32 byte dell'$\text{hash}$ come un intero a 256 bit. Questo numero viene poi sommato alla chiave privata genitore, il tutto preso modulo $n$ per rimanere nell'ordine della curva ellittica, come abbiamo visto nella sezione 3 sulle firme digitali. Pertanto, per derivare una chiave privata figlia normale, sebbene sia utilizzata la chiave pubblica genitore come base per il calcolo negli input della funzione HMAC-SHA512, è sempre necessario avere la chiave privata genitore per finalizzare il calcolo. Da questa chiave privata figlia è possibile derivare la corrispondente chiave pubblica applicando ECDSA o Schnorr, così da ottenere una coppia completa di chiavi. Ne consegue che la seconda parte dell'$\text{hash}$ è semplicemente interpretata come chain code per la coppia di chiavi figlie che abbiamo appena derivato:$

C_{\text{CHD}} = h_2

 $Ecco una rappresentazione schematica della derivazione complessiva: ![CYP201](/courses/cyp201/assets/fr/050.webp) Per una **chiave figlia hardened** ($i \geq 2^{31}$), il calcolo dell'$\text{hash}$ è il seguente:$

\text{hash} = \text{HMAC-SHA512}(C_{\text{PAR}}, 0x00 \Vert k_{\text{PAR}} \Vert i)

 $In questo calcolo osserviamo che la nostra funzione HMAC prende due input: prima la chain code genitore, poi la concatenazione dell'indice con la chiave privata genitore. La chiave privata genitore è utilizzata qui perché stiamo cercando di derivare una chiave figlia hardened. Inoltre un byte pari a `0x00` viene aggiunto all'inizio della chiave, per equalizzare la lunghezza totale e farla corrispondere a quella di una chiave pubblica compressa. Alla fine del calcolo abbiamo un $\text{hash}$ di 64 byte che divideremo in 2 parti da 32 byte ciascuna: $h_1$ e $h_2$:$

\text{hash} = h_1 \Vert h_2

h_1 = \text{hash}[:32] \quad, \quad h_2 = \text{hash}[32:]

 $La chiave privata figlia $k_{\text{CHD}}^h$ viene quindi calcolata come segue:$

k_{\text{CHD}}^h = \text{parse256}(h_1) + k_{\text{PAR}} \mod n

 $Successivamente interpretiamo semplicemente la seconda parte dell'$\text{hash}$ come chain code per la coppia di chiavi figlie che abbiamo appena derivato:$

C_{\text{CHD}} = h_2

 $Ecco una rappresentazione schematica della derivazione complessiva: ![CYP201](/courses/cyp201/assets/fr/051.webp) Possiamo vedere che la derivazione normale e quella hardened funzionano allo stesso modo, con questa differenza: la derivazione normale utilizza come input della funzione HMAC la chiave pubblica genitore, mentre la derivazione hardened utilizza la chiave privata genitore. #### Derivare una chiave pubblica figlia da una chiave pubblica genitore Se conosciamo solo la chiave pubblica genitore $K_{\text{PAR}}$ e la chain code associata $C_{\text{PAR}}$, ovvero una chiave pubblica estesa, è possibile derivare le chiavi pubbliche figlie $K_{\text{CHD}}^n$, ma solo per le chiavi figlie normali (non hardened). Questo principio permette principalmente di monitorare i movimenti di un account in un wallet Bitcoin a partire dall'`xpub` (_watch-only_). Per eseguire questo calcolo determineremo l'$\text{hash}$ con un indice $i < 2^{31}$ (derivazione normale):$

\text{hash} = \text{HMAC-SHA512}(C_{\text{PAR}}, K_{\text{PAR}} \Vert i)

 $Osserviamo in questo calcolo che la nostra funzione HMAC prende due input: prima la chain code genitore, poi la concatenazione dell'indice con la chiave pubblica genitore. Ora abbiamo un $hash$ di 64 byte che divideremo in 2 parti da 32 byte ciascuna: $h_1$ e $h_2$:$

\text{hash} = h_1 \Vert h_2

h_1 = \text{hash}[:32] \quad, \quad h_2 = \text{hash}[32:]

 $La chiave pubblica figlia $K_{\text{CHD}}^n$ viene quindi calcolata come segue:$

K_{\text{CHD}}^n = \text{parse256}(h_1) \cdot G + K_{\text{PAR}}

 $Se $\text{parse256}(h_1) \geq n$ (ordine della curva ellittica) o se $K_{\text{CHD}}^n$ è il punto all'infinito, la derivazione non è valida e si deve scegliere un altro indice. In questo calcolo l'operazione $\text{parse256}(h_1)$ implica che i primi 32 byte dell'$\text{hash}$ siano interpretati come un intero a 256 bit. Questo numero è utilizzato per calcolare un punto sulla curva ellittica attraverso l'addizione e il raddoppio dal punto di origine $G$. Questo punto viene poi aggiunto alla chiave pubblica genitore per ottenere la chiave pubblica figlia normale. Pertanto, per derivare una chiave pubblica figlia normale, sono necessari solo la chiave pubblica genitore e la chain code genitore; la chiave privata genitore non entra mai in questo processo, a differenza del calcolo della chiave privata figlia che abbiamo visto in precedenza. Successivamente la chain code figlia è semplicemente:$

C_{\text{CHD}} = h_2

 $Ecco una rappresentazione schematica della derivazione complessiva: ![CYP201](/courses/cyp201/assets/fr/052.webp) ### Corrispondenza tra chiavi pubbliche e private e chiavi figlie Una domanda che può sorgere è come una chiave pubblica figlia normale, derivata da una chiave pubblica genitore, possa corrispondere a una chiave privata figlia normale derivata dalla corrispondente chiave privata genitore. Questo collegamento è garantito esattamente dalle proprietà delle curve ellittiche. Per derivare una chiave pubblica figlia normale, infatti, HMAC-SHA512 viene applicato nello stesso modo, ma il suo output viene utilizzato diversamente: - **Chiave privata figlia normale**: $k_{\text{CHD}}^n = \text{parse256}(h_1) + k_{\text{PAR}} \mod n$ - **Chiave pubblica figlia normale**: $K_{\text{CHD}}^n = G \cdot \text{parse256}(h_1) + K_{\text{PAR}}$ Grazie alle operazioni di addizione e raddoppio sulla curva ellittica, entrambi i metodi producono risultati omogenei: la chiave pubblica derivata dalla chiave privata figlia è identica alla chiave pubblica figlia derivata direttamente dalla chiave pubblica genitore. ### Riassunto dei tipi di derivazione Per riassumere, ecco i diversi possibili tipi di derivazioni:$

\begin{array}{|c|c|c|c|} \hline \rightarrow & \text{PAR} & \text{CHD} & \text{n/h} \ \hline k_{\text{PAR}} \rightarrow k_{\text{CHD}} & k_{\text{PAR}} & { k_{\text{CHD}}^n, k_{\text{CHD}}^h } & { n, h } \ k_{\text{PAR}} \rightarrow K_{\text{CHD}} & k_{\text{PAR}} & { K_{\text{CHD}}^n, K_{\text{CHD}}^h } & { n, h } \ K_{\text{PAR}} \rightarrow k_{\text{CHD}} & K_{\text{PAR}} & \times & \times \ K_{\text{PAR}} \rightarrow K_{\text{CHD}} & K_{\text{PAR}} & K_{\text{CHD}}^n & n \ \hline \end{array}

 $Per riassumere finora hai imparato a creare gli elementi base del wallet HD: la frase mnemonica, il seed e poi la chiave e la chain code master. In questo capitolo hai anche scoperto come derivare coppie di chiavi figlie. Nel prossimo capitolo esploreremo come queste derivazioni sono organizzate nei wallet Bitcoin e quale struttura seguire per ottenere concretamente gli indirizzi di ricezione così come le coppie di chiavi utilizzate nello *scriptPubKey* e nello *scriptSig*. ## Struttura del wallet e Derivation Path <chapterId>34e1bbda-67de-5493-b268-1fded8d67689</chapterId> La struttura gerarchica dei wallet HD consente l'organizzazione delle coppie di chiavi in vari modi. L'idea è derivare, a partire dalla chiave privata master e dalla master chain code, diversi livelli di profondità (depth). Ogni livello aggiunto corrisponde alla derivazione di una coppia di chiavi figlie da una coppia di chiavi genitore. Nel tempo, diversi BIP hanno introdotto standard per questi percorsi di derivazione, con l'obiettivo di unificare il loro uso attraverso diversi software. In questo capitolo scopriremo il significato di ogni livello di derivazione nei wallet HD, secondo questi standard. ### profondità (depth) di Derivazione in un wallet HD I derivation path sono organizzati in livelli di profondità (depth), che vanno dalla 0, che rappresenta la chiave master e la chain code master, a strati di sottolivelli per derivare gli indirizzi utilizzati per bloccare gli UTXO. I BIP (_Bitcoin Improvement Proposals_) definiscono gli standard per ogni livello, il che aiuta ad armonizzare le pratiche attraverso diversi software di gestione dei wallet. Un derivation path, quindi, si riferisce alla sequenza di indici utilizzati per derivare le chiavi figlie da una chiave master. **profondità (depth) 0: Chiave Master (BIP32)** Questa profondità (depth) corrisponde alla chiave privata master del wallet e alla master chain code. È rappresentata dalla notazione $m/$. **profondità (depth) 1: Purpose, Scopo (BIP43)** Il Purpose determina la struttura logica di derivazione. Per un indirizzo P2WPKH, ad esempio, avrà $/84'/$ a profondità (depth) 1 (secondo BIP84), mentre per un indirizzo P2TR avrà $/86'/$ (secondo BIP86). Questo strato facilita la compatibilità tra wallet, mostrando indici corrispondenti ai numeri dei BIP. In altre parole, una volta che si ha la chiave master e la chain code master, questi servono come coppia di chiavi genitore per derivare una coppia di chiavi figlie. L'indice usato in questa derivazione può essere, ad esempio, $/84'/$ se il wallet è inteso per usare script di tipo SegWit v0. Questa coppia di chiavi è quindi a profondità (depth) 1. Il suo ruolo non è bloccare bitcoin, ma semplicemente servire come punto di passaggio nella gerarchia di derivazione. **profondità (depth) 2: Tipo di Valuta (BIP44)** Dalla coppia di chiavi a profondità (depth) 1 viene eseguita una nuova derivazione per ottenere la coppia di chiavi a profondità (depth) 2. Questa profondità (depth) permette di differenziare gli account Bitcoin da altre criptovalute all'interno dello stesso wallet. Ogni valuta ha un indice unico per garantire la compatibilità tra wallet multi-valuta. Per Bitcoin l'indice è $/0'/$ (o `0x80000000` in notazione esadecimale). Gli indici delle valute sono scelti nell'intervallo da $2^{31}$ a $2^{32}-1$ per garantire una derivazione hardened. Per darvi altri esempi, ecco gli indici di alcune valute: - $1'$ (`0x80000001`) per la testnet di Bitcoin; - $2'$ (`0x80000002`) per Litecoin; - $60'$ (`0x8000003c`) per Ethereum... **profondità (depth) 3: Account (BIP32)** Ogni wallet può essere diviso in diversi account, numerati da $2^{31}$ e rappresentati a profondità (depth) 3 da $/0'/$ per il primo account, $/1'/$ per il secondo, e così via. Generalmente, quando si fa riferimento a una chiave estesa `xpub`, si riferisce a chiavi a questa profondità (depth) di derivazione. Questa separazione in diversi account è opzionale. Ha lo scopo di semplificare l'organizzazione del wallet per gli utenti. In pratica si usa solo un account, di solito il primo per impostazione predefinita. In alcuni casi, tuttavia, se si desidera distinguere chiaramente coppie di chiavi per usi diversi, può risultare utile usare altri account. Ad esempio è possibile creare un account personale e uno professionale a partire dallo stesso seed, con gruppi di chiavi completamente distinti. Tutto ciò si ottiene a questa profondità (depth) di derivazione. **profondità (depth) 4: Chain (BIP32)** Ogni account definito a profondità (depth) 3 è poi strutturato in due chain: - **Chain esterna**: nella chain esterna vengono derivate quelli che sono noti come indirizzi "pubblici". Gli indirizzi di ricezione sono destinati a bloccare UTXO provenienti da transazioni esterne (cioè, originati dalla spesa di UTXO che non ti appartengono). Per dirla semplicemente, questa chain esterna viene utilizzata ogni volta che si desidera ricevere bitcoin. Quando si clicca su "_receive_" nel wallet, è sempre un indirizzo della chain esterna che viene mostrato. - **La chain interna (resto/change)**: Questa chain è riservata per gli indirizzi di ricezione che bloccano bitcoin generati spendendo un UTXO che ti appartiene: in altre parole indirizzi di resto. È identificata dall'indice $/1/$. **profondità (depth) 5: Indice degli Indirizzi (BIP32)** Infine il livello 5, che rappresenta l'ultimo passo della derivazione nel wallet. Sebbene tecnicamente sia possibile continuare all'infinito, gli standard attuali si fermano a questa profondità (depth). Qui vengono derivate le coppie di chiavi che saranno effettivamente utilizzate per bloccare e sbloccare gli UTXO. Ogni indice permette di distinguere tra coppie di chiavi sorelle: il primo indirizzo di ricezione utilizzerà l'indice $/0/$, il secondo l'indice $/1/$, e così via. ![CYP201](/courses/cyp201/assets/fr/053.webp) ### Notazione del Derivation Path Il derivation path è scritto separando ogni livello con una barra ($/$). Ogni barra indica quindi la derivazione di una coppia di chiavi genitore ($k_{\text{PAR}}$, $K_{\text{PAR}}$, $C_{\text{PAR}}$) in una coppia di chiavi figlie ($k_{\text{CHD}}$, $K_{\text{CHD}}$, $C_{\text{CHD}}$). Il numero indicato ad ogni profondità (depth) corrisponde all'indice utilizzato per derivare questa chiave dai suoi genitori. L'apostrofo ($'$) posto alla destra dell'indice indica una derivazione hardened ($k_{\text{CHD}}^h$, $K_{\text{CHD}}^h$). Talvolta questo apostrofo è sostituito da una $h$. In assenza di un apostrofo o di una $h$, si tratta quindi di una derivazione normale ($k_{\text{CHD}}^n$, $K_{\text{CHD}}^n$). Come abbiamo visto nei capitoli precedenti, gli indici delle chiavi hardened partono da $2^{31}$, o `0x80000000` in esadecimale. Quando in un derivation path un indice è seguito da un apostrofo, a $2^{31}$ deve essere aggiunto il numero indicato per ottenere il valore effettivo utilizzato nella funzione HMAC-SHA512. Ad esempio, se il percorso di derivazione specifica $/44'/$, l'indice effettivo sarà:$

i = 44 + 2^{31} = 2,147,483,692

 $In esadecimale, questo è `0x8000002C`. Ora che abbiamo compreso i principi fondamentali dei derivation path, prendiamo un esempio! Ecco il percorso di derivazione per un indirizzo di ricezione Bitcoin:$

m / 84' / 0' / 1' / 0 / 7

\text{HASH160}(K) = \text{RIPEMD160}(\text{SHA256}(K))

 $Prima passiamo la chiave attraverso SHA256: ```text SHA256(K) = C489EBD66E4103B3C4B5EAFF462B92F5847CA2DCE0825F4997C7CF57DF35BF3A ``` Poi passiamo il risultato attraverso RIPEMD160: ```text RIPEMD160(SHA256(K)) = 9F81322CC88622CA4CCB2A52A21E2888727AA535 ``` Abbiamo così ottenuto un hash a 160 bit della chiave pubblica, che costituisce quello che viene chiamato il payload dell'indirizzo. Il payload rappresenta la parte centrale e più importante dell'indirizzo, utilizzato anche nello _scriptPubKey_ per bloccare gli UTXO. Per rendere il payload più facilmente utilizzabile dagli esseri umani, gli vengono aggiunti dei metadati. Il passo successivo prevede la codifica di questo hash in gruppi di 5 bit in decimale. Questa trasformazione decimale sarà utile per la conversione in _bech32_, utilizzato dagli indirizzi post-SegWit. L'hash binario a 160 bit è quindi diviso in 32 gruppi di 5 bit:$

\begin{array}{|c|c|} \hline \text{5 bit} & \text{Decimal} \ \hline 10011 & 19 \ 11110 & 30 \ 00000 & 0 \ 10011 & 19 \ 00100 & 4 \ 01011 & 11 \ 00110 & 6 \ 01000 & 8 \ 10000 & 16 \ 11000 & 24 \ 10001 & 17 \ 01100 & 12 \ 10100 & 20 \ 10011 & 19 \ 00110 & 6 \ 01011 & 11 \ 00101 & 5 \ 01001 & 9 \ 01001 & 9 \ 01010 & 10 \ 00100 & 4 \ 00111 & 7 \ 10001 & 17 \ 01000 & 8 \ 10001 & 17 \ 00001 & 1 \ 11001 & 25 \ 00111 & 7 \ 10101 & 21 \ 00101 & 5 \ 00101 & 5 \ 10101 & 21 \ \hline \end{array}

\begin{array}{|c|c|c|c|c|c|c|c|c|} \hline & 0 & 1 & 2 & 3 & 4 & 5 & 6 & 7 \ \hline +0 & q & p & z & r & y & 9 & x & 8 \ \hline +8 & g & f & 2 & t & v & d & w & 0 \ \hline +16 & s & 3 & j & n & 5 & 4 & k & h \ \hline +24 & c & e & 6 & m & u & a & 7 & l \ \hline \end{array}

P' = P + t \cdot G

 $Dove $G$ è l'origine della curva ellittica utilizzata. Questa operazione produce una nuova chiave pubblica, derivata dalla chiave originale, mantenendo al contempo proprietà crittografiche che ne consentono l'uso. Se non hai bisogno di aggiungere script alternativi (spendendo esclusivamente tramite il _key path_), puoi generare un indirizzo Taproot basato unicamente sulla chiave pubblica presente al livello 5 del tuo wallet. In questo caso, è necessario creare uno script non spendibile per lo _script path_, al fine di soddisfare i requisiti della struttura. Il tweak $t$ viene poi calcolato applicando una funzione di hash etichettata, **`TapTweak`**, sulla chiave pubblica interna $P$:$

t = \text{H}_{\text{TapTweak}}(P)

 $dove: - **$\text{H}_{\text{TapTweak}}$** è una funzione di hash SHA256 etichettata con il tag `TapTweak`. Se non sei familiare con cosa sia una funzione di hash etichettata, ti invito a consultare il capitolo 3.3; - $P$ è la chiave pubblica interna, rappresentata nel suo formato compresso di 256 bit, utilizzando solo la coordinata $x$. La chiave pubblica Taproot $Q$ viene poi calcolata aggiungendo il tweak $t$, moltiplicato per il generatore della curva ellittica $G$, alla chiave pubblica interna $P$:$

Q = P + t \cdot G

 $Una volta ottenuta la chiave pubblica Taproot $Q$, possiamo generare l'indirizzo di ricezione corrispondente. A differenza di altri formati, gli indirizzi Taproot non sono derivati con un hash della chiave pubblica, bensì inserendo la chiave $Q$ in formato grezzo direttamente nell'indirizzo. Per iniziare, estraiamo la coordinata $x$ del punto $Q$ per ottenere una chiave pubblica compressa. Su questo payload si calcola un checksum utilizzando i codici BCH, come per gli indirizzi SegWit v0. Tuttavia il programma utilizzato per gli indirizzi Taproot differisce leggermente. Dopo l'introduzione del formato _bech32_ con SegWit, è stato infatti scoperto un bug: quando l'ultimo carattere di un indirizzo è una lettera `p`, inserire o rimuovere `q` proprio prima di questa `p` non invalida il checksum. Sebbene questo bug non abbia conseguenze su SegWit v0 (grazie a un vincolo di dimensione), potrebbe rappresentare un problema in futuro. Il bug è stato quindi corretto per gli indirizzi Taproot, con il nuovo formato di codifica chiamato "_bech32m_". L'indirizzo Taproot viene generato codificando la coordinata $x$ di $Q$ nel formato _bech32m_, con i seguenti elementi: - **HRP (_Human Readable Part_)**: `bc`, per indicare la Mainnet di Bitcoin; - **La versione**: `1` per indicare Taproot / SegWit v1; - **Il checksum**. L'indirizzo finale avrà quindi il formato: ``` bc1p[Qx][checksum] ``` D'altra parte, se desideri aggiungere script alternativi in aggiunta alla spesa con la chiave pubblica interna (_script path_), il calcolo dell'indirizzo di ricezione sarà leggermente diverso. Dovrai includere l'hash degli script alternativi nel calcolo del tweak. In Taproot, ogni script alternativo, situato alla fine dell'albero di Merkle, è chiamato "foglia" ("leaf"). Una volta scritti i diversi script, alternativi uno all'altro, devi passarli individualmente attraverso una funzione di hash etichettata `TapLeaf`, accompagnata da alcuni metadati:$

\text{h}{\text{leaf}} = \text{H}{\text{TapLeaf}} (v \Vert sz \Vert S)

 $Con: - $v$: il numero di versione dello script (default `0xC0` per Taproot); - $sz$: la dimensione dello script codificato in formato _CompactSize_; - $S$: lo script. I diversi hash dello script ($\text{h}_{\text{leaf}}$) vengono prima ordinati in ordine lessicografico. Poi vengono concatenati a coppie e passati attraverso una funzione hash etichettata `TapBranch`. Questo processo viene ripetuto iterativamente per costruire, passo dopo passo, il Merkle tree:$

\text{h}{\text{branch}} = \text{H}{\text{TapBranch}}(\text{h}{\text{leaf1}} \Vert \text{h}{\text{leaf2}})

 $Proseguiamo quindi concatenando i risultati due a due, passandoli ad ogni step attraverso la funzione hash etichettata `TapBranch`, fino ad ottenere la Merkle root: ![CYP201](/courses/cyp201/assets/fr/066.webp) Una volta calcolata la radice di Merkle $h_{\text{root}}$, possiamo calcolare il tweak. Per farlo, la chiave pubblica interna del wallet $P$ viene concatenata con la radice $h_{\text{root}}$ e il risultato viene passato attraverso la funzione di hash etichettata `TapTweak`:$

t = \text{H}{\text{TapTweak}}(P \Vert h{\text{root}})

 $Infine, come in precedenza, la chiave pubblica Taproot $Q$ viene ottenuta aggiungendo la chiave pubblica interna $P$ al prodotto del tweak $t$ e del punto di origine $G$:$

Q = P + t \cdot G

 $La generazione dell'indirizzo segue quindi lo stesso processo, utilizzando la chiave pubblica grezza $Q$ come payload, insieme ad alcuni metadati aggiuntivi. Ed eccoci! Abbiamo raggiunto la fine di questo corso CYP201. Se hai trovato questo corso utile, ti sarei molto grato se potessi dedicare qualche momento per dare una buona valutazione nel capitolo dedicato. Sentiti libero di condividerlo anche con i tuoi cari o sui tuoi social network. Infine, se desideri ottenere il tuo diploma per questo corso, puoi sostenere l'esame finale subito dopo il capitolo di valutazione. # Conclusione <partId>58111408-b734-54db-9ea7-0d5b67f99f99</partId> ## Recensioni & Valutazioni <chapterId>0cd71541-a7fd-53db-b66a-8611b6a28b04</chapterId> <isCourseReview>true</isCourseReview> ## Esame finale <chapterId>a53ea27d-0f84-56cd-b37c-a66210a4b31d</chapterId> <isCourseExam>true</isCourseExam> ## Conclusione <chapterId>d291428b-3cfa-5394-930e-4b514be82d5a</chapterId> <isCourseConclusion>true</isCourseConclusion>$