[[alloc] init] pubblica una proposta di Bitcoin schermato per transazioni Bitcoin private

Dettagli

Shielded Bitcoin, una proposta di [[alloc] init], consentirebbe transazioni Bitcoin con una forte privacy.

Shielded Bitcoin è una proposta avanzata dai ricercatori di [[alloc] init] Clara Shikhelman, Misha Komarov e Aleksei Moskvin per un nuovo metaprotocollo di privacy sul layer di base di Bitcoin, volto a consentire transazioni Bitcoin schermate senza richiedere operatori, soft fork o altre modifiche al consenso di Bitcoin. Potete trovare il whitepaper qui e l'annuncio sul blog qui. 

Il protocollo definisce una struttura transazionale e un protocollo di indicizzazione per transazioni con forte tutela della privacy, affidandosi alle PIPE di Bitcoin per ancorare i fondi in entrata e in uscita dal sistema. Maggiori dettagli sul meccanismo delle PIPE alla fine dell'articolo. 

Il suo design rispecchia molto quello di Bitcoin; esiste un equivalente di un UTXO (una nota), le transazioni consumano note come input proprio come una normale transazione Bitcoin, un witness dimostra che gli input consumati sono debitamente autorizzati, i nodi (indexer nel caso di un metaprotocollo) analizzano la cronologia delle transazioni e costruiscono uno stato corrente di quali monete sono spese e non spese, ecc. 

Tutti i dettagli, tuttavia, sono piuttosto diversi. 

Una transazione Shielded Bitcoin è semplicemente un blob di dati con un prefisso (qualcosa come "shbtc:") incluso in una transazione Bitcoin tramite OP_RETURN, il campo witness o qualche altro metodo di trasporto dati. Non ha alcun significato per Bitcoin, la rete Bitcoin non fa nulla per verificarla né impone alcuna regola al riguardo. È perfettamente possibile che transazioni Shielded Bitcoin non valide finiscano on-chain, ed è compito di un Shielded Bitcoin Indexer, che osserva passivamente la blockchain (leggi: nodo), ignorare quelle transazioni quando non superano la validazione e rifiutarsi di applicarle all'aggiornamento dello stato dei saldi di rete. 

Un indexer non elimina le note da un insieme di note non spese come fa Bitcoin con gli UTXO. Utilizza un insieme di nullifier. Questo è un modo per un utente di pubblicare pubblicamente una prova crittografata e un nullifier che una nota è stata spesa senza rivelare quale nota è stata spesa. L'idea è che, invece di verificare se una nota è nell'"insieme di note non spese", si controlla se un nullifier è già stato utilizzato. Gli indexer costruiscono un albero di Merkle che cresce per sempre, e al quale si può solo aggiungere, di ogni output di nota creato, e poi l'insieme dei nullifier. 

Per utilizzare questo protocollo, tutto ciò che serve è un nodo Bitcoin e un indexer Shielded Bitcoin. Non c'è bisogno di un fornitore di servizi, di un coordinatore o di alcuno stato off-chain per recuperare i fondi. Funziona proprio come Bitcoin on-chain, tutto ciò che serve è il proprio nodo/indexer e le proprie chiavi. 

Ogni portafoglio utente deriva una chiave segreta master, dalla quale viene creato ogni altro insieme di chiavi coinvolto.

Pensate a questo in modo molto simile a un portafoglio HD in Bitcoin. Potete generare molti insiemi di indirizzi con questa relazione. Skspend è la vostra chiave privata, la sknf è usata per annullare gli output delle note, la vkin è usata per decifrare e visualizzare le note in arrivo, la vkout per visualizzare le vostre transazioni in uscita e la sk_view è usata per generare un indirizzo di ricezione. 

Quando un utente vuole dare un indirizzo a qualcuno per inviargli fondi, genera un valore diversifier d simile a un valore di derivazione, e poi moltiplica il valore per la propria chiave skview. La chiave pubblica risultante, pkd e d sono l'indirizzo dell'utente. 

