in arrivo i computer quantici

[bitcoiner180]

Che saranno necessari due hard fork lo dice Charles Hoskinson che però è il creatore di Cardano    

L'obiettivo di BIP 361 è arrivare alla fase C con due soft fork: il primo rendendo le tx di ricezione (prima) e spesa (dopo) per gli indirizzi vulnerabili non valide e il secondo introducendo nel linguaggio di script  la capacità di verificare le zk proof

Nel primo caso viene introdotto un vincolo in base al quale i miner aggiornati smetteranno di inserire le tx vs quegli indirizzi (o da quegli indirizzi) in un blocco. Se avranno la maggioranza dell'hashrate gli altri miner si accoderanno alla catena più lunga, volenti o nolenti.

Siccome viene aggiunto un vincolo (e non rimosso) si tratta di un soft fork.

Nel secondo caso il possessore dell' indirizzo freezato genererà, a partire dalla private key, una zk proof.
La zk proof è una prova matematica (generata con crittografia post quantistica) che può essere generata solo da chi conosceva la chiave privata.

E' la dimostrazione, da parte di chi la esibisce, che era a conoscenza della chiave privata senza esporre la chiave pubblica (come accade invece nel caso di firma di una transizione).

A quel punto si renderà necessario un secondo soft fork che aggiunge un altro vincolo: quello di permettere ai nodi di verificare la prova e, se riscontrata vera, accettare la transazione come valida.

In sostanza, la zk proof sostituisce la coppia "firma ECDSA+chiave pubblica" nella witness della transazione. E i nodi aggiornati accetteranno quella prova come valida.

La zk proof in sostanza dice questo "Esiste una chiave privata che controlla questi fondi e io la sto usando in questo momento per autorizzare questo specifico spostamento (senza rivelarla). Ecco la prova matematica che non mento".

Per i nodi non aggiornati la tx con zk proof sembrerà una tx strana, senza firma (del tipo "anyone can spend") ma comunque valida. Lo stesso trucco è stato usato per introdurre Segwit (le cui tx agli occhi di un nodo non aggiornato sono senza firma).

Tutti i bitcoin saranno recuperabili a condizione che il proprietario conosca il seed (per i wallet post BIP39) o il vecchio wallet.dat.
Ovviamente i bitcoin persi resteranno freezati per sempre.

Un'attimo però. Sul fatto che il freeze degli indirizzi sia soft fork sono d'accordo. Ho sbagliato prima quando dicevo che era un hard fork.

Il freeze degli indirizzi è perfettamente retrocompatibile con la blockchain attuale: i nodi che non si adeguano continuerebbero a considerare come valida una blockchain dove gli indirizzi ECDSA non vengono mai spesi da nessuno.

Invece un qualsiasi aggiornamento che spende indirizzi ECDSA senza fornire una witness che non è una firma ECDSA è un hard fork, un nodo attuale non potrebbe mai considerare valida una spesa di questo tipo.

Non è lo stesso trucco di Segwit. Con Segwit sono stati introdotti una nuova serie di indirizzi considerati "anyone can spend" dai vecchi nodi ma considerati spendibili dai nuovi nodi solo con apposita firma Segwit.

Segwit è soft fork perché i vecchi nodi considerano valide, anche se "stupide" in quanto spendibili da chiunque, le transazioni verso indirizzi "anyone can spend" e ovviamente considerano sempre valida la spesa da quegli indirizzi pur non ricevendo la firma che i nuovi nodi "nascondono" nella parte segwit.

Invece, qua si parla di considerare come valida una spesa da vecchi indirizzi senza fornire una firma ECDSA valida. Bisogna dare ai vecchi nodi una firma ECDSA valida perché questi considerino valida la spesa degli indirizzi ECDSA e insieme ad essa bisogna consegnare anche la chiave pubblica. Per questo la ZK proof sui vecchi indirizzi non potrà mai essere un soft fork.

L'unico modo per rendere soft fork la ZK proof sugli indirizzi ECDSA è nascondere ai vecchi nodi non solo la firma ZK ma pure la spesa. I vecchi nodi dovrebbero ricevere blocchi al cui interno viene rendicontata la spesa di bitcoin dai vecchi indirizzi ECDSA ma che i vecchi nodi considererebbero come una non-spesa, dati senza alcun valore. Sarebbe possibile?

Con Segwit i vecchi nodi non vedono le firme degli indirizzi "anyone can spend" ma vedono e validano la quantità di bitcoin spesi da quegli indirizzi in quanto questa è sempre rendicontata esplicitamente nella blockchain.

[Plutosky]

Un'attimo però. Sul fatto che il freeze degli indirizzi sia soft fork sono d'accordo. Ho sbagliato prima quando dicevo che era un hard fork.

