in arrivo i computer quantici

[Italian Panic]

Vero Niekko, c'era questo sistema multi core che in quell'era non era ancora stato inserito nel client originale, agivano in parallelo come tanti core su una unica macchina e non come macchine singole. Infatti il nonce era molto ben organizzato e ottimizzato, infatti aveva un fingerprint tra 0 e 9 e tra 19 e 58 come ultimo byte.

Comunque negli address di Finney negli ultimi anni ci sono stati movimenti, indice che gli eredi spostano btc onchain e potrebbero avere accesso anche a quelli. Loro come anche qualcun'altro che compone il gruppo Satoshi. Potrebbero anche aver volutamente disperso le chiavi private e a quel punto è giusto che restino li e se qualcuno li prende sono suoi, è il concetto base di not your keys, not your money.

[Plutosky]

L'opinione di Gregory Maxwell, storico sviluppatore Bitcoin, sulle firme post quantistiche:

https://news.ycombinator.com/item?id=47666753

Riassumendo:

Introdurre un nuovo schema di firma è banale ed è già stato fatto: oggi B. supporta Schnorr oltre ECDSA

Il problema è che Bitcoin ha esigenza particolari e questo richiede la creazione di uno schema ad-hoc.
Ad un sistema centralizzato non interessano le dimensioni delle firme: il fattore cruciale è il tempo, pensate ad un server di e-commerce dove la latenza dei pagamenti è fondamentale.
In Bitcoin, dove un blocco viene prodotto ogni 10 minuti, che per firmare la transazione serva mezzo secondo o 2 secondi non fa differenza. Il fattore critico diventa la dimensione.

Per cui occorre creare uno schema post quantistico ad hoc, come il già citato SHRIMPS che va nella direzione giusta anche se ancora troppo grande.

Poi mette in guardia da truffatori di ogni razza e natura (non c'è da stupirsi) che spuntano e spunteranno come funghi per sfruttare questo clima.
Previsione facile: arriveranno tonnellate di shitcoin "super-quantum-resistant-bullet-proof"  nei prossimi anni per invogliarvi a scambiare i vostri vecchi e sorpassati bitcoin con la fiammante postquantumcoin  

[Ale88]

Previsione facile: arriveranno tonnellate di shitcoin "super-quantum-resistant-bullet-proof"  nei prossimi anni per invogliarvi a scambiare i vostri vecchi e sorpassati bitcoin con la fiammante postquantumcoin  

Immagine dal futuro dell'investitore medio:

[fillippone]

Oggi è uscito un report molto interessante:


Bernstein says quantum is a 'manageable upgrade cycle' for Bitcoin, not an existential threat


Se riesco a mettere le mani su una versione di quel PDF che non infranga nessun diritto, vedo di postarla qui sul forum.

In pratica analizza il problema del CRQC e lo pone come una sfida sociale, più che tecnica.

[Plutosky]

E' stata ufficialmente presentata una proposta di upgrade riguardante il freeze: BIP 361 (https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki)

La proposta prevede 3 fasi:

1)Fase A (durata 3 anni dall'attivazione della BIP) in cui gli indirizzi vulnerabili non possono più ricevere fondi ma possono solo inviarli a PQ (post quantum) address. Sarebbero coinvolti non solo i legacy (P2PK) ma tutti quelli con chiave pubblica esposta
2)Fase B (durata 2 anni dalla conclusione di fase A) in cui viene attivato il freeze e questi indirizzi non possono più ricevere né spendere
3)Fase C (in fase di studio) in cui sarebbe possibile per i legittimi proprietari recuperare i fondi nonostante il freeze.

L'ultima fase è la novità interessante, che io non credevo possibile. Le meraviglie della crittografia invece sembrano permetterlo, anche se la pratica deve ancora essere realizzata. Ho chiesto a Gemini di approfondire:



