Bitcoin Forum
July 13, 2025, 10:46:15 PM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Se tu avessi scoperto un algoritmo ECDLP , che strategia useresti ?  (Read 3830 times)
Stemby
Legendary
*
Offline Offline

Activity: 2450
Merit: 1008



View Profile
January 09, 2016, 12:29:38 AM
 #21

In questo scenario non guadagno nulla lato bitcoin, ma magari un nobel per la matematica
Difficile, visto che non esiste...

Magari però uno per l'economia, come venne fatto con Nash.

“…virtual currencies, could have a substitution effect on central bank money if they become widely accepted.”
ECB Report, October 2012
gbianchi (OP)
Legendary
*
Offline Offline

Activity: 3514
Merit: 3155



View Profile
January 09, 2016, 01:03:40 AM
Last edit: January 09, 2016, 01:16:26 AM by gbianchi
 #22

questo interessante paper

http://eprint.iacr.org/2016/003.pdf

congettura la possibile esistenza di un algoritmo di ordine 2^n/3

e' solo una congettura, e nel paper affrontano solo problemi su F2^n   (e non su Fp come Secp256k1)
e inoltre non ECDLP completo  ma una sorta di "riduzione in 2 polinomiali"

pero' un eventuale algoritmo del genere renderebbe il livello di 256 bit di ECDSA a rischio.

2^(n/3) e' ancora arduo ma comincia ad essere trattabile.

GUIDA PER NUOVI UTENTI https://bitcointalk.org/index.php?topic=1241459.0
DO NOT HOLD YOUR BTC ON THIRD PARTY EXCHANGES – BE YOUR OWN BANK https://bitcointalk.org/index.php?topic=945881.0
BITCOIN... WHAT IS IT ? https://bitcointalk.org/index.php?topic=2107660.0
gbianchi (OP)
Legendary
*
Offline Offline

Activity: 3514
Merit: 3155



View Profile
February 18, 2025, 05:55:02 PM
 #23

arulbero ha postato in risposta ad una mia (errata) convinzione un contributo di notevole importanza,
lo riporto qui perche' secondo me ogni bitcoiner (e a maggior ragione ogni shitcoiner) dovrebbe esserne a conoscenza:



Penso che bisogna fare un distinguo.

Supponiamo che si raggiunga la potenza quantistica necessaria per eseguire l'inverso di ECDSA in tempi ragionevoli.

qui esiste una biforcazione

se da un certo address sono gia' state firmate transazioni, allora e' gia' stata esposta la chiave pubblica ECDSA e quindi l'algoritmo puo' venire applicato.

ma se si tratta di address che non hanno mai firmato nessuna transazione, allora la questione si fa molto piu' complessa,
infatti un address bitcoin di vecchio tipo (quelli di satoshi) erano cosi' fatti:

base58(sha256(sha256(add_version(ripemd-160(sha256(chiave pubblica ecdsa))))))

per questi bisogna invertire anche 3 sha256 e un ripmed-160, calcolo che e' ancora ben lontano da essere decodificato dall'ipotetico computer quantistico suddetto.

Quindi riepilogando:

1) per indirizzi che hanno esposto la loro chiave pubblica, il problema sarebbe reale.

2) per indirizzi che non hanno mai esposto la chiave pubblica, ossia mai spesi, il problema non sussiste.

Siccome praticamente tutti gli indirizzi di satoshi ricadono nella seconda categoria, direi che il problema non sussiste.

No, il problema sussiste in entrambi i casi.
Per spendere bitcoin da un indirizzo, in ogni caso devi esporne la chiave pubblica. Per confermare la transazione devi attendere in media 10 minuti, e una volta che l'algoritmo sarà stato craccato, 10 minuti saranno più che sufficienti per tentare di appropriarsi di quei bitcoin.

Nel famoso puzzle, ovvero la transazione  
https://www.blockchain.com/explorer/transactions/btc/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

verso 160 indirizzi, ognuno protetto da una chiave privata a n bit, con n da 1 a 160,

finchè erano noti solo gli indirizzi e non le chiavi pubbliche associate, erano stati scoperti con attacco brute force solo le prime 62/63 chiavi (più o meno).

A un certo punto l'autore del puzzle fece alcune transazioni in uscita da alcuni tra quegli indirizzi che conservavano ancora bitcoin,

più precisamente effettuò 1 transazione dall'indirizzo protetto dalla chiave a 65 bit, 1 dalla chiave a 70 bit, 1 dalla chiave 75 bit, ... fino alla chiave a 160 bit, esponendo in questo modo le chiavi pubbliche (che rimangono in blockchain, non solo in mempool) di quei particolari indirizzi.