Il freeze degli indirizzi è perfettamente retrocompatibile con la blockchain attuale: i nodi che non si adeguano continuerebbero a considerare come valida una blockchain dove gli indirizzi ECDSA non vengono mai spesi da nessuno.

Invece un qualsiasi aggiornamento che spende indirizzi ECDSA senza fornire una witness che non è una firma ECDSA è un hard fork, un nodo attuale non potrebbe mai considerare valida una spesa di questo tipo.

Non è lo stesso trucco di Segwit. Con Segwit sono stati introdotti una nuova serie di indirizzi considerati "anyone can spend" dai vecchi nodi ma considerati spendibili dai nuovi nodi solo con apposita firma Segwit.

Segwit è soft fork perché i vecchi nodi considerano valide, anche se "stupide" in quanto spendibili da chiunque, le transazioni verso indirizzi "anyone can spend" e ovviamente considerano sempre valida la spesa da quegli indirizzi pur non ricevendo la firma che i nuovi nodi "nascondono" nella parte segwit.

Invece, qua si parla di considerare come valida una spesa da vecchi indirizzi senza fornire una firma ECDSA valida. Bisogna dare ai vecchi nodi una firma ECDSA valida perché questi considerino valida la spesa degli indirizzi ECDSA e insieme ad essa bisogna consegnare anche la chiave pubblica. Per questo la ZK proof sui vecchi indirizzi non potrà mai essere un soft fork.

L'unico modo per rendere soft fork la ZK proof sugli indirizzi ECDSA è nascondere ai vecchi nodi non solo la firma ZK ma pure la spesa. I vecchi nodi dovrebbero ricevere blocchi al cui interno viene rendicontata la spesa di bitcoin dai vecchi indirizzi ECDSA ma che i vecchi nodi considererebbero come una non-spesa, dati senza alcun valore. Sarebbe possibile?

Con Segwit i vecchi nodi non vedono le firme degli indirizzi "anyone can spend" ma vedono e validano la quantità di bitcoin spesi da quegli indirizzi in quanto questa è sempre rendicontata esplicitamente nella blockchain.

stai descrivendo uno scenario attuale, ma la fase C viene dopo la fase B.

Con quest'ultima, qualsiasi transazione (indipendentemente da dove proviene) con firma ECDSA/Schnorr sarà ritenuta non valida dai nodi aggiornati.
Chiunque è migrato sui PQ address durante la fase A, userà le firme PQ e sarà a posto.
Non ci sarà split della catena, nonostante i vecchi nodi continueranno a propagare le tx ECDSA/Schnorr, a condizione che >50% dell'hashrate sarà composto da miner aggiornati che NON includeranno transazioni ecdsa nei blocchi. Gli altri nodi si accoderanno alla catena più lunga. Un legacy miner, se la maggioranza dei nodi è aggiornato, si vedrebbe rimossa la ricompensa nel caso mettesse tx ecdsa in un blocco.
Con il soft fork della fase C, sarà ammessa la ZK proof come metodo di spesa ulteriore rispetto alla firma PQ. I nodi che non si aggiorneranno a questo ulteriore soft fork vedranno le tx zk proof come anyone can spend e le lasceranno passare.

Non accettare le zk proof comunque non avrebbe senso, dato che si tratta di una operazione fatta solo nell'interesse dei legittimi proprietari.

Molti dei dettagli tecnici di questi ultimi passaggi sono da tutti da definire e progettare ma, dato che la maggioranza dei bitcoin (tutti quelli non persi o dimenticati) saranno nel frattempo passati a PQ e quindi al sicuro, il tempo per definire questa operazione di recupero non mancherà.

Come diceva @gbianchi, il vero problema è a monte: trovare un algoritmo PQ sufficientemente "leggero" da essere compatibile con la dimensione di blocco attuale. Altrimenti l'hard fork dovrà avvenire ben prima, per alzare il tetto, e quello sarebbe un hard fork di sicuro.

[babo]

~~~
Come diceva @gbianchi, il vero problema è a monte: trovare un algoritmo PQ sufficientemente "leggero" da essere compatibile con la dimensione di blocco attuale. Altrimenti l'hard fork dovrà avvenire ben prima, per alzare il tetto, e quello sarebbe un hard fork di sicuro.

Sono convinto che lo troveremo, anzi lo troveranno.
Siamo agli inizi dello studio di algoritmi quantum resistant, quindi sono certo che non mancheranno le ottimizzazioni.
Chiaro ragazzi che non potremo avere il peso delle precedenti, questo ce lo dobbiamo proprio scordare... avremo un compromesso

[Plutosky]