In pratica tramite le prove a conoscenza zero sarebbe possibile, per il legittimo proprietario, dimostrare che conosceva la private key anche senza esibirla né esporre la chiave pubblica.
Il recupero dall'indirizzo vulnerabile al PQ address sarebbe quindi sicuro.

Insomma: potrebbe essere possibile mettere al sicuro tutti i bitcoin vulnerabili con un freeze solo temporaneo.


 

[babo]

E' stata ufficialmente presentata una proposta di upgrade riguardante il freeze: BIP 361 (https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki)
 

si ho letto Loop uno dei promotori
stavo litigando nella chat bitcoin in merito a questo BIP
da parte della community ci sta molta contrarieta a questa BIP che io ritengo soddisfacente invece, in modo che evitiamo danni maggiori

qualcosa bisogna fare, bisogna iniziarci da ora e non fra anni


-edit-
aggiungo il sito ufficiale

https://www.bip361.org/

[Ale88]

In pratica tramite le prove a conoscenza zero sarebbe possibile, per il legittimo proprietario, dimostrare che conosceva la private key anche senza esibirla né esporre la chiave pubblica.
Il recupero dall'indirizzo vulnerabile al PQ address sarebbe quindi sicuro.

Insomma: potrebbe essere possibile mettere al sicuro tutti i bitcoin vulnerabili con un freeze solo temporaneo.

Mi pare un'eccellente soluzione questa, no? Non ho mai neanche pensato a questa eventualità perché se tu, Plutosky, non sapevi che fosse possibile figurarsi se potevo anche solo immaginarlo io Sarebbe interessante avere opinioni in merito da parte degli altri membri della nostra comunità, che ne pensate?

[fillippone]

E' stata ufficialmente presentata una proposta di upgrade riguardante il freeze: BIP 361 (https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki)

La proposta prevede 3 fasi:

1)Fase A (durata 3 anni dall'attivazione della BIP) in cui gli indirizzi vulnerabili non possono più ricevere fondi ma possono solo inviarli a PQ (post quantum) address. Sarebbero coinvolti non solo i legacy (P2PK) ma tutti quelli con chiave pubblica esposta
2)Fase B (durata 2 anni dalla conclusione di fase A) in cui viene attivato il freeze e questi indirizzi non possono più ricevere né spendere
3)Fase C (in fase di studio) in cui sarebbe possibile per i legittimi proprietari recuperare i fondi nonostante il freeze.

L'ultima fase è la novità interessante, che io non credevo possibile. Le meraviglie della crittografia invece sembrano permetterlo, anche se la pratica deve ancora essere realizzata. Ho chiesto a Gemini di approfondire:



In pratica tramite le prove a conoscenza zero sarebbe possibile, per il legittimo proprietario, dimostrare che conosceva la private key anche senza esibirla né esporre la chiave pubblica.
Il recupero dall'indirizzo vulnerabile al PQ address sarebbe quindi sicuro.

Insomma: potrebbe essere possibile mettere al sicuro tutti i bitcoin vulnerabili con un freeze solo temporaneo.

Non riesco davvero a capire, anche solo a livello concettuale, quale tipo di prova possa io fornire oltre la chiave privata.
Dato che la chiave privata non è una prova attendibile, dato che può essere trovata da un CRQC, che cosa mai potrò portare a dimostrazione di essere legittimo proprietario di quei bitcoin??

[Italian Panic]

E' stata ufficialmente presentata una proposta di upgrade riguardante il freeze: BIP 361 (https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki)

La proposta prevede 3 fasi:

1)Fase A (durata 3 anni dall'attivazione della BIP) in cui gli indirizzi vulnerabili non possono più ricevere fondi ma possono solo inviarli a PQ (post quantum) address. Sarebbero coinvolti non solo i legacy (P2PK) ma tutti quelli con chiave pubblica esposta
2)Fase B (durata 2 anni dalla conclusione di fase A) in cui viene attivato il freeze e questi indirizzi non possono più ricevere né spendere
3)Fase C (in fase di studio) in cui sarebbe possibile per i legittimi proprietari recuperare i fondi nonostante il freeze.