Cosa è successo quindi?
Nel giro di relativamente poco tempo sono state trovare tutte le chiavi private degli indirizzi da quello protetto a 60 bit fino a quello protetto a 130 bit (solo le chiavi private relative agli indirizzo con chiavi pubbliche esposte).

Si è invece 'spento' l'interesse per trovare le chiavi private relative alle chiavi 67, 68, 69, ecc. Perchè?  

Perchè con un hardware normalissimo bastano pochi secondi per ricavare una chiave privata di 68 bit da una chiave pubblica, quindi chi dopo mesi di ricerca avesse trovato la chiave privata (a partire solo dall'indirizzo, quindi con attacco brute force) nel momento in cui avesse tentato di spendere quei bitcoin avrebbe corso il serio rischio di non riuscire a farlo.

Con l'eventuale arrivo dei computer quantistici, una chiave pubblica standard protetta a 256 bit sarebbe come una chiave pubblica protetta da una chiave privata da 68 bit oggi, ovvero craccabile in secondi.
E quindi nessun indirizzo sarebbe sicuro, a meno che uno decida di lasciare lì i bitcoin per sempre, ma allora sarebbe come non averli.


GUIDA PER NUOVI UTENTI https://bitcointalk.org/index.php?topic=1241459.0
DO NOT HOLD YOUR BTC ON THIRD PARTY EXCHANGES – BE YOUR OWN BANK https://bitcointalk.org/index.php?topic=945881.0
BITCOIN... WHAT IS IT ? https://bitcointalk.org/index.php?topic=2107660.0
gbianchi (OP)
Legendary
*
Offline Offline

Activity: 3514
Merit: 3155



View Profile
February 18, 2025, 05:57:24 PM
Merited by fillippone (6)
 #24

questa e' la mia risposta (dove tra l'altro rimando proprio a questo thread):


No, il problema sussiste in entrambi i casi.
Per spendere bitcoin da un indirizzo, in ogni caso devi esporne la chiave pubblica. Per confermare la transazione devi attendere in media 10 minuti, e una volta che l'algoritmo sarà stato craccato, 10 minuti saranno più che sufficienti per tentare di appropriarsi di quei bitcoin.

Nel famoso puzzle, ovvero la transazione  
https://www.blockchain.com/explorer/transactions/btc/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

verso 160 indirizzi, ognuno protetto da una chiave privata a n bit, con n da 1 a 160,

finchè erano noti solo gli indirizzi e non le chiavi pubbliche associate, erano stati scoperti con attacco brute force solo le prime 62/63 chiavi (più o meno).

A un certo punto l'autore del puzzle fece alcune transazioni in uscita da alcuni tra quegli indirizzi che conservavano ancora bitcoin,

più precisamente effettuò 1 transazione dall'indirizzo protetto dalla chiave a 65 bit, 1 dalla chiave a 70 bit, 1 dalla chiave 75 bit, ... fino alla chiave a 160 bit, esponendo in questo modo le chiavi pubbliche (che rimangono in blockchain, non solo in mempool) di quei particolari indirizzi.

Cosa è successo quindi?
Nel giro di relativamente poco tempo sono state trovare tutte le chiavi private degli indirizzi da quello protetto a 60 bit fino a quello protetto a 130 bit (solo le chiavi private relative agli indirizzo con chiavi pubbliche esposte).

Si è invece 'spento' l'interesse per trovare le chiavi private relative alle chiavi 67, 68, 69, ecc. Perchè?  