Sono convinto che lo troveremo, anzi lo troveranno.
Siamo agli inizi dello studio di algoritmi quantum resistant, quindi sono certo che non mancheranno le ottimizzazioni.
Chiaro ragazzi che non potremo avere il peso delle precedenti, questo ce lo dobbiamo proprio scordare... avremo un compromesso

sono d'accordo, l'impressione è che, da quando ci hanno buttato la testa i programmatori Bitcoin, il progresso nelle ottimizzazioni software stia procedendo ad un ritmo più veloce del progresso hardware dei pc quantistici.

La struttura di firma PQ più leggera che abbiamo al momento è SHRINCS, che però ha alcune limitazioni (non sarebbe ad esempio possibile usare lo stesso seed su più device e ci sarebbero rischi per la sicurezza con i metodi di backup attuali) In ogni caso SHRINCS ha firme di 324 byte, appena 5x rispetto a Schnorr.
Gli algoritmi ufficiali del NIST, quelli che probabilmente verranno usati nei sistemi centralizzate hanno firme da 2420 byte.

[bitcoiner180]

Con il soft fork della fase C, sarà ammessa la ZK proof come metodo di spesa ulteriore rispetto alla firma PQ. I nodi che non si aggiorneranno a questo ulteriore soft fork vedranno le tx zk proof come anyone can spend e le lasceranno passare.

Ma neanche per sogno. I nodi che non si aggiorneranno a questo ulteriore hard fork vedranno le tx zk proof come transazioni da indirizzi che non sono assolutamente anyone can spend, cioè gli indirizzi attuali (1..., 3..., bc1...), verso altri indirizzi e non le lasceranno passare (cioè non valideranno il blocco che le contiene) in quanto le transazioni da indirizzi attuali (1..., 3..., bc1...) hanno bisogno di una firma ECDSA per essere valide.

Come ho detto il freeze è un soft fork perché una catena dove non vengono mai spesi bitcoin dagli indirizzi attuali (1..., 3..., bc1...) è comunque una catena valida per i nodi che non si adeguano.

Invece la fase C è necessariamente un hard fork perché si vuole consentire la spesa di bitcoin che ora stanno su indirizzi ECDSA (1..., 3..., bc1...) senza fornire una firma ECDSA. Un nodo attuale non potrà mai considerare valida una transazione (e di conseguenza il blocco che la contiene) da un indirizzo ECDSA (1..., 3..., bc1...) verso un altro indirizzo se non ha in mano la coppia "firma ECDSA - chiave pubblica".

[Plutosky]

Con il soft fork della fase C, sarà ammessa la ZK proof come metodo di spesa ulteriore rispetto alla firma PQ. I nodi che non si aggiorneranno a questo ulteriore soft fork vedranno le tx zk proof come anyone can spend e le lasceranno passare.

Ma neanche per sogno. I nodi che non si aggiorneranno a questo ulteriore hard fork vedranno le tx zk proof come transazioni da indirizzi che non sono assolutamente anyone can spend, cioè gli indirizzi attuali (1..., 3..., bc1...), verso altri indirizzi e non le lasceranno passare (cioè non valideranno il blocco che le contiene) in quanto le transazioni da indirizzi attuali (1..., 3..., bc1...) hanno bisogno di una firma ECDSA per essere valide.

Come ho detto il freeze è un soft fork perché una catena dove non vengono mai spesi bitcoin dagli indirizzi attuali (1..., 3..., bc1...) è comunque una catena valida per i nodi che non si adeguano.

Invece la fase C è necessariamente un hard fork perché si vuole consentire la spesa di bitcoin che ora stanno su indirizzi ECDSA (1..., 3..., bc1...) senza fornire una firma ECDSA. Un nodo attuale non potrà mai considerare valida una transazione (e di conseguenza il blocco che la contiene) da un indirizzo ECDSA (1..., 3..., bc1...) verso un altro indirizzo se non ha in mano la coppia "firma ECDSA - chiave pubblica".

Il fatto che i nodi attuali non la considerino valida non ha alcuna rilevanza, come ho già scritto.
Mi sembra di essere entrato in loop e non ho tempo/voglia di argomentare sulla stessa cosa all'infinito:secondo alcuni dei più esperti programmatori è fattibile tramite un soft fork.
A me è chiaro perchè è fattibile.
Se per te non è fattibile, ne prendo atto.
 

[bitcoiner180]

Il fatto che i nodi attuali non la considerino valida non ha alcuna rilevanza, come ho già scritto.

Certo che ha rilevanza, è la differenza tra soft fork e hard fork. Un soft fork è retrocompatibile e viene considerato comunque valido dai nodi vecchi, un hard fork invece viene considerato non valido dai nodi vecchi.

