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

Bitcoin Magazine

[[alloc] init] presenta la proposta Shielded Bitcoin per transazioni Bitcoin private

Shielded Bitcoin è una proposta avanzata dai ricercatori di [[alloc] init] Clara Shikhelman, Misha Komarov e Aleksei Moskvin per un nuovo metaprotocollo per la privacy sul livello base di Bitcoin, che consente transazioni Bitcoin schermate senza richiedere operatori, soft fork o altre modifiche al consenso di Bitcoin. Puoi trovare il white paper qui e l’annuncio sul blog qui.

Il protocollo definisce una struttura transazionale e un protocollo di indicizzazione per transazioni che tutelano fortemente la privacy, facendo affidamento sui PIPE di Bitcoin per trasferire fondi dentro e fuori dal sistema. Maggiori informazioni sul meccanismo dei PIPE alla fine dell’articolo.

Il suo design rispecchia in larga misura quello di Bitcoin: esiste un equivalente di un UTXO (una nota); le transazioni utilizzano note come input, proprio come una normale transazione Bitcoin; una prova dimostra che gli input utilizzati sono debitamente autorizzati; i nodi (gli indicizzatori, nel caso di un metaprotocollo) analizzano la cronologia delle transazioni e ricostruiscono lo stato corrente delle monete spese e non spese, ecc.

Tutti i dettagli, tuttavia, sono piuttosto diversi.

Una transazione Shielded Bitcoin è semplicemente un blocco di dati con un prefisso (qualcosa come «shbtc:») incluso in una transazione Bitcoin tramite OP_RETURN, il campo witness o un altro metodo per trasportare dati. Per Bitcoin non ha alcun significato: la rete Bitcoin non fa nulla per verificarla né per applicare alcuna regola nei suoi confronti. È perfettamente possibile che transazioni Shielded Bitcoin non valide finiscano on-chain; spetta a un indicizzatore Shielded Bitcoin, che osserva passivamente la blockchain (cioè un nodo), ignorare queste transazioni quando non superano la convalida e rifiutarsi di applicarle all’aggiornamento dello stato dei saldi della rete.

Un indicizzatore non elimina le note da un insieme di note non spese, come fa Bitcoin con gli UTXO. Usa invece un insieme di nullifier. In questo modo, un utente può pubblicare una prova crittografica e un nullifier, rendendo noto che una nota è stata spesa senza rivelare quale nota è stata spesa. L’idea è che, invece di controllare se una nota si trova nell’«insieme delle note non spese», si verifichi se un nullifier è già stato utilizzato. Gli indicizzatori costruiscono un albero di Merkle che cresce all’infinito e al quale si possono solo aggiungere elementi: contiene ogni output di nota creato e, poi, l’insieme dei nullifier.

Per usare questo protocollo, ti servono solo un nodo Bitcoin e un indicizzatore Shielded Bitcoin. Non occorrono fornitori di servizi, coordinatori o dati di stato off-chain per recuperare i fondi. Funziona proprio come Bitcoin on-chain: ti bastano il tuo nodo, l’indicizzatore e le tue chiavi.

Ogni wallet utente deriva una chiave segreta principale, dalla quale vengono create tutte le altre serie di chiavi coinvolte.

Pensala in modo molto simile a un wallet HD di Bitcoin. Puoi generare molte serie di indirizzi con questa relazione. Sk_spend è la tua chiave privata, la sk_nf viene utilizzata per invalidare gli output delle note, la vk_in viene utilizzata per decrittare e visualizzare le note in entrata, la vk_out per visualizzare le tue transazioni in uscita, e la sk_view viene utilizzata per generare un indirizzo di ricezione.

Quando un utente vuole fornire a qualcuno un indirizzo a cui inviargli fondi, genera un valore diversificatore g simile a un valore di derivazione, quindi moltiplica il valore per la propria sk_viewchiave pubblica risultante, pk_d e g è l’indirizzo dell’utente.

Il mittente genera quindi un valore casuale, il r_seed, necessario sia per la cifratura dell’output della nota sia per la generazione del nullifier (ci arriviamo tra un attimo). Gli output delle transazioni contengono solo tre elementi cifrati: il valore dell’output, il g valore fornito dal destinatario al mittente e il valore r_seed del mittente. Il mittente usa una coppia di chiavi effimera segreta 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 parte. L’output della nota viene cifrato usando questo segreto condiviso e la chiave effimera sk_eph viene inclusa in chiaro affinché il destinatario possa generare il segreto condiviso.

Per l’input, come mostrato nell’immagine, servono due elementi 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 noti, nell’immagine sopra il nullifier usa la chiave sk_nf e il valore ρ derivato da r_seed, e la posizione della nota nell’albero Merkle degli output delle note. La prova a conoscenza zero garantisce tutto questo, ed è per questo che puoi semplicemente contare i nullifier per rilevare le ripetizioni, invece di eliminare le note spese. Anche se non puoi mai sapere a quale output di nota corrisponde un nullifier, le prove a conoscenza zero presenti in ogni transazione garantiscono che ciascun nullifier aggiunto all’insieme provenga da un output di nota valido. Finché non ci sono ripetizioni, offre la stessa garanzia contro la doppia spesa.

Ecco fatto: il protocollo ti consente di incorporare di fatto transazioni cifrate del metaprotocollo nella blockchain di Bitcoin, garantendo comunque che nulla venga speso due volte e che le monete non vengano create dal nulla.

Si tratta di un sistema progettato molto bene dal punto di vista della privacy, paragonabile ai pool schermati di Zcash. Al momento di entrare e uscire dal metaprotocollo occorre tenere conto di alcune considerazioni relative alla privacy, che saranno approfondite in un prossimo articolo. Non c’è da preoccuparsi di misurare la privacy o di effettuare remix periodici, come nel caso dei coinjoin.

Dunque, il peg. L'obiettivo è realizzare un peg usando PIPEs v2, uno schema di cifratura a testimonianza. PIPEs consente di cifrare una chiave privata con un programma/meccanismo che non rivelerà la chiave a meno che non si possa fornire una prova ZK del verificarsi di una determinata condizione (ad esempio, lo stato di un UTXO, la conferma di una transazione ecc.). Ciò consentirebbe al peg di funzionare senza operatori, federazioni o terze parti che custodiscano i fondi.

Non sono necessari soft fork né modifiche al protocollo Bitcoin, e il tutto avviene interamente off-chain.

Il piano per Shielded Bitcoin, e la fase successiva del loro lavoro, prevede un meccanismo di peg che consenta agli utenti di depositare fondi in Shielded Bitcoin usando chiavi controllate crittograficamente da PIPEs, che verrebbero poi «sbloccate» generando una prova ZK di transazioni di peg-out legittime confermate on-chain.

È attualmente in corso la stesura del documento che definisce questo aspetto del sistema, che dovrebbe essere pubblicato a breve.

Questo post [[alloc] init] Releases Shielded Bitcoin Proposal For Private Bitcoin Transactions è apparso per la prima volta su Bitcoin Magazine ed è scritto da Shinobi.

Fonte: BitcoinMagazine