Perchè con un hardware normalissimo bastano pochi secondi per ricavare una chiave privata di 68 bit da una chiave pubblica, quindi chi dopo mesi di ricerca avesse trovato la chiave privata (a partire solo dall'indirizzo, quindi con attacco brute force) nel momento in cui avesse tentato di spendere quei bitcoin avrebbe corso il serio rischio di non riuscire a farlo.

Con l'eventuale arrivo dei computer quantistici, una chiave privata standard da 256 bit sarebbe come una chiave privata da 68 bit oggi, ovvero craccabile in secondi.
E quindi nessun indirizzo sarebbe sicuro, a meno che uno decida di lasciare lì i bitcoin per sempre, ma allora sarebbe come non averli.

Effettivamente mentre la transazione che firma la spesa dell'UTXO e' in mempool, e quindi i BTC non sono ancora trasferiti al nuovo indirizzo,
il "pagante" ha pero' gia' esposto la sua chiave pubblica.

Quindi se l'attaccante  tiene monitorata la mempool, e decodifica le chiavi private dalle chiavi pubbliche mediamente piu' velocemente di
quanto le transazioni in attesa vengono inserite nei blocchi, l'attaccante puo' firmare una transazione della stessa UTXO ma con fee piu' alte verso
un indirizzo sotto il suo controllo.

Tra l'altro a questo punto anche altri attaccanti potrebbero fare la stessa cosa, e tutto si trasformerebbe in un casino senza fondo.
 
Ammettendo che i tempi di decodifica siano di secondi o al massimo qualche minuto, hai perfettamente ragione!

Questo ragionamento fa totalmente riposizionare la mia idea di sicurezza su questi sistemi, non tanto per i computer quantistici,
ma piuttosto per la mina vagante sempre possibile della scoperta di un ECDLP efficiente.

Non dimentichiamoci che le difficolta' di inversione di ECDSA sono solo congetturate, non dimostrate.

Rimando a questo mio vecchio thread chi puo' essere interessato all'argomento:

https://bitcointalk.org/index.php?topic=1294566.0



GUIDA PER NUOVI UTENTI https://bitcointalk.org/index.php?topic=1241459.0
DO NOT HOLD YOUR BTC ON THIRD PARTY EXCHANGES – BE YOUR OWN BANK https://bitcointalk.org/index.php?topic=945881.0
BITCOIN... WHAT IS IT ? https://bitcointalk.org/index.php?topic=2107660.0
fillippone
Legendary
*
Offline Offline

Activity: 2590
Merit: 18600


Duelbits.com - Rewarding, beyond limits.


View Profile WWW
March 16, 2025, 11:27:05 PM
 #25

questa e' la mia risposta (dove tra l'altro rimando proprio a questo thread):


No, il problema sussiste in entrambi i casi.
Per spendere bitcoin da un indirizzo, in ogni caso devi esporne la chiave pubblica. Per confermare la transazione devi attendere in media 10 minuti, e una volta che l'algoritmo sarà stato craccato, 10 minuti saranno più che sufficienti per tentare di appropriarsi di quei bitcoin.

Nel famoso puzzle, ovvero la transazione  
https://www.blockchain.com/explorer/transactions/btc/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15

verso 160 indirizzi, ognuno protetto da una chiave privata a n bit, con n da 1 a 160,

finchè erano noti solo gli indirizzi e non le chiavi pubbliche associate, erano stati scoperti con attacco brute force solo le prime 62/63 chiavi (più o meno).

A un certo punto l'autore del puzzle fece alcune transazioni in uscita da alcuni tra quegli indirizzi che conservavano ancora bitcoin,

più precisamente effettuò 1 transazione dall'indirizzo protetto dalla chiave a 65 bit, 1 dalla chiave a 70 bit, 1 dalla chiave 75 bit, ... fino alla chiave a 160 bit, esponendo in questo modo le chiavi pubbliche (che rimangono in blockchain, non solo in mempool) di quei particolari indirizzi.

Cosa è successo quindi?
Nel giro di relativamente poco tempo sono state trovare tutte le chiavi private degli indirizzi da quello protetto a 60 bit fino a quello protetto a 130 bit (solo le chiavi private relative agli indirizzo con chiavi pubbliche esposte).

Si è invece 'spento' l'interesse per trovare le chiavi private relative alle chiavi 67, 68, 69, ecc. Perchè?  