Una transazione che spende UTXO che richiedono una firma ECDSA, senza fornire una firma ECDSA e la chiave pubblica non potrà mai essere considerata valida dai nodi vecchi, per questo lo zk proof sugli indirizzi ECDSA (fase C) è un hard fork.

[Vinsneuve]

Nel bip 0361 mediawiki è scritto chiaramente riguardo al "Backward compatibility" che se la fase C è attivata insieme alla fase B non è necessario l' HARD FORK.

[babo]

Nel bip 0361 mediawiki è scritto chiaramente riguardo al "Backward compatibility" che se la fase C è attivata insieme alla fase B non è necessario l' HARD FORK.

appunto, senza contare che ci stiamo fasciando la testa prima di rompercela

dobbiamovalutare con attenzione e mettere tutto in ordine

1) abbiamo necessita di fare un algo quantum resistant, siamo tutti d'accordo
2) come farlo viene assolutamente dopo

ancora non sappiamo manco quale algo verra usato anche se promettente, e la wiki e' draft

[bitcoiner180]

Nel bip 0361 mediawiki è scritto chiaramente riguardo al "Backward compatibility" che se la fase C è attivata insieme alla fase B non è necessario l' HARD FORK.

Nel bip 361 mediawiki la fase C è stata rimossa
https://github.com/bitcoin/bips/commit/ab2ebe2c5d3593dd1d74e2a13b5b9835ccbf28c0

[bitcoiner180]

Forse penso di aver intuito come poter eventualmente consentire la spesa di indirizzi ECDSA tramite soft fork: oltre a pubblicare la firma ECDSA e la chiave pubblica dell'indirizzo che voglio spendere, costruendo così una transazione valida per i vecchi nodi, devo pubblicare anche una ZK proof che provi che possiedo l'HD wallet (bip32) che ha generato quella chiave pubblica, questa zk proof è necessaria perché i nuovi nodi considerino valida la mia spesa.

In questo modo verrebbero soddisfatte sia le condizioni di spesa per i vecchi nodi che quelle per i nuovi nodi.

Gli indirizzi ECDSA non generati tramite HD wallet (bip32) invece non sarebbero più recuperabili.

[fillippone]

Forse penso di aver intuito come poter eventualmente consentire la spesa di indirizzi ECDSA tramite soft fork: oltre a pubblicare la firma ECDSA e la chiave pubblica dell'indirizzo che voglio spendere, costruendo così una transazione valida per i vecchi nodi, devo pubblicare anche una ZK proof che provi che possiedo l'HD wallet (bip32) che ha generato quella chiave pubblica, questa zk proof è necessaria perché i nuovi nodi considerino valida la mia spesa.

In questo modo verrebbero soddisfatte sia le condizioni di spesa per i vecchi nodi che quelle per i nuovi nodi.

Gli indirizzi ECDSA non generati tramite HD wallet (bip32) invece non sarebbero più recuperabili.

Mi spieghi brevissimamente cosa vuol dire che possiedo l'HD wallet?
Molti indirizzi all'inizio non avevano proprio il BIP32, quindi come fai a provare di avere qualcosa ch non avevi, pur essendo legittimo proprietario delle chiavi? Penso soprattutto alle prime chiavi, tipo Satoshi.

[bitcoiner180]

Mi spieghi brevissimamente cosa vuol dire che possiedo l'HD wallet?
Molti indirizzi all'inizio non avevano proprio il BIP32, quindi come fai a provare di avere qualcosa ch non avevi, pur essendo legittimo proprietario delle chiavi? Penso soprattutto alle prime chiavi, tipo Satoshi.

Qui purtroppo andiamo oltre alle mie conoscenze.

Ovviamente "possedere un HD wallet" significa possedere le famose 12-24 parole, o per la precisione possedere la chiave xprv che viene derivata con quelle 12-14 parole

per esempio queste 12 parole:

Code:

odor guess frequent laundry glass avocado setup diet hamster brain box net

generano questa chiave xprv

Code:

xprvA1Qw3LCBdxccF6wmv98tDc7mRTXLgALA6WJ7BR1MNdmEWsb4oUQUC5dvXrzZM5SbqGsfhhH1MDJBo3kYoiQnDjihaiSuw5YySUie6iTToB5

tramite questa chiave è possibile generare tutte le coppie "chiave privata-chiave pubblica" del proprio wallet.

Per esempio la prima coppia generata con la xprv sopra è la seguente:

• Chiave pubblica: 0327b402156f54a297c6b3ec2fb78814b275c6f7c5102f3dd780ecbaa43ef62436
• Chiave privata: L2wSd2FiV57wnRgqxoa8nejDSTbHAuPRVtkxoXfWeknBBG53Yu9n
• Bonus, chiave pubblica protetta da hash/ripemd: 1Da96S6crkftxdmvnviThYcikdSEJ2KycC
  

Le 12 parole di cui sopra, oltre a generare la chiave xprv generano anche una chiave xpub che consente di generare le chiavi pubbliche senza però riuscire a generare le chiavi private, nel nostro caso la chiave xpub è la seguente:

Code:

xpub6EQHSqj5ULAuTb2F2Aftak4VyVMq5d41TjDhyoQxvyJDPfvDM1iijsxQP6muz96rLcRSTsV64YsDQdvyhmmtmVcgDix89bpCPvg7Z7GF86U

Ma immagino che la tua domanda vada oltre: come si fa a dimostrare che si possiede la chiave xprv che genera l'indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC senza mostrare né la chiave xprv e nemmeno la chiave xpub (che con un computer quantistico potrebbe essere utilizzata per ottenere la chiave xprv)?

Qui entra in gioco la zk proof. Purtroppo non ti so spiegare esattamente come funziona, ho provato a leggere su internet spiegazioni approfondite ma bisogna essere dei geni oppure bisogna aver fatto corsi di laurea avanzati in crittografia o matematica che io non ho fatto.

Posso dunque "fidarmi" delle conclusioni che traggono quelle spiegazioni e farti un esempio che secondo me più o meno spiega come avviene la zk proof:

Tu ti trovi al museo del Louvre e vuoi dimostrarmi che ti trovi li: "filippone si trova al Louvre". Allora ho due tecniche per ottenere la prova di questa affermazione.

La prima è chiederti di mandarmi una tua foto vicino alla Gioconda, questa è una prova che assomiglia alla firma ECDSA: tu usi la tua faccia (che hai solo tu, è la tua chiave privata) per "firmare" la foto della gioconda, in quel modo mi stai dimostrando che sei al Louvre. Al giorno d'oggi però, con la computer grafica (nel caso della ECDSA con i computer quantistici) è facile falsificare una foto del genere, potresti essere a casa tua e falsificare la foto. Inoltre io, devo avere un'idea di come è fatta la tua faccia, devo conoscerti (devo avere la tua chiave pubblica), altrimenti come faccio a sapere che quello nella foto sei tu? Non solo! Tu non vuoi condividere con me nessuna tua foto, vuoi giustamente rimanere l'anonimo "filippone", anche perché sai che se rendi pubblica la tua foto chiunque potrebbe utilizzarla per dimostrare che ti trovi dovunque, per esempio nella stanza del Louvre mentre rubavi i gioielli . E allora come mi dimostri che ti trovi al Louvre?

Beh, ti posso fare delle domande:

• mandami la foto del biglietto con data e ora
• mandami una foto della Gioconda con il pubblico che ovviamente non potrà mai essere lo stesso di quelle che si trovano su internet
• mandami una foto della stanza dove si trovavano i gioielli rubati di recente
• mandami una foto dell'opera d'arte X che so trovarsi vicino alla finestra così verifico che il tempo che c'è fuori è quello di Parigi di oggi
• mandami una foto dell'opera d'arte Y che so trovarsi vicino ad un orologio con calendario così vedo che l'ora e il giorno corrispondono
• in questo momento (sito louvre.fr) c'è un'esposizione temporanea di "Michelangelo e Rodin", mandami una foto di quell'esposizione
• ...

Sarà difficile che tu riesca a falsificare o a recuperare da internet tutte queste foto, se riesci a mandarmele tutte, ho un'ottima sicurezza che tu ti trovi al Louvre. E non devo nemmeno sapere come è fatta la tua faccia!

Ovviamente più domande ti farò e più sarò sicuro che non mi stai fregando. Anzi, tutti qua nel forum saremo sicuri che non ci stai fregando.

Ecco la ZK proof funziona più o meno così, bisogna fornire una serie di risposte ad una serie di domande che, nel caso della ZK-SNARK vengono decise sul momento da un validatore che deve essere affidabile e non d'accordo con te (potremmo metterci d'accordo io e te in anticipo sulle domande, recuperare tutte quelle foto insieme e far credere a tutti che tu ti trovi al Louvre), nel caso della ZK-STARK queste domande sono deterministiche e basate sullo stato attuale del sistema.

La ZK proof non garantisce al 100% che chi risponde alle domande sia onesto ma può garantirlo al 99,999...% con una sicurezza maggiore tanto più sono le domande. Nel caso del Louvre mi sono venute in mente solo 6 domande da farti, nel caso della ZK-STARK o ZK-SNARK si possono sempre produrre un numero grande a piacimento e standardizzabile di domande, basate non sul Louvre ma sull'indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC e alle quali si può rispondere correttamente solo se si conosce la chiave xprv.