L'ultima fase è la novità interessante, che io non credevo possibile. Le meraviglie della crittografia invece sembrano permetterlo, anche se la pratica deve ancora essere realizzata. Ho chiesto a Gemini di approfondire:

Questo apre sicuramente un dibattito anche sull'identità, per 17 anni abbiamo sostenuto il "not your keys, not your money" e tutto ad un tratto di fronte ad una minaccia vengono freezzati dei fondi per timore che vengano riscossi da altri. Almeno bisognerebbe fare in modo che la fase C fosse perenne, cioè, proteggere i fondi perennemente da attacchi quantum ma sbloccabili anche tra 200 anni da chi riuscirà in qualche modo a dimostrare una zero know proof.
Il problema di rendere perenne la fase C sarebbe legata al fatto che non sappiamo dopo l'era quantum cosa possa arrivare (tra 50 o 100 anni) e ci si potrebbe trovare con un problema invalicabile di indirizzi bloccati e protocollo da aggiornare.

Sicuramente ci saranno belle gatte da pelare, attualmente propenderei per proteggere chi migra mentre chi resta esposto si assume il rischio come dovrebbe essere da filosofia bitcoin. Capisco anche che la tecnologia avanza e si deve essere pronti ai cambiamenti dati dalle sfide che si presentano.

L'unica cosa che spero è che non sia un preludio per poter bloccare indirizzi in futuro quando per forza di cose bitcoin entrerà nella finanza dalla porta principale e quando sarà strumento per la gestione della finanza del futuro, rischiando di fatto di perdere la sua caratteristica principale.

[Italian Panic]

Poi vedo un'altra questione, nel bip-0361 riportano: "Phase C (TBD): Pending further research, a separate BIP proposing a method to allow quantum safe recovery of legacy UTXOs, likely via zero knowledge proof of possession of a corresponding BIP-39 seed phrase".

Quindi richiede esattamente di dimostrare il possesso di un seed BIP-39 (verrà trovato un metodo matematico per risolverlo) ma gli indirizzi ante 2013 non sono indirizzi HD, ma indirizzi P2PK con gestione della chiave pubblica direttamente su blockchain e quindi senza seed BIP-39 saranno bloccati in maniera permanente. Quindi almeno un milione e mezzo di bitcoin saranno bloccati in eterno salvo che Satoshi si faccia vivo prima.


Infatti riportano che "Phase C is also compatible with an "Hourglass" style BIP for spending P2PK encumbered funds, provided such a BIP has activated by the time Phase C activates. BIP-361 authors support Hourglass for P2PK because it's not possible to construct a proof of HD wallet ownership for UTXOs created before BIP-32 existed".

In teoria dovrebbero garantire al massimo un bitcoin per blocco minato derivante da indirizzi P2PK per evitare di trovarsi nella migliore delle ipotesi un milione e mezzo di bitcoin immessi sul mercato in poche ore. Questa sembra una buona idea, anche uno avesse 200k bitcoin in 4 anni dovrebbe cavarsela.

[bitcoiner180]

E' stata ufficialmente presentata una proposta di upgrade riguardante il freeze: BIP 361 (https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki)

La proposta prevede 3 fasi:

1)Fase A (durata 3 anni dall'attivazione della BIP) in cui gli indirizzi vulnerabili non possono più ricevere fondi ma possono solo inviarli a PQ (post quantum) address. Sarebbero coinvolti non solo i legacy (P2PK) ma tutti quelli con chiave pubblica esposta
2)Fase B (durata 2 anni dalla conclusione di fase A) in cui viene attivato il freeze e questi indirizzi non possono più ricevere né spendere
3)Fase C (in fase di studio) in cui sarebbe possibile per i legittimi proprietari recuperare i fondi nonostante il freeze.