Il mittente genera quindi un valore casuale, il rseed, necessario per la crittografia dell'output della nota così come per l'annullamento (ci arriveremo tra un secondo). Gli output delle transazioni contengono solo tre elementi crittografati: il valore dell'output, il valore d che il destinatario ha dato al mittente e il valore rseed del mittente. Il mittente usa una coppia di chiavi effimere segrete e la chiave pubblica del destinatario per creare un segreto condiviso. Entrambe le parti possono generare lo stesso segreto moltiplicando la propria chiave privata per la chiave pubblica dell'altra. L'output della nota è crittografato usando questo segreto condiviso, e la sk_eph effimera è inclusa non crittografata in modo che il destinatario possa generare il segreto condiviso. 

Sul lato degli input, sono necessarie due cose per avere una transazione valida: un nullifier pubblico per gli output delle note consumati, e una prova a conoscenza zero che dimostri che 1) l'output della nota è incluso nell'albero di Merkle delle note, 2) la transazione è autorizzata dalla chiave sk_spend appropriata, 3) il nullifier è derivato correttamente, e 4) non si è verificata alcuna inflazione. 

Se notate nell’immagine sopra, il nullifier usa la chiave sknf, il valore ρ derivato da rseed e la posizione della nota nell’albero di Merkle degli output delle note. La prova a conoscenza zero garantisce tutto questo, ed è per questo che potete semplicemente contare i nullifier per individuare le ripetizioni invece di eliminare le note spese. Anche se non sapete mai a quale output di nota corrisponda un nullifier, le prove a conoscenza zero in ogni transazione garantiscono che ogni nullifier aggiunto all’insieme provenga da un output di nota valido. Finché non ci sono ripetizioni, offre la stessa garanzia anti doppia spesa. 

Ecco quindi che il protocollo vi consente essenzialmente di incorporare transazioni metaprotocollo cifrate sulla blockchain di Bitcoin, pur fornendo comunque la garanzia che nulla venga speso due volte e che le monete non vengano gonfiate dal nulla. 

Si tratta in realtà di un sistema molto ben progettato in termini di proprietà di privacy, ed è paragonabile a qualcosa come i pool schermati di Zcash. Ci sono considerazioni sulla privacy da tenere in conto al momento di entrare e uscire dal metaprotocollo, e queste saranno dettagliate in un prossimo paper. Non c’è alcuna preoccupazione di misurare la privacy o di rimixing periodico come con i coinjoin. 

Quindi, il peg. L’intento è costruire un peg usando PIPEs v2, uno schema di crittografia witness. Le PIPEs consentono di cifrare una chiave privata con un programma/meccanismo che non rivelerà la chiave a meno che non siate in grado di fornire una prova ZK che una certa condizione sia stata soddisfatta (cioè lo stato di qualche UTXO, che una transazione sia stata confermata, ecc.). Ciò permetterebbe a un peg di funzionare senza un operatore, una federazione o qualsiasi terza parte che custodisca i fondi. 

Questo non richiede softfork o modifiche al protocollo di Bitcoin, e avviene interamente off-chain. 

Il piano con Shielded Bitcoin, e la parte successiva del loro lavoro, è un meccanismo di pegging che consenta agli utenti di depositare fondi in Shielded Bitcoin usando chiavi controllate crittograficamente tramite PIPEs, che verrebbero poi “sbloccate” generando una prova ZK di transazioni di peg out legittime confermate on-chain. 

Il lavoro sul paper che definisce questo aspetto del sistema è attualmente in corso, e dovrebbe essere pubblicato nel prossimo futuro.

La questione quantistica: non si conosce mai davvero il futuro

L’ex commissario della CFTC Giancarlo: perché i rialzi dei tassi potrebbero avvantaggiare Bitcoin

James Seyffart di Bloomberg: perché migliaia di miliardi di ricchezza dei consulenti potrebbero confluire in Bitcoin

Brent Johnson: BTC il miglior asset “pure play” per la crescente liquidità globale

Il prezzo di Bitcoin scivola mentre i rendimenti dei Treasury USA salgono e i prezzi del petrolio aumentano

Guarda in diretta, recupera gli episodi e ottieni contenuti esclusivi in mobilità.

Bitcoin Magazine è pubblicato da BTC Inc., una sussidiaria di Nakamoto Inc. (NASDAQ: NAKA).

Monete correlate

BTC

Fonte

Bitcoin Magazine RSS