[fillippone]

Capito, e non capito.
L'esempio che hai fatto è molto ben strutturato.
In caso di bitcoin c'è poco da fare, la chiave privata è l'unico elemento che può sancire il possesso dei satoshi.
Mi pare molto diffile capire cosa potrebbero essere le "prove alternative". Sto pensando ai miei stessi bitcoin, ad esempio.

[bitcoiner180]

Capito, e non capito.
L'esempio che hai fatto è molto ben strutturato.
In caso di bitcoin c'è poco da fare, la chiave privata è l'unico elemento che può sancire il possesso dei satoshi.
Mi pare molto diffile capire cosa potrebbero essere le "prove alternative". Sto pensando ai miei stessi bitcoin, ad esempio.

I tuoi bitcoin sono associati ad una serie di chiavi pubbliche nascoste tramite hash, solo tu che possiedi le chiavi private di quelle chiavi pubbliche puoi produrre una firma ECDSA valida. Per produrre una firma valida devi ovviamente mostrare a tutti la chiave pubblica e una firma fatta con la rispettiva chiave privata. Con l'avvento dei computer quantistici quella chiave pubblica può essere convertita da un impostore nella chiave privata.

Nel caso degli HD wallet siamo fortunati perché esiste un'altra coppia chiave pubblica-chiave privata che può dimostrare che tu possiedi quei bitcoin ed è la coppia xprv-xpub del tuo HD wallet. Quella dell'esempio che ho fatto sopra. Questa coppia attualmente non ti viene chiesto di mostrarla in pubblico e soprattutto non può essere trovata con un computer quantistico a partire dalla chiave pubblica di un tuo indirizzo bitcoin.

Se tu rendi pubblica la chiave di questo indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC, che sarebbe questa: 0327b402156f54a297c6b3ec2fb78814b275c6f7c5102f3dd780ecbaa43ef62436 nemmeno con un computer quantistico è possibile ottenere la coppia xprv-xpub dell'HD wallet che contiene quell'indirizzo. La coppia "xprv-xpub" continua a rimanere segreta, continui ad avercela solo te, anche con l'avvento dei computer quantistici. La zk proof che si vorrebbe utilizzare nella fase C sfrutta questa cosa: tu pubblicherai la chiave pubblica dell'indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC e la firma ECDSA per rendere felici i vecchi nodi, però ai nuovi nodi dovrai anche rispondere a delle domande alle quali potrai rispondere solo avendo la coppia xprv-xpub che ha generato quell'indirizzo e che non è ottenibile con un computer quantistico.

Se vuoi sapere quali domande e come vengono poste, beh serve un corso di crittografia avanzata, noi mortali possiamo solo fidarci che è possibile generare questo tipo di domande. D'altra parte, io sinceramente non ho ben chiaro nemmeno come può essere prodotta e verificata matematicamente una firma ECDSA. Mi fido del fatto che con la chiave privata si può produrre una firma che può essere verificata tramite chiave pubblica e vice versa tramite chiave pubblica (non ECDSA) si può criptare un messaggio che può essere decriptato solo tramite chiave privata.

[fillippone]

Capito, e non capito.
L'esempio che hai fatto è molto ben strutturato.
In caso di bitcoin c'è poco da fare, la chiave privata è l'unico elemento che può sancire il possesso dei satoshi.
Mi pare molto diffile capire cosa potrebbero essere le "prove alternative". Sto pensando ai miei stessi bitcoin, ad esempio.

I tuoi bitcoin sono associati ad una serie di chiavi pubbliche nascoste tramite hash, solo tu che possiedi le chiavi private di quelle chiavi pubbliche puoi produrre una firma ECDSA valida. Per produrre una firma valida devi ovviamente mostrare a tutti la chiave pubblica e una firma fatta con la rispettiva chiave privata. Con l'avvento dei computer quantistici quella chiave pubblica può essere convertita da un impostore nella chiave privata.

Nel caso degli HD wallet siamo fortunati perché esiste un'altra coppia chiave pubblica-chiave privata che può dimostrare che tu possiedi quei bitcoin ed è la coppia xprv-xpub del tuo HD wallet. Quella dell'esempio che ho fatto sopra. Questa coppia attualmente non ti viene chiesto di mostrarla in pubblico e soprattutto non può essere trovata con un computer quantistico a partire dalla chiave pubblica di un tuo indirizzo bitcoin.

