UPD: 25.12.2023
Actually DoubleDirect() also not working. It starting to calculate wrong keys after some interval. Why this is can happen?
The only function work so far for sequential private keys to public keys is ComputePublicKey().
For sequential private keys there is the NextKey function. DoubleDirect does, as the name indicates, only the double of P. Then, if you start from G: G P = DoubleDirect(G) : G -> P = 2G P = NextKey(P) : P -> P+1 = 3G P = NextKey(P) : P -> P+1 = 4G P = NextKey(P) : P -> P+1 = 5G and so on |
|
|
|
Nel frattempo Antpool continua, anche con mempool piena come un uovo, a minare 1-2 volte al giorno dei blocchi vuoti ... Una forma di protesta che gli costerà milioni di dollari e che non nota nessuno Contenti loro...  In effetti i miner non possono velocizzare l'inserimento delle tx nella blockchain ma possono al contrario, se vogliono, rallentare l'offerta di spazio di scrittura per unità di tempo a disposizione degli utenti, scegliendo di minare blocchi vuoti e quindi rinunciando alle fee. In praticano scelgono di fare un lavoro di spesa come il mining indipendentemente dagli incentivi degli utenti; se tutti i miner facessero così, raccoglierebbero solo i btc delle ricompense che però non varrebbero nulla; e comunque loro stessi hanno bisogno di scrivere nella blockchain per vendere i propri btc. Una protesta contro se stessi. |
|
|
|
La mempool è a livelli record.
I miner hanno avuto l'altro giorno il loro miglior giorno di sempre con 23.6 milioni guadagnati in fees.
Se le stime di questo calcolatore sono corrette: https://buybitcoinworldwide.com/fee-calculator/attualmente ci vogliono 25 dollari per una tx con 2 input e 2 output, per averla confermata entro 2 ore (12 blocchi). Le fee stimate salgono a 40 dollari se si vuole una conferma entro 2 blocchi La cosa che mi sorprende è però che l'hash rate sia ai massimi, e che il prossimo aggiustamento sarà mastodontico e positivo:
...
Questo vuol dire che comunque i miner stanno andando più veloce del previsto, quindi stanno minando il 5% dei blocchi in più.
I miner stanno andando più velocemente del previsto semplicemente perchè sono aumentate le fee che il mercato paga per scrivere nella blockchain. Siamo passati da 10 btc di fee al giorno di 1 anno fa a oltre 400 btc di fee al giorno negli ultimi giorni https://www.blockchain.com/explorer/charts/transaction-fees l'incentivo adesso è veramente alto (le fee sono quasi al 50% delle ricompense giornaliere, che si aggirano attualmente sui 900 btc a giorno). Il livello attuale delle fee è equivalente alla sola ricompensa giornaliera che si avrà da aprile in poi, dopo l'halving. Gli utenti/utilizzatori della blockchain aumentano la richiesta di scrivere dati nei blocchi e per guadagnarsi questo diritto a scrivere si fanno concorrenza tra loro a suon di fee, i miner attratti da questo aumento delle fee si fanno a loro volta concorrenza tra loro a suon di exahash per incamerare queste fee. In effetti vale la pena ricordare che, per quanto i miner si sforzino di 'aumentare' l'offerta di blocchi (incrementando la velocità di mining), di fatto l'aggiustamento periodico della difficoltà rende praticamente rigida la velocità di inserimento delle tx, diciamo che si possono aggiungere 6 MB di dati all'ora circa (o 6 * 4 = 24 MB all'ora se si considera la dimensione reale dei blocchi) nella blockchain. Sulla carta se aumentano i btc a disposizione dei miner, dovrebbe aumentare anche la pressione di vendita dei btc da parte dei miner stessi, quindi questo dovrebbe contenere il prezzo del btc, anche se dall'altra parte l'aumento delle fee dovrebbe riflettere anche un aumento dell'interesse a utilizzare i bitcoin. |
|
|
|
EDIT2:
multithread (16 cores), 2^25 keys (33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 seconds
multithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 seconds Wow, impressive! My results have all been single core. I have not attempted to do anything with multi-core yet. Then your results are better than mine. With only 1 cpu in 4 seconds I get around 16.5 M consecutive keys, not 20 M. |
|
|
|
After more script tweaking, I can generate a 20,000,000 key database in less than 10 seconds. Search time less than 2 seconds. 36 Bit Result: This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Building the Binary Database
Targeting PubKey: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Number of PubKeys: 20,000,000
Writing to file every: 20,000,000 keys
Subtract Value: 1
Space Covered: 20,000,000 / 0x1312d00
DB Generation Time: 0:00:09.604563
Scanning Randomly
Current Random Key: 0x9dd926219 Jumps Made: 291
PK Found: 42387769980
PK Found: 0x9de820a7c
Search Time: 0:00:01.815859
Total Time: 0:00:11.420422
EDIT: If I use the BitArray option, as in original code, 20,000,000 keys generated into DB takes right at 4 seconds. Are you using multithreading? It works only for consecutive keys? With multithreading and 16 cores, I get 2**24 (16.77M) keys in 4.35 seconds. Non consecutive keys. EDIT:multithread (16 cores), 2^25 keys ( 33.5M) with distance = 16 (using ice.point_loop_subtraction): 5.15 secondsmultithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.39 secondsEDIT2:multithread (16 cores), 2^25 keys ( 33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.8 secondsmultithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 1.06 secondsEDIT3:multithread (16 cores), 2^25 keys ( 33.5M) with distance = 16 (using ice.point_loop_subtraction): 4.67 secondsmultithread (16 cores), 2^25 consecutive keys (using ice.point_sequential_decrement): 0.89 seconds |
|
|
|
I am currently working on trying to create the "wilds" in the DB and then run "tames" for the search.
Keep your ideas and scripts coming arulbero. Many thanks for all of your insights over the last few years. You are Way smarter than me with python and ecc math, 100%!
The ideas in my script are: - put 2^23 keys in 2^23 bits (mcdouglasx's idea) - then produce a random key P and from P get 128 (not 64) subtractions : P - sustract*G, P - 2*sustract*G, ..., P - 128*sustract*G - I get in this way a large string of 128 bits; from this large string I extract 64 strings of consecutive 64 bits (from 1 to 64, from 2 to 65, from 3 to 66, ..., from 65 to 128) - I do the same thing for: P-1G, P-2G, P-3G, ..., P -(sustract-1)*G - now each key is represented not by 1 but by 64 strings of 64 bits each. In this way I can mantain low the size of the database. - I compare all these strings (4 bytes each) against the database where the databases is divided in groups of 4 bytes each (in this case, the database is a set of 2^23/2^6 = 2^17 elements of 4 bytes each) - to see if an element of 4 byte is in database, i intersect the set of the 4 bytes elements of the databases with the set of the 4 bytes elements generated in the search; this step is pretty fast, because python automatically creates an hashtable. |
|
|
|
Ok, I changed this back to 1: split_total_keys = 1 #2**4 #> 1 only if sustract > 1 I had it at split_total_keys = 2**4 #> 1 only if sustract > 1 based on your note of greater than 1 if sustract is greater than 1. Now it's taking anywhere from 4 seconds to 15 seconds to find key. Your code is good. Just not easy to follow at times.  'Only' doesn't mean you have to set > 1, it is useful only if the db size is 2^28 keys or more, 2^23 is small. Now I run 40 times in a row: time for i in {1..40}; do python3 search_pk.py; done
and I got 91s, then 2.28 s for each key. Worst result: 8.5 s, but many other under 1 second. My script is not optimized to random search, but to 'consecutive' search. |
|
|
|
Did you copy again the create_database.py ? There was a bug.
Yes, I did.
I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
Are you sure to have set prefix = '23_4' in both scripts? In the script I posted, there was '32_0' Lol, yes. I am sure. It eventually found the key around the 4 minute mark running randomly in the 2^36 range. Two tests one took 4 minutes the other 3 min 30 sec. Running a 3rd now. I'm pretty sure you are using parameters for 2^28 or for 2^32 search space. These are my parameters: prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 num = 128 # collision margin in bits (multiple of 64 bits) split_total_keys = 1 total_search_keys_to_generate = sustract multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys bytes_for_key = num//8 split_database = 2**0 #read only a fraction of the database to speedup the finding of the string and save RAM size_partial_db = num_bytes_db//split_database pk_orig = 42387769980 space_search_start = 0x800000000 space_search_stop = 0x1000000000 |
|
|
|
Did you copy again the create_database.py ? There was a bug.
Yes, I did.
I am running 2^23 keys with a spread of 2^4. That shouldn't matter, just wanted to let you know my params.
Are you sure to have set prefix = '23_4' in both scripts? In the script I posted, there was '32_0' do this check: du -sh data-base23_4.bin
1,0M data-base23_4.bin
|
|
|
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts:
space_covered in the DB = number of key stored in db * subtract value and
search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds. Yeah I don't get less than 2 seconds when I run the range with your script. It's been running for 2 minutes now with no key found. Maybe you changed up all the other parameters? Did you copy again the create_database.py ? There was a bug. These are my parameters: prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 num = 128 # collision margin in bits (multiple of 64 bits) split_total_keys = 1 total_search_keys_to_generate = sustract multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys bytes_for_key = num//8 split_database = 2**0 #read only a fraction of the database to speedup the finding of the string and save RAM size_partial_db = num_bytes_db//split_database pk_orig = 42387769980 space_search_start = 0x800000000 space_search_stop = 0x1000000000 |
|
|
|
Why you made: Jumps Made: 983?
In which range you generate your random private keys?
In my 2 scripts:
space_covered in the DB = number of key stored in db * subtract value and
search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] Correct. My subtract value + keys generated only need to stay less than the search range; or more than 0x0. The difference is, my script doesn't need to know the private key to find a key, but yours does/did. I can't go from, priv key - search space, because I do not know the priv key. So in my example, my search was limited to 0x800000000 - 0x1000000000; because I do not know the private key, I have to run random checks all through the range. If my script used a known private key and I could narrow the range down to priv key - search space, I am sure it would find the key much faster. I may took a look and test your script(s) again and modify it so the priv key is not known and test results. DB creation will always be close to the same speed since we basically use the same coding; search time should also be close. space_search_start = 0x800000000 space_search_stop = 0x1000000000 on average less than 2 seconds. |
|
|
|
Running a search for the 2^36 key and it's been about 6 minutes with no key found. That is with 2^23 keys generated with subtraction of 2^4.
This search takes way too long. Should be found within 10 seconds.
Maybe I'm missing something.
There was a bug in the create_database script, now it is fixed (copy again that script) When I run a 2^36 key test with my modified OP script, the results: This is the public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
Building the Binary Database
Targeting PubKey: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
[b] Number of PubKeys: 9,000,000
Writing to file every: 900,000 keys
Subtract Value: 9[/b]
Scanning Randomly
Current Random Key: 0x9dafa302d Jumps Made: 983
PK Found: 42387769980
PK Found: 0x9de820a7c
Total Time: 0:00:19.863232
Maybe I am missing something in your script arulbero. And maybe I don't understand your script 9,000,000 keys with subtract value = 9 means that (in my language) you are covering a 9M * 9 = 81M = 2**27 range, then you want to find a key (42387769980, that is in 2**36 range) in a database that cover a 2**27 range, is it correct? Why you made: Jumps Made: 983? In which range you generate your random private keys? In my 2 scripts: space_covered in the DB = number of key stored in db * subtract value and search_space = [priv_key - size_of_space_covered_by_DB, priv_key + size_of_space_covered_by_DB] I generate: 1) in DB: only keys equally spaced 2) in the search script: consecutive keys (and for each of these keys, 128 subtractions); in your example, 16 * 128 subtractions In search script only 1 key is random generated, then I generate consecutive keys_search with number of consecutive keys_search = sustract value, in this way the random key has 50% to produce a sequence of 64 bits that falls in the DB. For each of these keys I perform 2*64 subtractions. You have to set the parameters in this way: ###DATABASE##### prefix = '23_4' data_base_name = 'data-base'+prefix+'.bin' num_public_keys = 2**23 # 8 millions of keys num_bytes_db = num_public_keys//8 # 1 bit for each key sustract= 2**4 #amount to subtract each time, If you modify this, use the same amount to scan. space_covered = num_public_keys*sustract #2**27 = 128 millions, space covered Low_m= 2**3 # writing to file every: 2**23/2**3 = 2**20 keys = 1M target_public_key = "02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6" target = ice.pub2upub(target_public_key) > time python3 create_database.py
Making Binary Data-Base
Keys generated: 8388608
Space covered by the keys spread with distance 16 in the database : 134217728
real 0m12,831s (but with Low_m = 2**7 it takes about 12s)
user 0m12,030s
sys 0m0,800s
> du -sh data-base23_4.bin
1,0M data-base23_4.bin
########################SEARCH PARAMATERS########################## num = 64# collision margin in bits (multiple of 64 bits) pk_orig = 42387769980 space_search_start = pk_orig - space_covered #in this way you know for sure that the space search contains the space covered space_search_end = pk_orig + space_covered > time python3 search_pk.py
Keys generated in DB: 8388608
Space covered by the keys in DB (the keys are distributed in this space with distance 16) : 134217728
This is the public key: b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
I need to find this private key: 42387769980
Scanning Binary Sequence
Looking in the range: 42253552252 42521987708
Found!
The private key 42387769980 was recovered successfully!
real 0m0,145s
user 0m0,136s
sys 0m0,009s
Then it takes about 13s to create the database and to retrieve the key. With: prefix = '28_4' num_public_keys = 2**28 #256 millions of keys num_bytes_db = num_public_keys//8 #1 bit for each key sustract= 2**4 #amount to subtract each time, If you modify this, use the same amount to scan. space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered Low_m = 2**8 num = 256 #collision margin in bits (multiple of 64 bits) pk_orig = 42387769980 space_search_start = pk_orig - space_covered #in this way you know for sure that the space search contains the space covered space_search_end = pk_orig + space_covered it takes (on average) less than 1 second only to retrieve the key. |
|
|
|
I modified slightly the OP's 'create_database' script (1 bit for key, 128 kB, distance between 2 keys = 1) it takes about 111 minutes (less than 2 hours) to generate 2**32 keys (4 billions), size of the DB = 512 MBThe script search takes less than 1 second to retrieve a key in this space. create_database.py #@mcdouglasx modified by arulbero
import secp256k1 as ice
from bitstring import BitArray
#########################DATABASE PARAMETERS#########################
prefix = '32_0'
data_base_name = 'data-base'+prefix+'.bin'
num_public_keys = 2**32 # 4 billions of keys
num_bytes_db = num_public_keys//8 # 1 bit for each key
sustract= 2**0 #amount to subtract each time, If you modify this, use the same amount to scan.
sustract_pub= ice.scalar_multiplication(sustract)
space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered
#pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45
target_public_key = "03f760d768600e639758836fda5da546c10b1d84886165a5a1a4586192518aaf77"
target = ice.pub2upub(target_public_key)
Low_m= 2**8 #to save ram
lm= num_public_keys // Low_m
###################################################################
print("Making Binary Data-Base")
print()
res= ice.point_loop_subtraction(lm, target, sustract_pub)
my_str= BitArray(res[t*65+64]%2 for t in range(lm)) #0 if even, 1 if odd
with open(data_base_name, 'wb') as binary_file:
my_str.tofile(binary_file)
for i in range (1,Low_m):
lm_upub=ice.scalar_multiplication((lm*i)*sustract)
A1= ice.point_subtraction(target, lm_upub)
res=ice.point_loop_subtraction(lm, A1, sustract_pub)
my_str=BitArray(res[t*65+64]%2 for t in range(lm))
with open(data_base_name, 'ab') as binary_file:
my_str.tofile(binary_file)
print("Keys generated: " + str(num_public_keys))
print("Space covered by the keys spread with distance " + str(sustract) + " in the database : " + str(space_covered))
search_pk.py #@mcdouglasx modified by arulbero
import secp256k1 as ice
from bitstring import BitArray
import random
import sys
#########################DATABASE PARAMETERS#########################
prefix = '32_0'
data_base_name = 'data-base'+prefix+'.bin'
num_public_keys = 2**32 # 4 billions of keys
num_bytes_db = num_public_keys//8 # 1 bit for each key
sustract= 2**0 #amount to subtract each time, If you modify this, use the same amount to scan.
sustract_pub= ice.scalar_multiplication(sustract)
space_covered = num_public_keys*sustract #2**32 = 4 billions, space covered
#pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45
target_public_key = "03f760d768600e639758836fda5da546c10b1d84886165a5a1a4586192518aaf77"
target = ice.pub2upub(target_public_key)
###################################################################
########################SEARCH PARAMATERS##########################
num = 1024+1024# collision margin in bits
total_search_keys_to_generate = sustract
split_total_keys = 1 #> 1 only if sustract > 1
multiple_search_keys_at_once = total_search_keys_to_generate//split_total_keys
bytes_for_key = num//8
split_database = 2**9 #read only a fraction of the database to speedup the finding of the string and save RAM
size_partial_db = num_bytes_db//split_database
pk_orig = 32294923307823
#pk = 32 294 923 307 823 = 0x1d5f3f6e8b2f between 2**44 and 2**45
space_search_start = pk_orig - space_covered #I'm assuming that the space search contains for sure the pk
space_search_end = pk_orig + space_covered
#####################################################################
print("Keys generated in DB: " + str(num_public_keys))
print("Space covered by the keys in DB (the keys are distributed in this space with distance " + str(sustract) + ") : " + str(space_covered))
print()
print("This is the public key: " + target_public_key[2:])
print("I need to find this private key: " + str(pk_orig))
print()
print("Scanning Binary Sequence")
print("Looking in the range: "+str(space_search_start)+" " +str(space_search_end))
print()
while True:
#pk0=random.randint(space_search_start, space_search_end)
for t in range(split_total_keys):
pk0=random.randint(space_search_start, space_search_end)
b=BitArray()
for r in range(multiple_search_keys_at_once): #how many different consecutive keys are generated at once against the keys in DB
target2 = ice.scalar_multiplication(pk0-t*multiple_search_keys_at_once-r)
res=ice.point_loop_subtraction(2*num, target2, sustract_pub)
b = b + (res[t*65+64]%2 for t in range(2*num)) #0 if even, 1 if odd
#2*num -> means we utilize double size of collision margin for each key, in this way we can shift and obtain num windows of num bits
b2 = ()
for r in range(multiple_search_keys_at_once):
for j in range(num):
b2 = b2 + b[(r*2*num)+j:(r*2*num)+j+num] #64 strings of 64 bits
b3 = bytes(b2)
b2_i = [ b3[j*bytes_for_key:j*bytes_for_key+bytes_for_key] for j in range(len(b3)//bytes_for_key)]
set_search_keys = set(b2_i)
with open(data_base_name, 'r+b') as f:
for k in range(split_database):
f.seek(0,1)
partial_db = f.read(size_partial_db)
dat_i = [partial_db[j*bytes_for_key:j*bytes_for_key+bytes_for_key] for j in range(size_partial_db//bytes_for_key)]
set_database = set(dat_i)
a = list(set_database & set_search_keys)
if(len(a) > 0):
s = b2_i
f = dat_i
inx = f.index(a[0])
r_ind = s.index(a[0])
Pk = (pk0 - r_ind//num - (r_ind%num)*sustract - t*multiple_search_keys_at_once) + (k*size_partial_db*8 +(inx*num))*sustract
print("Found!")
if(Pk == pk_orig):
print("The private key " + str(Pk)+ " was recovered successfully!")
data = open("win.txt","a")
data.write("Pk:"+" "+str(Pk)+"\n")
data.close()
sys.exit()
|
|
|
|
la concorrenza maggiore non è (solo) tra i produttori di libri,
ma tra chi produce in prima persona e proprio per questo in modo inefficiente e chi produce per vivere (in cambio di soldi), e per questo è 'costretto' all'efficienza.
Interessantissimo punto di vista. Per chi acquista un bene/servizio l'inefficienza di per sè è negativa, in quanto l'inefficienza viene fatta pagare all'acquirente (che paga in qualche modo più di quello che dovrebbe) invece quando si tratta di inefficienza "gratuita", allora è il produttore che ci mette dentro più valore, il che è un bene per il destinatario del prodotto quindi l'inefficienza gratuita insieme all'efficienza a pagamento funzionano bene entrambe per i consumatori finali In taluni casi l'efficienza rappresenta un limite per chi deve mantenere profittevole il proprio lavoro, e questo limite può andare a discapito dell'utilizzatore finale che riceve meno di quello che avrebbe potuto (ad esempio un prodotto che per esigenze di costi di produzione ha una qualità inferiore di quella possibile) A parte che quell'annuncio in particolare è sostanzialmente pubblicità ingannevole: https://www.youtube.com/watch?v=rI0X6be5zC4se l'avvento dei computer e di internet ha permesso ai singoli youtuber di produrre video (magari in perdita, ma con piccoli costi) e di metterli così in concorrenza 'sleale' con televisioni e mass media organizzati (che una volta erano gli unici a possedere il monopolio della produzione e della trasmissione dell'informazione) così in futuro l'AI potrebbe offrire un'alternativa a basso costo nella trasmissione e applicazione della conoscenza/competenza; fino ad oggi il modo più efficiente per disporre di una competenza specifica era servirsi di una persona (figura professionale) che aveva investito tempo ed energia per poter in modo rapido utilizzare una certa competenza quando ce ne fosse stato bisogno, domani potrebbero concretizzarsi alternative a basso costo automatizzate (diagnosi mediche, lezioni, ...) già adesso ci sono assistenti virtuali allo studio, tu fai una foto a un'equazione matematica scritta a mano e l'app te la risolve, commentando passaggio per passaggio |
|
|
|
... un soggetto, inteso in forma aggregata, che opera in perdita costante ...
La questione delicata è: " il soggetto in forma aggregata" dal mio punto di vista se l'avidità spinge i singoli attori verso un'economia di scala per migliorare efficienza e guadagno, la gratuità invece richiede un impegno personale non delegabile, 'perdere' funziona come strategia se è una scelta personale (anche perchè la ricompensa morale è personale) a livello di comunità mettersi insieme per 'perdere soldi collettivamente' toglie motivazione e stimolo alla faccenda già mettere d'accordo un condominio sarebbe difficile, un paese intero la vedo molto difficile. L’idea è affascinate. Sarebbe un bel “controsenso”: avere nell’industria più competitiva ed a più alta intensità di capitale al mondo un soggetto, inteso in forma aggregata, che opera in perdita costante, fornendo una ulteriore spinta competitiva.
Un paio di esempi di questo 'controsenso' in un altro contesto: 1) molti youtuber producono gratuitamente contenuti di qualità altissima (parlo ad esempio di matematica e fisica) tutto questo lavoro gratuito o semigratuito entra in forte competizione con il lavoro retribuito; in soldoni, se un docente non si prepara più che bene le lezioni, fra poco per lo studente sarà più utile rimanere a casa a guardare dei video su youtube piuttosto che seguire certe lezioni a scuola 2) pensa al confronto tra libri di testo a pagamento e le moltissime risorse gratuite che si trovano online, la presenza di quest'ultime spinge all'innovazione l'industria tradizionale dei libri di testo, che deve confrontarsi con nuovi livelli di efficienza comunicativa; la concorrenza maggiore non è (solo) tra i produttori di libri, ma tra chi produce in prima persona e proprio per questo in modo inefficiente e chi produce per vivere (in cambio di soldi), e per questo è 'costretto' all'efficienza. |
|
|
|
Ok but how you image to work with bigger size of range, the nearest 2**130…? How much ram do you need to generate such equation ?
I don't image to work with bigger size of range. At this level the problem in my opinion is to shrink the size of database. That's all. To "cover" a 2**130 space, you need 2**65 keys with distance 2**65. 2**65 keys with 128 bits (at least) for each key means 2**73 bit = 2**70 bytes, 1 Billions of TB. If you use the script of the OP, 2**65 keys = 2**65 bits = 2**62 bytes = 4 Millions of TB. These are the numbers. These script are made for fun, not to become rich. |
|
|
|
start_key = 2**49
num_public_keys = 2**50
bits_to_store = 64
bytes_to_store = bits_to_store//8
rate_of_key_to_generate = 2**20 Actually, I already figured it out, the difference is just 2**49) 2**49 / 2**20 = 2**29 keys stored in DB. 2**20 keys generated in search script against 2**29 keys generated in create_database script = 2**49 couples. I presume that the probability of collision is not low with these numbers. The script is not optimized, it is only a proof of concept. It needs some work. Try with bits_to_store = 96, in this way the probability of collision is lower. |
|
|
|
Ah, I uploaded a version of create_database that doesn't match with that version of the search_pk script
Now it should work:
It works for me up to 0x81 and after that it does not seem to find any keys. I tried deleting and recreating the database from 0x80 but still nothing found. 0x80 = 128 What are you parameters? Like these? start_key = 1
num_public_keys = 2**32
bits_to_store = 64
bytes_to_store = bits_to_store//8
rate_of_key_to_generate = 2**20
|
|
|
|
|
Show Posts