L'ultima fase è la novità interessante, che io non credevo possibile. Le meraviglie della crittografia invece sembrano permetterlo, anche se la pratica deve ancora essere realizzata. Ho chiesto a Gemini di approfondire:



In pratica tramite le prove a conoscenza zero sarebbe possibile, per il legittimo proprietario, dimostrare che conosceva la private key anche senza esibirla né esporre la chiave pubblica.
Il recupero dall'indirizzo vulnerabile al PQ address sarebbe quindi sicuro.

Insomma: potrebbe essere possibile mettere al sicuro tutti i bitcoin vulnerabili con un freeze solo temporaneo.


 

Il problema della soluzione C è che necessita di un hard fork, esattamente come il freeze. Oggi per spendere UTXO che appartengono ad indirizzi che richiedono una firma ECDSA serve, appunto, una firma ECDSA valida, non c'è altro modo. Nel momento in cui si rilassano le condizioni di spesa di quegli output, aggiungendo una condizione alternativa, si crea un hard fork.

Quindi il BIP 361 propone ben due hard fork, il primo per congelare gli indirizzi, il secondo (se la fase di studio si conclude con successo ) per introdurre un nuovo metodo di spesa di quegli indirizzi.

[fillippone]

Quindi il BIP 361 propone ben due hard fork, il primo per congelare gli indirizzi, il secondo (se la fase di studio si conclude con successo ) per introdurre un nuovo metodo di spesa di quegli indirizzi.

Non lo so gente.
Introdurre ben due hard fork (che significa avere 4 differenti blockchain) mi pare un po troppo.
Tra l’altro, per le questioni dette sopra, mi pare che questa fantomatica prova che abiliti la condizione C sia davvero una chimera.

[Plutosky]

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.

[gbianchi]

questo e' il testo ufficiale della BIP 361: https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki

Effettivamente si propongono delle soft-fork

Backward Compatibility
As a series of soft forks, older nodes will continue to operate without modification. Non-upgraded nodes, however, will consider all post-quantum witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.

Purtroppo i dettagli tecnici sono veramente pochi, e in particolare non c'e nessun dettaglio su come dovrebbe funzionare la fase C.

[babo]

questo e' il testo ufficiale della BIP 361: https://github.com/bitcoin/bips/blob/master/bip-0361.mediawiki

Effettivamente si propongono delle soft-fork

Backward Compatibility
As a series of soft forks, older nodes will continue to operate without modification. Non-upgraded nodes, however, will consider all post-quantum witness programs as anyone-can-spend scripts. They are strongly encouraged to upgrade in order to fully validate the new programs.

Purtroppo i dettagli tecnici sono veramente pochi, e in particolare non c'e nessun dettaglio su come dovrebbe funzionare la fase C.

se guardate il sito ufficiale che vi ho inserito poco sopra noterete un dettaglio molto importante
DRAFT


quindi non ci sta niente di ufficiale ancora, si possono fare delle proposte tecniche che potrebbero essere vagliate se avete idee in merito
la discussione al momento verte proprio su "cosa fare" e non "come farlo" credo

[gbianchi]

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.

Ragionavo stamattina come programmare una regola di consenso che filtri solo un po' di indirizzi sarebbe un incubo. Non e' un problema difficile dal punto concettuale,
ma lo sarebbe dal punto di vista implementativo in quanto ci vorrebbe una tabella condivisa di address da filtrare, che faccia parte attiva del sistema di consenso e condivisa da tutti i client.
Un vero e proprio incubo informatico.

Allora mi sono riletto bene la rfc, e dice:

A   Permitted sends are from legacy scripts to PQ scripts.   Everyone holding or accepting BTC.   160,000 blocks (~3 years) after BIP-361 activation.

B      At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys.