Se tu rendi pubblica la chiave di questo indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC, che sarebbe questa: 0327b402156f54a297c6b3ec2fb78814b275c6f7c5102f3dd780ecbaa43ef62436 nemmeno con un computer quantistico è possibile ottenere la coppia xprv-xpub dell'HD wallet che contiene quell'indirizzo. La coppia "xprv-xpub" continua a rimanere segreta, continui ad avercela solo te, anche con l'avvento dei computer quantistici. La zk proof che si vorrebbe utilizzare nella fase C sfrutta questa cosa: tu pubblicherai la chiave pubblica dell'indirizzo 1Da96S6crkftxdmvnviThYcikdSEJ2KycC e la firma ECDSA per rendere felici i vecchi nodi, però ai nuovi nodi dovrai anche rispondere a delle domande alle quali potrai rispondere solo avendo la coppia xprv-xpub che ha generato quell'indirizzo e che non è ottenibile con un computer quantistico.

Se vuoi sapere quali domande e come vengono poste, beh serve un corso di crittografia avanzata, noi mortali possiamo solo fidarci che è possibile generare questo tipo di domande. D'altra parte, io sinceramente non ho ben chiaro nemmeno come può essere prodotta e verificata matematicamente una firma ECDSA. Mi fido del fatto che con la chiave privata si può produrre una firma che può essere verificata tramite chiave pubblica e vice versa tramite chiave pubblica si può criptare un messaggio che può essere decriptato solo tramite chiave privata.

Ok, ma quello che voglio dire io è che io posso essere il proprietario di bitcoin, senza conoscere la chiave xprv del mio wallet HD. Semplicemente perhè... non la conosco perchè la mia chiave privata è stata creata prima della definizione dello standard BIP32.
Non lo so, mi pare difficile, come è naturale che sia!

[bitcoiner180]

Ok, ma quello che voglio dire io è che io posso essere il proprietario di bitcoin, senza conoscere la chiave xprv del mio wallet HD. Semplicemente perhè... non la conosco perchè la mia chiave privata è stata creata prima della definizione dello standard BIP32.
Non lo so, mi pare difficile, come è naturale che sia!

Esistevano gli HD wallet prima della definizione dello standard BIP32? Sapevo che prima dell'avvento di quello standard un wallet bitcoin era formato da chiavi pubbliche-private generate casualmente, ma forse già allora qualcuno si creava un wallet deterministico "fatto in casa" e fuori standard?

