Un hash pointer viene creato a partire dal valore dell'hash di un dato e viene usato per identificare lo stesso in maniera univoca. In altre parole un hash pointer punta al blocco che hashato lo ha prodotto. Un esempio di struttura dati che utilizza questo tipo di puntatori è la blockchain. Si tratta di una lista concatenata, in cui ogni blocco contiene un riferimento a quello precedente includendo il suo hash. Il vantaggio dell'utilizzo di questo tipo di puntatore è che garantisce l'integrità del dato: se un nodo della lista, ad esempio, venisse modificato, sarebbe estremamente facile accorgersene, in quanto l'hash pointer non corrisponderebbe più con il valore hashato del blocco a cui puntava.
-
Qual è la differenza tra hot e cold storage?
- Per motivi principalmente di sicurezza, è preferibile mantenere la chiave segreta in uno storage che sia quanto estremamente difficile da compromettere. Mantenere questo storage offline riduce la possibilità di attacco, ma rende più scomodo l'utilizzo della chiave segreta per firmare nuove transazioni. Un compromesso è quello di utilizzare due wallet, uno hot, connesso e facilmente accessibile, da usare solo per effettuare pagamenti verso l'esterno e con un saldo che, in ogni momento, è pari allo stretto necessario per effettuare queste transazioni, mentre l'indirizzo associato con la chiave mantenuta in cold storage è usato per ricevere pagamenti, e mantiene il saldo completo dell'utente.
-
Spiegare il concetto di Hierarchical Wallet
- Per poter produrre comodamente un numero arbitrario di coppie di chiavi sk-pk una possibile soluzione è utilizzare un wallet gerarchico. L'idea è quella di generare inizialmente una coppia chiave privata-pubblica a cui affiancare un'informazione aggiuntiva che permetta di generare, in maniera indipendente, la i-esima chiave pubblica o privata. Ovviamente si ha la garanzia che la i-esima chiave pubblica abbia come chiave privata la i-esima chiave privata e viceversa. Ad un osservatore esterno tutte le chiavi generate non hanno alcuna relazione fra di loro, permettendo di migliorare lo pseudo anonimato. Viene inoltre garantito il fatto che anche compromettendo una delle chiavi segrete generate con questo metodo, la chiave segreta generatrice non viene compromessa. Persino rivelando l'informazione aggiuntiva che permette di generare le molteplici chiavi lo schema rimane sicuro, sebbene, con quella conoscenza si è in grado di tracciare tutte le chiavi ad uno stesso wallet gerarchico.
-
Spiegare come realizzare un Hierarchical Wallet usando firme EC-DSA
- Nella fase di inizializzazione sono realizzate una coppia di chiavi tradizionale ECDSA tradizionale
$(sk, pk) = (x, x\times G)$ , a cui però viene affiancata un'informazione aggiuntiva$w$ . Utilizzando le chiavi iniziali più questo valore è possibile produrre la i-esima coppia come segue:$(sk_i, pk_i) = (sk + H(w||i), H(w||i) \times G + pk)$ . Si noti che la i-esima chiave privata è legata alla i-esima chiave pubblica con la relazione abiutale. Infatti, ricordando che$sk_i = sk + H(w||i)$ , si noti che$pk_i = H(w||i) \times G + sk \times G = sk_i \times G $
- Nella fase di inizializzazione sono realizzate una coppia di chiavi tradizionale ECDSA tradizionale
3) Supponiamo che Alice voglia comprare un contenuto digitale (ad esempio un libro digitale) da un online store e che voglia pagare in Bitcoin. Supponiamo che lo store invii il contenuto in questione ad Alice un minuto dopo aver visto la transazione di pagamento apparire sul blockchain. Spiegare perché una tale strategia rappresenti un forte rischio per lo store.
Sulla blockchain di Bitcoin il tempo medio di creazione di un blocco è di 10 minuti. Il che vuol dire che, dopo il minuto atteso dallo store, non è presente nemmeno un blocco sopra quello che contiene la transazione effettuata da Alice. Il motivo per cui questo è un rischio è perché Alice potrebbe ad esempio pubblicare due transazioni che, partendo dallo stesso input, sono diretti a due destinatari diversi. Questo tentativo di double spending è scongiurato dal protocollo di consenso, ma in un primo momento è possibile che entrambe le transazioni siano state accettate e aggiunte alla blockchain da due miner differenti che hanno prodotto due blocchi diversi. Per il principio per il quale solo la catena più lunga viene proseguita, e per il fatto che le due transazioni sono incompatibili fra di loro, solo uno dei due blocchi farà parte della catena man mano che questa si allunga, mentre l'altro verrà eliminato e sarà trattato come se non fosse mai esistito. Lo store non ha modo di proteggersi da questo tipo di rischio se non aspettando che almeno un 6 blocchi non siano stati prodotti a ridosso di quello che contiene la transazione interessata. A quel punto è possibile affermare con ragionevole sicurezza che la transazione è definitiva.
4) Si spieghi perché Bitcoin non garantisce anonimato, spiegando anche che cosa si intende per ”pseudonymity”
Con pseudoanonymity si intente la possibilità di utilizzare pseudonimi, cioè identità che non corrispondono con quella reale dell'utente.
Sebbene da solo un indirizzo pubblico sulla blockchain da solo non contenga alcuna informazione che permetta di risalire al suo proprietario, bisogna ricordare che le transazioni associate a quell'indirizzo saranno pubblicamente visibili e consultabili. Quindi, studiando con attenzione le azioni intraprese da quel particolare indirizzo e gli altri indirizzi con cui interagisce, potrebbe essere possibile risalire all'identità dell'utente che lo possiede. Motivo per il quale è considerata una buona pratica quella di generare una nuova coppia di chiavi per ogni transazione, operazione resa più pratica dai wallet gerarchici, in modo da rende più difficile questo tipo di analisi e conseguente tracciamento.
5) Sia $H : D \rightarrow R$ una funzione hash crittografica (ad es. SHA256) e si consideri il seguente sistema proof of work. Dato un parametro di difficoltà $k$ , l’obbiettivo è calcolare $H^{(k)}(\text{prev-hash} || tx || ... || tx)$ , dove $H^{(k)}(x) = H(H(...H(x)...))$ , $k$ volte prima degli altri. É questo un buon sistema per implementare proof of work? Giustificare la risposta fornita.
Il sistema proposto non è un buon sistema per implementare la Proof of work, poichè si tratta di un lavoro sequenziale privo di qualsiasi elemento di casualità. Un miner con potenza di calcolo superiore, anche di pochissimo, rispetto agli altri avrebbe la certezza di vincere ogni volta. Ciò ovviamente viola il principio di decentralizzazione e di "one CPU one VOTE" su cui si basano le criptovalute, e il destino delle transazioni sarebbe alla mercé del volere di quell'unico miner. Come se non bastasse, la complessità necessaria per la verifica, che ogni nodo compierebbe per verificare che il miner ha svolto correttamente il lavoro coinciderebbe con quella del lavoro stesso.