fino ad un certo punto A sono ammesse le transazion da indirizzi ECDSA/Schnorr, poi da un certo punto B sono vietate le transazioni da TUTTI i vecchi indirizzi ECDSA/Schnorr,
non da solo quelli esposti. Cosi' mi torna come implementazione di regola di consenso semplice e condivisa da tutti i client.

C'e' inoltre da considerare che (come dico io) questa RFC presuppone che PRIMA sia stato gia' implementato un sistema di address PQ,
quindi di base non serve a nulla se prima non si implementa il sistema PQ.

Il punto A fa gia' riferimento a script PQ, quindi manca un punto precedente grosso come una casa  

ℵ) implementare gli script  PQ

[Niekko]

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.

Ragionavo stamattina come programmare una regola di consenso che filtri solo un po' di indirizzi sarebbe un incubo. Non e' un problema difficile dal punto concettuale,
ma lo sarebbe dal punto di vista implementativo in quanto ci vorrebbe una tabella condivisa di address da filtrare, che faccia parte attiva del sistema di consenso e condivisa da tutti i client.
Un vero e proprio incubo informatico.

Allora mi sono riletto bene la rfc, e dice:

A   Permitted sends are from legacy scripts to PQ scripts.   Everyone holding or accepting BTC.   160,000 blocks (~3 years) after BIP-361 activation.

B      At a predetermined block height, nodes reject transactions that rely on ECDSA/Schnorr keys.

fino ad un certo punto A sono ammesse le transazion da indirizzi ECDSA/Schnorr, poi da un certo punto B sono vietate le transazioni da TUTTI i vecchi indirizzi ECDSA/Schnorr,
non da solo quelli esposti. Cosi' mi torna come implementazione di regola di consenso semplice e condivisa da tutti i client.

C'e' inoltre da considerare che (come dico io) questa RFC presuppone che PRIMA sia stato gia' implementato un sistema di address PQ,
quindi di base non serve a nulla se prima non si implementa il sistema PQ.

Il punto A fa gia' riferimento a script PQ, quindi manca un punto precedente grosso come una casa  

ℵ) implementare gli script  PQ

Non sono molto d'accordo. Questa soluzione congela le coin nei vecchi indirizzi anche ai legittimi proprietari, rendondole difatto inutili e sottratte al totale dei 21. In un ottica a lungo termine già questi 21 sono pochi, se li bruciamo anche saranno ancora meno.

[Italian Panic]

Leggevo un interessante articolo di qualche mese fa (dicembre) che mette in correlazione le varie blockchain principali e l'avanzamento degli studi che stanno facendo in merito all'arrivo dell'era quantum. https://arxiv.org/html/2512.13333v1

Molto interessante, ma dopo 4 mesi alcune info sono passate, però è l'unico e più recente che confronta le varie situazioni. Diciamo che mi ha colpito molto la situazione di Solana che praticamente non sta facendo nulla. Considerando la quantità di soldi che gira su quella blockchain e visto che vogliono fare concorrenza ad Ethereum, avessi dei fondi in una coin collegata a Solana guardando ad un orizzonte lungo non starei tranquillo anche perchè hanno una doppia esposizione al quantum attack oltre che alla firma (EdDSA) sono esposti anche sulla timeline (VDF).

[Niekko]

A me ricorda tanto il millenium bug 

[babo]

Non sono molto d'accordo. Questa soluzione congela le coin nei vecchi indirizzi anche ai legittimi proprietari, rendondole difatto inutili e sottratte al totale dei 21. In un ottica a lungo termine già questi 21 sono pochi, se li bruciamo anche saranno ancora meno.

perdonami e cosa cambia se sono 20 milioni o 21 milioni? non cambia moltissimo
invece secondo me scongelarli e rimeterli in circolo sarebbe molto piu grave
vuol dire che uno che holda per 20 anni potrebbe trovarsi i bitcoin sottratti e rimessi in circolo.. no

solo i btc di satoshi sono problematici ma alcuni mi hanno spiegato sticazzi e infondo non hanno tutti i torti
la forza di btc e' la liberta