Comunque sì, purtroppo se il proprio wallet non rispetta lo standard BIP32 c'è ben poco da fare. Sicuramente i bitcoin salvati su indirizzi che espongono la chiave pubblica, con l'avvento dei computer quantistici, prima o poi verranno "rubati" (o freezati se passa BIP361). Invece i bitcoin che appartengono ad indirizzi che non fanno parte di un HD wallet BIP32 e che non hanno esposto la chiave pubblica possono essere salvati solamente con un eventuale hard fork che consenta al proprietario di spenderli tramite ZK proof (fatta questa volta utilizzando la chiave privata dell'indirizzo e non la xprv) ma senza accontentare i vecchi nodi, cioè senza esporre la chiave pubblica e fornire una firma ECDSA valida.

[gbianchi]

interessante piccolo conto della serva (non so se qualcun altro l'ha fatto):

attualmente ci sono circa 56 milioni di indirizzi con saldo, che quindi andranno trasformati in nuovi indirizzi PQ.

considerando che attualmente bitcoin ha una banda di circa 7 transazioni al secondo, supponiamo che con gli indirizzi PQ possa farne 3
(stima che credo estremamente ottimistica)

Ebbene, per convertire tutti gli address al nuovo tipo, usando tutta la rete SOLO per fare questa operazione conversione ECDSA->PQ,
quindi non lasciando banda per nessun  altro tipo di operazione servirebbero piu' di 200 giorni....

In pratica vi sara' un periodo lunghissimo di rete intasatissima, con fee alle stelle, ammesso che il tutto sia sostenibile.

Se uno ha un address ECDSA con una somma "piccola" probabilmente non gli sara' neppure conveniente passare a PQ,
ossia la soglia del DUST si spostera' molto in alto.

Questo vuol dire che conviene conglobare i BTC ora che le fee sono basse?
Ma questo pero' potrebbe cozzare con il problema della privacy delle transazioni (magari uno li teneva separati APPOSTA)

Insomma i tradeoff da considerare saranno veramente molti e di svariata natura.

[Plutosky]

In pratica vi sara' un periodo lunghissimo di rete intasatissima, con fee alle stelle, ammesso che il tutto sia sostenibile.

Questo secondo me è un pò prematuro per dirlo.
Oggi la rete Bitcoin gestisce ~550k transazioni al giorno con fees microscopiche (sui 400 satoshi/tx in media), grazie a tutte le migliorie e alla fine del delirio Rune+Ordinals.
Anche se le fees medie  quadruplicassero o quintuplicassero parliamo sempre di poco più di 1 dollaro ai prezzi attuali.
La transazione vs i PQ si svolgerà in un periodo di anni, quindi ognuno potrà trovare il momento giusto di "stanca" della rete per spedire.
Se inoltre è vero che il 20% dei bitcoin sono persi per sempre, una discreta fetta non si muoverà nemmeno.

[bitcoiner180]

interessante piccolo conto della serva (non so se qualcun altro l'ha fatto):

attualmente ci sono circa 56 milioni di indirizzi con saldo, che quindi andranno trasformati in nuovi indirizzi PQ.

considerando che attualmente bitcoin ha una banda di circa 7 transazioni al secondo, supponiamo che con gli indirizzi PQ possa farne 3
(stima che credo estremamente ottimistica)

Ebbene, per convertire tutti gli address al nuovo tipo, usando tutta la rete SOLO per fare questa operazione conversione ECDSA->PQ,
quindi non lasciando banda per nessun  altro tipo di operazione servirebbero piu' di 200 giorni....

In pratica vi sara' un periodo lunghissimo di rete intasatissima, con fee alle stelle, ammesso che il tutto sia sostenibile.

Se uno ha un address ECDSA con una somma "piccola" probabilmente non gli sara' neppure conveniente passare a PQ,
ossia la soglia del DUST si spostera' molto in alto.

Questo vuol dire che conviene conglobare i BTC ora che le fee sono basse?
Ma questo pero' potrebbe cozzare con il problema della privacy delle transazioni (magari uno li teneva separati APPOSTA)

Insomma i tradeoff da considerare saranno veramente molti e di svariata natura.

L'analisi che hai fatto è molto interessante.

Aggiungo una cosa a riguardo: la ZK proof, come abbiamo detto sopra, potrebbe forse essere eventualmente utilizzata per recuperare bitcoin depositati su indirizzi non quantum resistant, ma al di là del tema (secondo me marginale) del recupero dei vecchi bitcoin, la ZK proof potrebbe essere utilizzata anche per introdurre nuovi indirizzi quantum resistant che utilizzano la prova a conosenza zero per validare le transazioni al posto di usare la firma digitale.

La ZK proof ha una caratteristica che può essere vista sia come pro che come contro.

Per fornire una prova a conscenza zero convincente (abbiamo detto che le prove a conoscenza zero non danno garanzia 100% che chi fornisce la prova non sia un impostore ma possono darla al 99,99..%: a più domande viene data risposta meno è probabile che ci si trovi di fronte ad un impostore) è necessario fornire una risposta ad un grande numero di domande, queste risposte occupano molto spazio, molto di più delle firme che verrebbero fornite con gli algoritmi quantum resistant che non sfruttano la consocenza zero.

Tuttavia, a differenza degli algoritmi che utilizzano la firma digitale, è possibile unificare le prove a conoscenza zero di un gruppo di transazioni (per esempio un gruppo di transazioni contenute in un blocco) in un'unica prova, recuperando molto spazio. Per esempio un miner o qualcuno che lo supporta, potrebbe raccogliere un certo numero di transazioni e invece di pubblicare un blocco contenente tutte le loro prove a consocenza zero che occuperebbero una marea di spazio, le potrebbe unificare in un unica prova che valida da sola tutto il grupo di transazioni e pubblicare un blocco che contiene quel'unica prova. La cosa più bella è che non è richiesto che l'entità che unifica le prove a consocenza zero sia affidabile, tale entità non è matematicamente in grado di fornire un'unica prova a conscenza zero che valida tutte le transazioni del gruppo senza avere prima in mano le singole prove a consocenza zero di ogni transazione.

Questa tecnica di raggruppare le prove a conoscenza zero in una unica ha un grosso costo computazionale (parecchi secondi) che tra l'altro non può essere svolto con le caratteristiche hardware che hanno le ASIC create appositamente per fare mining, tuttavia teoricamente potrebbe dare la possibilità di creare un'unica prova della autenticità di tutte le transazioni (a conoscenza zero) contenute in un blocco occupando poco spazio, probabilmente molto meno di quello che sarebbe occupato se tutte quelle transazioni fossero firmate digitalmente con algoritmi quantum resistant.

E qua introduco un'altro tema rognoso per il passaggio alla crittografia post quantica: quanto costerà computazionalmente validare le firme digitali quantum resistant e/o le varie prove a conoscenza zero? Un nodo potrà continuare a girare su un'economico e casalingo Raspberry Pi?