Ho fatto una prova veloce sulla mia macchina,impiega 20 secondi, nettamente più veloce dell'altro.  No so se usi qualche libreria particolamente ottimizzata in C per fare i calcoli o quale compiler, però potrebbe esserci la possibilità di spingersi oltre a livello di prestazioni implementando il tutto in assembly. Probabilmente lo saprai già comunque, quando compili in C, il compilatore crea un approssimazione del codice in assembly, in base a quanto lo fa intelligentemente ci sarà un calo minimo di prestazioni paragonato ad un implementazione full assembly. Esistono librerie già pronte ed ottimizzate in Assembly per effettuare operazioni matematiche che sono scontate in altri linguaggi. Detto questo sono 10 anni circa che non metto mano a codice assembly e l'ho utilizzato solo all'università, quindi bisognerebbe capire bene prima se ne vale la pena. Tutto il codice delle operazioni base come moltiplicazione tra 2 numeri di 64 bit , eccetera è stato scritto da me "a mano" in questa forma: #define MultiplyWordsLoHi(low, high, a, b) asm ( "mulx %2, %0, %1;" : "=r"(low), "=r"(high) : "gr" (a), "d" (b) : "cc");
Non so se sia possibile ottenere tanto di più a livello di prestazioni ... |
|
|
|
Ho provato un pò lo script (un'altra versione che hai pibblicato ecc_for_collider5.py, non trovo il link ora dal telefono) in python è parecchio veloce ~60 secondi per 16.4M chiavi pubbliche, non mi sono ancora addentrato nei dettagli del funzionamento e relativa spiegazione. Magari dipende dalla versione di python che uso 2.7, ma ho notato che alcune coordinate non sono 32 byte, la stringa che le rappresenta ha un carattere in più per qualche motivo. Non ho ancora verificato nel dettaglio con che frequenza capita, magari domani riesco a controllare un pò meglio. Comunque ottimo lavoro, grazie Non offendiamo, la mia libreria migliore in python impiega meno di 6,5 secondi per generare 16.4 milioni di chiavi pubbliche! Utilizzando gmpy2. Poi mi sono stufato di python e sono passato a C (50 milioni di chiavi in 1 secondo). Penso che la versione che hai scaricato tu sia più leggibile, comunque ti allego la più veloce (la 08). Per quanto riguarda la stampa, se stampa a video una L finale, L sta per long. Se ci sono altri problemi fammi sapere. $ time python2 gen_batches_points08.py
private key: -lambda*(k+m)G
0x2a7fb67883ea214c0a96f75b449fa3cec8e1b0d1f1e65e8aa80c3ef6cffaa1ae
('0x1c98a16eb218925feea48547a41d9d07bbd757d696857b4c2072bd264c827938', '0x49963b55d6a149f0df12d4acd5065e26b3e9d4f7da9c56aab690f44e866afe16')
*******
private key: -lambda*(k-m)G
0x6554827e46f82b9e6c571fdc6ae54b90dfdd38c4a3daf5213f3b4ee41119b8f8
('0x3c8250f180d59f9f1deeb55dbe00deb835de8a774c2fe1e6231b9eb44cdb3148', '0x7fcc26c9d9b58dd0971e87dd475c9d535a393cd5cf2cc62d53d4130cef611b6b')
*******
You have just generated 16 Millions of keys!!!
real 0m6,460s
user 0m6,456s
ecc_for_collider08.py import gmpy2
from gmpy2 import mpz
#see http://www.secg.org/sec2-v2.pdf at page 9
#Gx=55066263022277343669578718895168534326250603453777594175500187360389116729240
#Gy=32670510020758816978083085130507043184471273380659243275938904335757337482424
#p=115792089237316195423570985008687907853269984665640564039457584007908834671663
#n=115792089237316195423570985008687907852837564279074904382605163141518161494337
Gx=mpz(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
Gy=mpz(0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8)
p=mpz(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F) # Fp
n=mpz(0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141) # E(Fp)
#endomorphism
lambd=mpz(0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72) # (lambda^3 = 1 mod n)
lambd2=mpz(0xac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce) #(lambda^2)
beta=mpz(0x7ae96a2b657c07106e64479eac3434e99cf0497512f58995c1396c28719501ee) # (beta^3 = 1 mod p)
beta2=mpz(0x851695d49a83f8ef919bb86153cbcb16630fb68aed0a766a3ec693d68e6afa40) # (beta^2)
############################################################################################
###Field operations
#a must be a number between 1 and p-1; input: a output: 1/a
#see http://www.springer.com/?SGWID=4-102-45-110359-0 page 40 alg. 2.20
def inv(a,p):
u, v = a%p, p
x1, x2 = 1, 0
while u != 1:
#q = v//u
#r = v-q*u
q, r = divmod(v,u)
x = x2-q*x1
v = u
u = r
x2 = x1
x1 = x
return x1%p
#inverse of a batch of x
#input: batch of x : [x1,x2,x3,x4,x5,x6,x7,x8,...,x2048]
#x is known (x of kG)
#output: batch of inverse: 1/(x1-x), 1/(x2-x), 1/(x3-x), ....
#3M for each inverse
def inv_batch(x,batchx,p):
a = (batchx[1]-x) % p
partial= [0]*2049
partial[1]=a
for i in range(2,2049):
a = (a*(batchx[i]-x)) % p #2047M
partial[i]=a
inverse=gmpy2.invert(partial[2048],p) # 1I
#inverse=inv(partial[2048],p) # 1I
batch_inverse=[0]*2049
for i in range(2048,1,-1):
batch_inverse[i-1]=(partial[i-1]*inverse) % p #2047M
inverse=(inverse*(batchx[i]-x)) %p #2047M
batch_inverse[0]=inverse
return batch_inverse
############################################################################################
##Group operations
# https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication#Point_addition
#'double' addition
#add 2 points P and Q --> P+Q
#add 2 points P and Q --> P-Q
#
#(X1,Y1) + (X2,Y2) --> (X3,Y3) (the inverse of (x2-x1) must be known)
#(X1,Y1) + (X2,-Y2) --> (X4,Y4) (the inverse of (x2-x1) must be known)
#
#input: (X1,Y1), (X2,Y2), the inverse of (X2 - X1): 5 scalars
#output: (X3,Y3), (X4,Y4) : 4 scalars
#4M + 2S
def double_add_P_Q_inv(x1, y1, batchG, batchinvx2x1):
batch=[0]*2048
for i in range(1,2049):
x2,y2 = batchG[i]
invx2x1 = batchinvx2x1[i]
dy = (y2-y1) #% p
a = dy*invx2x1 % p #1M
a2 = a**2 #1S
x3 = (a2 - x1 -x2) % p
y3 = (a*(x1-x3) -y1) % p #1M
dy = p-(y2+y1) #% p # only the sign of y2 changes, "y of -Q = -y of +Q"
a = dy*invx2x1 % p #1M x2 and then the inverse invx2x1 are the same
a2 = a**2 #1S
x4 = (a2 - x1 -x2) % p
y4 = (a*(x1-x4) -y1) % p #1M
batch[i-1]=(x3,y3,x4,y4)
return batch
#https://en.wikibooks.org/wiki/Cryptography/Prime_Curve/Jacobian_Coordinates
#jacobian coordinates
def add_j_j(jax, jay, jaz, jbx, jby, jbz):
u1 = (jax*jbz**2) % p
u2 = (jbx*jaz**2) % p
s1 = (jay*jbz**3) % p
s2 = (jby*jaz**3) % p
h = (u2-u1) % p
r = (s2-s1) % p
jcx = (r**2 -h**3-2*u1*h**2) % p
jcy = (r*(u1*h**2-jcx)-s1*h**3) % p
jcz = (h*jaz*jbz) % p
return jcx, jcy, jcz
def double_j_j(jx, jy, jz):
s = (4*jx*jy**2) % p
m = (3*jx**2) % p
jx2 = (m**2 - 2*s) % p
jy2 = (m*(s-jx2) - 8*jy**4) % p
jz2 = (2*jy*jz) % p
return jx2, jy2, jz2
def mul(k,jx,jy,jz):
jkx, jky, jkz = 0, 0, 1
if (k%2 == 1):
jkx, jky, jkz = jx, jy, jz #only if d is odd
q=k//2
while q>0:
jx, jy, jz = double_j_j(jx,jy,jz)
a=q%2
if (a > jkx):
jkx, jky, jkz = jx, jy, jz #only if d is even
elif (a):
jkx, jky, jkz = add_j_j(jx, jy, jz, jkx, jky, jkz)
q=q//2
return jkx, jky, jkz
############################################################################################
#Coordinates
#from jacobian to affine
def jac_to_aff(jax, jay, jaz, invjaz):
ax, ay = (jax*invjaz**2) % p, (jay*invjaz**3) % p
return ax, ay
gen_batches_points08.py #!/usr/bin/env python
#this script computes 6x667 batchs of 4097 points (1 single point + 2048 couples of points -> (kG+mG, kG-mg))
#16,4 millions of points
#3 : 1 batch + 5 endomorphism
from ecc_for_collider08 import *
########################################################################
#in this section the script pre-computes 1G, 2G, 3G, ..., 2048G
mG = [(0,0)]*2049
mGx = [0]*2049
mGy = [0]*2049
mGx[1]=Gx
mGy[1]=Gy
mG[1]=(Gx,Gy) #list of multiples of G,
#you have to precompute and store these multiples somewhere
mGx[2]=mpz(0xC6047F9441ED7D6D3045406E95C07CD85C778E4B8CEF3CA7ABAC09B95C709EE5)
mGy[2]=mpz(0x1AE168FEA63DC339A3C58419466CEAEEF7F632653266D0E1236431A950CFE52A)
mG[2]=(mGx[2],mGy[2])
for i in range(3,2049):
jx,jy,jz=add_j_j(Gx, Gy, mpz(1), mGx[i-1], mGy[i-1], mpz(1)) #this is not a efficient way, but it is not important
jzinv = inv(jz,p)
(x,y) = jac_to_aff(jx, jy, jz, jzinv)
mG[i] = (x,y)
mGx[i] = x
mGy[i] = y
###########################################################################
lowest_key=2**55+789079076 #put here the lowest key you want to generate
number_of_batches=667 # #put here how many consecutive batches you want to generate
number_of_keys=4097*6*number_of_batches #this is the number of consecutive keys you are going to generate
#this number is always a multiple of 6*4097=24582, because 24582 is the minimum size
#remember: you generate always 6 batches at once, 1 in (1,2^160) and 5 out of this range
#their name are: main_batch (the main), batch2, batch3, batch_minus
#(these other batches are derived from the main with endomorphism or complement private keys)
id_batch=lowest_key+2048 #id_batch is now the private key of the middle point of the first batch that you want compute
distance_between_successive_batches=4097 #this is the distance from the middle point of the first batch and the middle point
#of the successive batch in (1,2^160)
#4097 means that I'm generating only consecutive batches in (1,2^160), this is the default
start=id_batch #the first key to generate of the the first batch is the lowest key + 2048 -->
#the middle point of the first batch
stop=id_batch + number_of_batches*distance_between_successive_batches #the key of the middle point of the last batch
#k is always the id of the current main batch and the key of the middle point of the current main batch
for k in range(start,stop,distance_between_successive_batches):
jkx,jky,jkz = mul(k,Gx,Gy,mpz(1)) #here we use the slow function mul to generate the middle point
#invjkz = inv(jkz,p)
invjkz=gmpy2.invert(jkz,p) # 1I
(kx,ky) = jac_to_aff(jkx, jky, jkz, invjkz)
kminverse = [0]*2048
kminverse = inv_batch(kx,mGx,p) #you need to compute 2048 inverse, 1 for each couple
#to perform this task you need only the x coordinates of the multiples of G and
#the x coordinate of kG: kx
kminverse = [invjkz]+kminverse
#the element number 0 of the list is the inverse invjkz that you have computed to get kG=(kx,ky)
#the element number 1 of the list is the inverse necessary to perform kG + 1G (and kG-1G)
#---> 1/(x_of_1G - kx)
#the element number 2 of the list is the inverse necessary to perform kG + 2G (and kG-2G)
#---> 1/(x_of_2G - kx)
#...
#the element number m of the list is the inverse necessary to perform kG + mG (and kG-mG)
#---> 1/(x_of_mG - kx)
#then the name: "kminverse", the inverse to get the generic kG+mG
#...
#the element number 2048 of the list is the inverse necessary to perform kG+2048G and kG-2048G
#---> 1/(x_of_2048G - kx)
main_batch=[(0,0,0,0)]*2048
#the element number 0 of the list will be the middle point kG=(kx,ky), you can see it as the couple ((k+0)G, (k-0)G)
#the element number 1 will be the couple (k+1)G, (k-1)G
#the element number 2 will be the couple (k+2)G, (k-2)G
#...
#the element number 2048 will be the couple (k+2048)G, (k-2048)G
#each element of this list is a couple of points -> 4 scalars: x_(k+m)G,y_(k+m)G,x_(k-m)G,y_(k-m)G,
#but the first element is only a fake couple
main_batch = double_add_P_Q_inv(kx,ky,mG,kminverse)
#_the function double_add_P_Q_inv computes kG +/-mG, it uses the list of the inverse and return a list of couple of points
#each element of this list is a couple of points, 4 scalars, x_(k+m)G,y_(k+m)G,x_(k-m)G,y_(k-m)G
#this list has 2049 elements
main_batch = [(kx,ky,kx,ky)]+main_batch #the element number 0 of the list is now the middle point kG=(kx,ky), you can see it as the fake couple (k+0)G, (k-0)G
batch2=[0] * 2049 #this is the batch2 with lambda*kG, ( lambda*(k+1)G, lambda*(k-1)G ), ( lambda*(k+2)G, lambda*(k-2)G ), ....,
# (lambda*(k+2048)G, lambda*(k-2048)G)
#this list actually has only the x-cooordinates of the points, because the y-coordinates are the same of main batch
#each element of this list is a couple of x -> 2 scalars: x_lambda*(k+m)G, x_lambda*(k-m)G
#this list has 2049 elements
batch3=[0] * 2049 #this is the batch3 with lambda^2*kG, ( lambda^2*(k+1)G, lambda^2*(k-1)G ), ( lambda^2*(k+2)G, lambda^2*(k-2)G ), ....,
# (lambda^2*(k+2048)G, lambda^2*(k-2048)G)
#this list actually has only the x-cooordinates of the points, because the y-coordinates are the same of main batch
#each element of this list is a couple of x -> 2 scalars: x_lambda^2*(k+m)G, x_lambda^2*(k-m)G
#this list has 2049 elements
batch_minus=[0] * 2049 #the complement private keys of the other batches
for i in range(0,2049): #endomorphism + the complement private keys
x1,y1,x2,y2=main_batch[i]
batch2[i] = [(x1*beta % p), (x2*beta % p)] #only x coordinates, the first and the third scalar of each element
#of the main batch
#private key: lambda*k mod n, coordinate x: beta*x mod p
batch3[i] = [(x1*beta2 % p), (x2*beta2 % p)] #only x coordinates, the first and the third scalar of each element
#of the main batch
#private key: lambda^2*k mod n, coordinate x: beta^2*x mod p
batch_minus[i]=[(-y1 % p), (-y2 % p)] #only y coordinates, the 2^ and the 4^ scalar of each element of all batches
#k in this case is the id of the last batch (or if you prefer, k is the private key of the middle point of the last batch)
m=2048 #a random number between 0 and 2048, you can pick up a couple of points in the last main batch (or in batch2 / batch3)
(kmx1,kmx2)=batch2[m]
(kmy1,kmy2)=batch_minus[m] #in this case the points chosen are in batch3
#the y are from batch_minus
#(kmx1,kmy1,kmx2,kmy2)=main_batch[m]
print ('private key: -lambda*(k+m)G')
print (hex(-lambd*(k+m)%n)) #private key
print (hex(kmx1), hex(kmy1)) #public key (first and second coordinate)
print ('*******')
print ('private key: -lambda*(k-m)G')
print (hex(-lambd*(k-m)%n)) #private key
print (hex(kmx2), hex(kmy2)) #public key (first and second coordinate)
print ('*******')
print (' ')
a=number_of_keys//1000000
print ('You have just generated ' + str(a) + ' Millions of keys!!!')
|
|
|
|
@arulbero
I have an idea about #58. Can I message you the details?
Just to be clear: that is the time I need to recover the private key from the public one (using a cpu), to do a brute force I would need a gpu (or more) and a different program. It is completely different. |
|
|
|
In teoria la penso anche io come te, però quello che succede in realtà è che per via della complessità nel far funzionare il sistema dei meriti e fallibilità umana, non funziona come dovrebbe sfortunatamente.
I sistemi perfetti nella pratica non esistono, mi basta osservare che la direzione presa sia quella giusta, poi la realizzazione non lo è mai. Il punto è che con post di quella caratura, a questo punto dovresti avere ricevuto piu meriti di theymos (o almeno più di quelli che ho ricevuto io, per rimanere conservativi) visto che questo è un forum su bitcoin e sulla sua tecnologia principalmente.
Non esiste il concetto di merito "intrinseco", il riconoscimento per definizione ti viene sempre dagli altri. E quindi il riconoscimento dipende anche e soprattutto dall'interesse che gli altri hanno di certi argomenti. I merit svolgono in questo forum un po' la stessa funzione dei soldi nella nostra società. Il denaro serve a ripartire la ricchezza prodotta dalla società in parti "giuste", quantificando il valore (merito) del lavoro di ciascuno rispetto a quello altrui. Un errore sarebbe credere che questo valore sia "oggettivo", non lo è, riflette un riconoscimento altrui dettato dagli interessi che gli altri hanno, basta essere consapevoli di questo limite intrinseco del denaro. Per esempio nella nostra società se sai giocare bene a pallone hai un riconoscimento in termini economici molto superiore a quello ottenuto mediante altre attività, e questo semplicemente perchè la maggioranza delle persone apprezza di più vedere una partita di calcio (e spendere per vederla) rispetto ad altri tipi di servizi. In questo forum pensa ai lavori di statistica (e non solo) di gbianchi, quanti pochi riconoscimenti ha avuto? O il libro di gallisiardi? E bada bene che io non dico che questo sia ingiusto, constato semplicemente che interessa a pochi/minoranza. E' un dato di fatto. Tu scrivi: questo è un forum su bitcoin e sulla sua tecnologia principalmente, io ti rispondo: i thread più seguiti sono quelli (anche nella sezione italiana) su bitcoin pump (= soldi) e questo sul sistema dei merit, quindi quello che più interessa alla maggior parte della gente è la distribuzione della ricchezza e del riconoscimento, e la giustizia nella distribuzione di questi riconoscimenti (i governi sono valutati sulle manovre di tipo economico, distribuzione della ricchezza, se è giusto prendere di più, andare in pensione dopo, condoni, tasse, ...). Ci appassiona insomma molto il tema della giustizia e il tema dei soldi/riconoscimento, tutto il resto è secondario. Tu mi sembra che abbia ottenuto molti merit (meritati) per il bot che hai scritto, il quale serve a informare un utente di essere stato citato, e come vedi ricadiamo nel tema del riconoscimento, questione molto sentita alla fine un po' da tutti. |
|
|
|
About 16.7 MKeys/s, 1 GKeys/min.
Let's say 2^24 Keys/s.
To compute 2 lists of 2^28 keys, it takes 2 * 2^4 seconds, about 30 seconds. That is the time it took to retrieve the key #57.
Have you tried to search a key in space of 10 quadrillion? How many hours you think it can finish that large space? American or British system ? -> https://www.quadrillion.com/number.shtmquadrillion = 10^15 -> 10 quadrillion = 10^16? 10^16 = 2^53 --> 2 lists of 2^26 keys = 2 * 2^2 = 8 seconds quadrillion = 10^24 -> 10 quadrillion = 10^25? 10^25 = 2^83 --> 2 lists of 2^41 keys ? NO! Too much for my RAM! Let's say that the max list size (for my RAM) is 2^28 keys. To retrieve the #59, I need to compute 2 list of 2^29, I have to split the first in 2 * 2^28, then generate the 2^29 keys of the second list 2 times against each half of the first, tot: 2*2^28 + 2*2^29 = 3*2^29 instead of 2*2^29 ( 96 seconds instead of 64 seconds). To retrieve the #61, I need to compute 2 list of 2^30, I have to split the first in 4 * 2^28, then generate the 2^30 keys of the second list 4 times against each quarter of the first list, tot: 4*2^28 + 4*2^30 = 5*2^30 instead of 2*2^30 ( 320 seconds instead of 128 seconds). To retrieve the #63, I need to compute 2 list of 2^31, I have to split the first in 8 * 2^28, then generate the 2^31 keys of the second list 8 times against each part of the first list, tot: 8*2^28 + 8*2^31 = 9*2^31 instead of 2*2^31 ( 1152 seconds instead of 256 seconds). To retrieve the #65, I need to compute 2 list of 2^32, I have to split the first in 16 * 2^28, then generate the 2^32 keys of the second list 16 times against each part of the first list, tot: 16*2^28 + 16*2^32 = 17*2^32 instead of 2*2^32 ( 4352 seconds instead of 512 seconds). Time is for the #(57+x) = (2^(x/2)+1) lists of 2^((57+x-1)/2) keys instead of only 2 lists of 2^(57+x-1)/2 keysFor the #61 = #(57+4) = (2^2+1) * (2^30) = (2^2 + 1) lists of 2^30 -> 5 * 2^6 seconds = about 320 seconds = 5 min 20 secFor the #71 = #(57+14) = (2^7+1) * (2^35) = (2^7 + 1) lists of 2^35 -> 2^7 * 2^11 seconds = about 2^18 seconds = 73 hoursFor the #83 = #(57+26) = (2^13+1) * (2^82/2) = (2^13 + 1) lists of 2^41 -> 2^13 * 2^17 seconds = about 2^30 seconds = 34 years (if I had enough RAM, 2 * 2^41 = 2^42 keys = 2^18 seconds = 73 hours !!! I would need a RAM: 2^13 = 8000 times 32 GB) |
|
|
|
If the public key is revealed it is still safe from bruteforce if the attacker don't know the range of bits to search for?
Of course. Many blocks mined by Satoshi have txs with "pay to public key" script (P2PK) instead of "pay to public key hash" script (P2PKH, pay to address). The public keys are known, but the btc are still there: block #100 https://www.blockchain.com/it/btc/tx/2d05f0c9c3e1c226e63b5fac240137687544cf631cd616fd34fd188fc9020866PUSHDATA(65)[04 e70a02f5af48a1989bf630d92523c9d14c45c75f7d1b998e962bff6ff9995fc5bdb44f1793b3749 5d80324acba7c8f537caaf8432b8d47987313060cc82d8a93] CHECKSIG x = e70a02f5af48a1989bf630d92523c9d14c45c75f7d1b998e962bff6ff9995fc5
y = bdb44f1793b37495d80324acba7c8f537caaf8432b8d47987313060cc82d8a93
|
|
|
|
i merit non servono a chi scrive, servono soprattutto a chi legge. In sostanza i merit servono (o dovrebbero servire) al forum.
Mmmm, mi sa che non ho capito cosa intendi dire. I Merit da "regolamento" dovrebbero essere dati da chi legge a chi scrive se chi legge ritiene interessante/condivisibile quel che ha letto. Se io che leggo li do a te, i Merit saranno utili a te, non a me, giusto ? Oppure intendevi dire che sono utili a chi legge perché fanno identificare a colpo d'occhio i post più interessanti? non penso nemmeno sia così perché quando guardi un post non guardi come prima cosa il fatto che qualcuno lo abbia meritato.... magari lo stai leggendo subito dopo la pubblicazione e nessuno può aver ancora avuto il tempo per dare merit, oppure al contrario rischi di leggere un post con merit dati da qualcuno che invece li ha dati "a caso". Ma forse non ho capito quel che intendevi dire..... Intendevo dire che se si incentiva la scrittura di post validi (con il sistema dei merit) anzichè incentivare solo la scrittura di numerosi post (activity di una volta) il risultato finale è che il livello medio dei post si alzerà (in teoria). Il "lettore" quando valuta positivamente il post di uno "scrittore" riconosce e incentiva il lavoro svolto da chi scrive. I merit vanno quindi a chi ha scritto il post ma questo fatto sostiene indirettamente la scrittura di post migliori, a tutto vantaggio di chi alla fine fruisce del forum (per leggere). Scrivere molto tanto per scrivere (o fare addirittura spam) non paga più come prima. |
|
|
|
i merit non servono a chi scrive, servono soprattutto a chi legge. In sostanza i merit servono (o dovrebbero servire) al forum. È sicuramente un punto di vista interessante e diverso da come l'ho sempre vista io: i Merit, secondo me, sono stati introdotti quasi ed esclusivamente per contenere lo spam dilagante che si verificava nelle sezioni più trafficate (nel bene e nel male noi, come sezione italiana, siamo un'isola felice) Guarda che è quello che ho detto io, contenere lo spam è un servizio agli utenti del forum, forum che in questo modo diventa più leggibile. Se poi non solo non si scrive spam ma si scrive anche qualcosa di interessante meglio ancora. La maggior parte di coloro che scrivono post "utili" è vero che lo fanno per la comunità ma anche per loro stessi ora, per prendere i Merit. Per assurdo era più facile vedere a chi stava a cuore il forum prima dei Merit, perché uno che scriveva post articolati e di senso logico senza ricevere nulla in cambio allora si che lo faceva per passione dato che il suo post aveva lo stesso identico valore del "nice project" menzionato prima.
Penso che quando ti viene offerto un "servizio" (tipo qualcuno che ti informa di qualcosa) non sia poi così rilevante questo tipo di distinzione: quando il cuoco cucina per te al ristorante (e lo fa bene) lo fa al 100% per soldi o anche perchè un po' gli piace cucinare bene per i clienti? Quando uno insegna a scuola lo fa al 100% per soldi o anche un po' perchè gli interessa che i suoi studenti apprendano qualcosa? .... Questa distinzione tra passione e interesse personale la trovo un po' artificiosa, come chiedersi se qualcuno sta con te perchè al 100% vuole bene a te o anche perchè così sta meglio lui/lei (interesse personale), alla fine che senso hanno questo tipo di distinzioni? |
|
|
|
That works only if you have enough RAM to store 2^28 keys. Otherwise that program cannot retrieve #57. Besides if you want to retrieve only #57 and you don't modify the code, it starts always from 1 to 2^57 - 1 (instead from 2^56 to 2^57 - 1) |
|
|
|
Mi capita spesso da questo punto di vista di fidarmi più facilmente di utenti che sono qui da un po' sul forum e dei quali riconosco un certo stile di scrittura e pensiero (una sorta di "marchio" che mi fa subito pensare: ok, è farina del loro sacco).
Capisco il tuo punto di vista, un solo appunto: non dovrebbe esserci il sistema trust per quello? Il trust riguarda soprattutto le transazioni, non il fatto che uno copia quello che scrive. L'altro giorno un utente newbie ad esempio ha semplicemente copiato una parte di un mio post e ha preso il suo primo merit proprio per quel post copiato  Questo accade perchè chiaramente chi ha dato il merit non poteva andare prima a controllare se quel post era già stato scritto da qualcun altro (ci vorrebbero sistemi automatici per questo). Però.... però che te li diamo a fare i merit a te (e a quasi tutti gli altri su citati) visto che sei già al massimo rank ?  io personalmente quando è stato introdotto questo sistema dei merit decisi che avrei dato i merit ai livelli minori, non perché tu o altri legendary non li meritiate (ovvio!) ma perché tutto sommato servono di più ad altri. Non è quindi una scelta fatta per "colpire" te o altri, ma solo perché (scusate se mi ripeto) ad altri servono di più. ...... Per concludere: merit o no, grazie per il contributo che apporti sempre qui. Grazie per i complimenti. Non ho scritto un intervento perchè voglio / ho bisogno di merit, ma perchè ritengo che sia sbagliata proprio la tua impostazione: a chi servono i merit? i merit non servono a chi scrive, servono soprattutto a chi legge. In sostanza i merit servono (o dovrebbero servire) al forum. Il forum è utile per imparare cose nuove, quasi tutti siamo arrivati qui partendo da zero e abbiamo imparato un sacco di cose su bitcoin grazie a coloro che scrivevano delle cose sensate (non per forza ultra tecniche, basta anche rispondere a una domanda di un newbie). L'effetto secondario di partecipare in modo produttivo alla scrittura di post nel forum è di avanzare di rank (prima bastava scrivere, adesso si guarda un attimo anche al contenuto). L'effetto di avanzare di rank è secondario non dal mio punto di vista, ma dal punto di vista della qualità e della fruizione del forum stesso. Detta in altro modo, se domani theymos portasse tutti a Legendary, il forum diventerebbe improvvisamente una fonte di informazioni migliori per questo? No. Semplicemente qualcuno avrebbe più possibilità di fare soldi con le firme (non me ne intendo, ma se il numero di Legendary aumentasse a dismisura le ricompense probabilmente diminuirebbero drasticamente, immagino). |
|
|
|
I search only the last 56 bit (between 2^56 and 2^57 - 1)
Btw why -1? Because 2^57 has 58 digits (in binary form '1' + 57 '0'). Then 2^57 could be the key #58, not #57 key 1 -> 1 bit : 1 ( from 2^0 to 2^1 - 1) key 2 -> 2 bit : from 2 to 3 (from 2^1 to 2^2 - 1) : 10 or 11 key 3 -> 3 bit : from 4 to 7 (from 2^2 to 2^3 - 1) : 100 or 101 or 110 or 111 key 57 -> 57 bit : from 2^56 to 2^57 - 1 key 58 -> 58 bit : from 2^57 to 2^58 - 1 If you look at key #3 .....0000000000000000000000000000000000000000000000000000000000000111 (to address 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA) and at the #4 .....0000000000000000000000000000000000000000000000000000000000001000 (to address 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e) key #3 = 2^3 - 1 = 7 key #4 = 2^3 = 8 |
|
|
|
My code instead uses a different library written by myself for the LBC project.
In your code how many keys can you generate per minute? About 16.7 MKeys/s, 1 GKeys/min. Let's say 2^24 Keys/s. To compute 2 lists of 2^28 keys, it takes 2 * 2^4 seconds, about 30 seconds. That is the time it took to retrieve the key #57. |
|
|
|
Come ti hanno risposto anche nella sezione internazionale, io non penso che la questione sia che "bisogna" dare più merit ai rank minori rispetto a quelli maggiori. Il merit è un riconoscimento della qualità dei post scritti e dovrebbe quindi aiutare a migliorare la qualità dell'informazione che il forum di bitcointalk propone a tutti i suoi partecipanti. Per questo vanno incentivati i post migliori, indipendentemente da chi li scrive. Ne guadagnano tutti se i merit sono assegnati effettivamente per merito e non per altri motivi. E dal mio punto di vista nella sezione italiana questo sta in effetti avvenendo. Il passaggio di rank è anche un effetto dell'attribuzione dei merit, ma il valore di questo passaggio sta nel fatto che sia meritato/guadagnato. Il vero problema che sta alla base della scarsità di circolazione dei merit è che valutare in generale non è un'operazione così semplice / poco costosa come potrebbe sembrare a prima vista: c'è la questione del "plagiarismo", le informazioni sono talmente tanto diffuse su internet e sul forum che è facile che qualcuno sia tentato di copiare e incollare. Mi capita spesso da questo punto di vista di fidarmi più facilmente di utenti che sono qui da un po' sul forum e dei quali riconosco un certo stile di scrittura e pensiero (una sorta di "marchio" che mi fa subito pensare: ok, è farina del loro sacco). Poi c'è la questione dell'interesse, personalmente mi interessano solo alcuni temi/sezioni quindi sicuramente ci sono post meritevoli che non leggerò mai. Ma questo ha anche un suo senso, se un tema suscita poco interesse, un post su quel tema "vale" di meno, per esempio tempo fa avevo scritto un thread con più post molto articolati sulle curve ellittiche che avrà raccolto sì e no 3 merit, e pur essendomi "costato" molta fatica ha raccolto molto meno di altri miei post che ho buttato giù in 5 minuti. Il valore di un post va giudicato dagli altri, da chi legge (e innanzitutto ci deve essere qualcuno che lo legge) Un'ultima osservazione: nella prima fase della storia del forum bisognava incentivare la partecipazione attiva (scrittura di post), ma oggi la situazione è completamente diversa: più utenti ci sono, più post vengono pubblicati, è inevitabile. Soprattutto in sezione internazionale questo è evidente (da noi invece non siamo ancora così tanti). Tutto questo complica ulteriormente la selezione manuale dei post meritevoli, bisogna scavare sempre di più. |
|
|
|
If I get this correctly, you need the Raw Public Key to recover the private key.
But it is not possible to get the Raw Public Key from a Bitcoin Address unless some transaction is done by whoever cracked the private key first, right?
Right! which program you use to generate a large number of address and keys?
You have to use a library tailored to elliptic computations. The most famous is the libsecp256k1 written by Pieter Wuille (it is in Bitcoin Core). These programs https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89 and https://github.com/klynastor/supervanitygen use this library. My code instead uses a different library written by myself for the LBC project. |
|
|
|
Im a bit lost, you mean you create a code that can be run on mobile fast enough to search for the private key of a known public key within a limited search space?
It uses only cpu. If the search space is very limited, it is like you know already many bit of 256. I'm saying: for example, if you provide me: 1) a public key 2) the first 198 bit of the private key then I can recover the last 58 bit of the key. Nothing more. There is no magic, 58 bit is not so much. That is the meaning of the sentence: "the search space is very limited". My code runs on a cpu. So I can use efficiently the Ram of my pc. Gpus are good for hashing computations, cpus are good for elliptic (multi integer precision, 256 bit in this case) computations. I'll try a little explanation: If I know already the first 255 bit, then the search space is 2 (the value for the right key ends with 0 or 1). if I know already the first 254 bit, then the search space is 2^2 = 4 if I know already the first 246 bit, then the search space is 2^10 = 1024 With so small number, any cpu can in less than 1 sec retrieve the correct private key with brute force. Now we talk about the key #57 of the puzzle transaction. We all know that the first 200 bit are 000000.....00001 then I search only the last 56 bit (between 2^56 and 2^57 - 1). With brute force I would need to use 2^56 different private keys to generate 2^56 public keys. Too much time. But If I knew only the address and not the public key, that would be the only way. But If I know the public key too, then I can exploit an algebraic property of the elliptic curve (of all elliptic curves, not only the secp256k1). Then instead of doing 2^56 "computations", I need only to compute a list of 2^28 public keys, put it in Ram, then generate another list of 2^28 public keys and do a comparison between the 2 lists. In this way I get 2^58 combinations (that's the way the Baby Step Giant Step algorithm works). If you look at the links I provided in the previous post you can understand it better. Input data: private key #57 : first 200 bit:
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
(I got it from https://www.blockchain.com/btc/tx/95b77d69302fbc805f1a6e97a3f0d27159017341e5f2d40ec79785d830fe9d59 --> PUSHDATA(33)[02 a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea], look at this answer to understand how to get the y coordinate too) x = a521a07e98f78b03fc1e039bc3a51408cd73119b5eb116e583fe57dc8db07aea
y = 6fb15c871dd7cf7d287390acd4e09d41f705081a98d5fe3a930ca032525dbcdc
: last 56 bit of the private key#57: 11101011001001011100100100000111100101011101011000011100
Now, for the next private key #58: Input data: private key #58 : first 199 bit:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
public key Output data: last 57 bit of the private key#58: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
|
|
|
|
I will look into it but last I looked it wasn't available for any GPUs.
Code is only for cpu. Why GPU? |
|
|
|
Sto provando un pò a sperimentare con bouncy castle per cercare di capire che genere di prestazioni si possano raggiungere tramite l'utilizzo di linguaggi di alto livello, tipo c# e python, usando solo la CPU.
Arulbero hai già fatto qualche esperimento del genere o mi sai consigliare qualche libreria in particolare?
Tempo fa avevo fatto questa in python (python2) https://bitcointalk.org/index.php?topic=1573035.msg17685839#msg17685839ma non so se è molto chiaro il suo utilizzo. Prova a dare un'occhiata (non ricordo le prestazioni, ma non erano pessime) |
|
|
|
|
Show Posts