Perchè con un hardware normalissimo bastano pochi secondi per ricavare una chiave privata di 68 bit da una chiave pubblica, quindi chi dopo mesi di ricerca avesse trovato la chiave privata (a partire solo dall'indirizzo, quindi con attacco brute force) nel momento in cui avesse tentato di spendere quei bitcoin avrebbe corso il serio rischio di non riuscire a farlo.

Con l'eventuale arrivo dei computer quantistici, una chiave privata standard da 256 bit sarebbe come una chiave privata da 68 bit oggi, ovvero craccabile in secondi.
E quindi nessun indirizzo sarebbe sicuro, a meno che uno decida di lasciare lì i bitcoin per sempre, ma allora sarebbe come non averli.

Effettivamente mentre la transazione che firma la spesa dell'UTXO e' in mempool, e quindi i BTC non sono ancora trasferiti al nuovo indirizzo,
il "pagante" ha pero' gia' esposto la sua chiave pubblica.

Quindi se l'attaccante  tiene monitorata la mempool, e decodifica le chiavi private dalle chiavi pubbliche mediamente piu' velocemente di
quanto le transazioni in attesa vengono inserite nei blocchi, l'attaccante puo' firmare una transazione della stessa UTXO ma con fee piu' alte verso
un indirizzo sotto il suo controllo.

Tra l'altro a questo punto anche altri attaccanti potrebbero fare la stessa cosa, e tutto si trasformerebbe in un casino senza fondo.
 
Ammettendo che i tempi di decodifica siano di secondi o al massimo qualche minuto, hai perfettamente ragione!

Questo ragionamento fa totalmente riposizionare la mia idea di sicurezza su questi sistemi, non tanto per i computer quantistici,
ma piuttosto per la mina vagante sempre possibile della scoperta di un ECDLP efficiente.

Non dimentichiamoci che le difficolta' di inversione di ECDSA sono solo congetturate, non dimostrate.

Rimando a questo mio vecchio thread chi puo' essere interessato all'argomento:

https://bitcointalk.org/index.php?topic=1294566.0



Quindi se ho capito bene, anche i bitcoin di Satoshi rimarrebbero fermi, perchè in caso di "movimentazione" si scatenerebbe una guerra di RBF che porterebbe la transazione a consumarsi in fees? Ma allora speriamo che un miner non abbia mai un computer quantistico, perchè potrebbe inserirsi da solo la transazione nel blocco, impedendo di fatto la competizione!


fillippone
Legendary
*
Offline Offline

Activity: 2590
Merit: 18600


Duelbits.com - Rewarding, beyond limits.


View Profile WWW
March 18, 2025, 11:43:05 PM
 #26

Ho trovato un interessante blog post di jameso Lopp in proposito:

What to do with Satoshi Stash? Jameson Lopp has a view.

Spero di stimolare un pò di discussione,

arulbero
Legendary
*
Offline Offline

Activity: 2022
Merit: 2265


View Profile
June 25, 2025, 01:34:31 PM
 #27

arulbero ha postato in risposta ad una mia (errata) convinzione un contributo di notevole importanza,
lo riporto qui perche' secondo me ogni bitcoiner (e a maggior ragione ogni shitcoiner) dovrebbe esserne a conoscenza:

Segnalo questo servizio:

https://slipstream.mara.com/

Quote
What is Marathon Slipstream?

Slipstream is a service for directly submitting large or non-standard Bitcoin transactions to Marathon. It provides sophisticated users with a simple web interface and a transparent process for adding complex Bitcoin transactions to the blockchain. If your transaction meets Marathon’s minimum fee threshold and conforms to the consensus rules of Bitcoin, Marathon adds it to its mempool for mining.

Are my transactions private?

Before they are mined, yes. Your transactions are not broadcasted to the Bitcoin network until they have received at least one confirmation. Once mined, your transaction will live on the public Bitcoin ledger.

in pratica è possibile inviare una tx non standard a un pool di miner (Marathon), senza che la transazione venga esposta in una mempool pubblica (non conosco gli ulteriori dettagli tecnici);

in questo modo si potrebbe aggirare in parte il problema della pubblicazione anticipata di una chiave pubblica prima di avere inserito la transazione in un blocco della blockchain.

Chiaro che in questo modo si riduce solo il problema e non lo si elimina definitivamente.
gbianchi (OP)
Legendary
*
Offline Offline

Activity: 3514
Merit: 3155



View Profile
June 25, 2025, 01:41:21 PM
 #28

arulbero ha postato in risposta ad una mia (errata) convinzione un contributo di notevole importanza,
lo riporto qui perche' secondo me ogni bitcoiner (e a maggior ragione ogni shitcoiner) dovrebbe esserne a conoscenza:

Segnalo questo servizio:

https://slipstream.mara.com/

Quote
What is Marathon Slipstream?

Slipstream is a service for directly submitting large or non-standard Bitcoin transactions to Marathon. It provides sophisticated users with a simple web interface and a transparent process for adding complex Bitcoin transactions to the blockchain. If your transaction meets Marathon’s minimum fee threshold and conforms to the consensus rules of Bitcoin, Marathon adds it to its mempool for mining.

Are my transactions private?

Before they are mined, yes. Your transactions are not broadcasted to the Bitcoin network until they have received at least one confirmation. Once mined, your transaction will live on the public Bitcoin ledger.

in pratica è possibile inviare una tx non standard a un pool di miner (Marathon), senza che la transazione venga esposta in una mempool pubblica (non conosco gli ulteriori dettagli tecnici);

in questo modo si potrebbe aggirare in parte il problema della pubblicazione anticipata di una chiave pubblica prima di avere inserito la transazione in un blocco della blockchain.

Chiaro che in questo modo si riduce solo il problema e non lo si elimina definitivamente.


Ah bhe, cosi' usi bitcoin come servizio centralizzato gestito da Marathon.

La soluzione e' peggiore del problema!


GUIDA PER NUOVI UTENTI https://bitcointalk.org/index.php?topic=1241459.0
DO NOT HOLD YOUR BTC ON THIRD PARTY EXCHANGES – BE YOUR OWN BANK https://bitcointalk.org/index.php?topic=945881.0
BITCOIN... WHAT IS IT ? https://bitcointalk.org/index.php?topic=2107660.0
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!