Hello everybody.
Is there a way to check public keys at the same time?
how bitcrack checks addresses.
Maybe a kangaroo is a multi-key or something like that?
Or tell me how you check for example 100,000-1,000,000 keys?
It's unrealistic with your hands.
Topic: Pollard's kangaroo ECDLP solver - page 48. (Read 60744 times)
Quote
NotATether, answer please ?
EDIT:
I'm realy not understand how many exact sustracted from pubkey this code:
# This function makes all the downscaled pubkeys obtained from subtracting
# numbers between 0 and divisor, before dividing the pubkeys by divisor.
def shiftdown(pubkey, divisor):
Q = pub2point(pubkey)
# k = 1/divisor
k = pow(divisor, N - 2, N)
for i in range(divisor+1):
P = Q - (i * G)
P = k * P
if (P.y % 2 == 0):
prefix = "02"
else:
prefix = "03"
hx = hex(P.x)[2:].zfill(64)
hy = hex(P.y)[2:].zfill(64)
print(prefix+hx, "04"+hx+hy)
so, if devisor = 5 this mean a just FIVE not any ^ and 2^5 etc.....
Cobra, why not just put 5 at the bottom and run it, see if you get 5 or 32 pubkeys? Put 10 at the bottom and run it, see if you get 10 or 1024 pubkeys...EDIT:
I'm realy not understand how many exact sustracted from pubkey this code:
# This function makes all the downscaled pubkeys obtained from subtracting
# numbers between 0 and divisor, before dividing the pubkeys by divisor.
def shiftdown(pubkey, divisor):
Q = pub2point(pubkey)
# k = 1/divisor
k = pow(divisor, N - 2, N)
for i in range(divisor+1):
P = Q - (i * G)
P = k * P
if (P.y % 2 == 0):
prefix = "02"
else:
prefix = "03"
hx = hex(P.x)[2:].zfill(64)
hy = hex(P.y)[2:].zfill(64)
print(prefix+hx, "04"+hx+hy)
so, if devisor = 5 this mean a just FIVE not any ^ and 2^5 etc.....
DO NOT mess with the code up top, I told you the two areas to tweak, pubkey and qty.
I was divide 120/30, in ECSPcallc.jar, and not foud pubkey in result of scrip work with param 30... not use this script now.
Quote
NotATether, answer please ?
EDIT:
I'm realy not understand how many exact sustracted from pubkey this code:
# This function makes all the downscaled pubkeys obtained from subtracting
# numbers between 0 and divisor, before dividing the pubkeys by divisor.
def shiftdown(pubkey, divisor):
Q = pub2point(pubkey)
# k = 1/divisor
k = pow(divisor, N - 2, N)
for i in range(divisor+1):
P = Q - (i * G)
P = k * P
if (P.y % 2 == 0):
prefix = "02"
else:
prefix = "03"
hx = hex(P.x)[2:].zfill(64)
hy = hex(P.y)[2:].zfill(64)
print(prefix+hx, "04"+hx+hy)
so, if devisor = 5 this mean a just FIVE not any ^ and 2^5 etc.....
Cobra, why not just put 5 at the bottom and run it, see if you get 5 or 32 pubkeys? Put 10 at the bottom and run it, see if you get 10 or 1024 pubkeys...EDIT:
I'm realy not understand how many exact sustracted from pubkey this code:
# This function makes all the downscaled pubkeys obtained from subtracting
# numbers between 0 and divisor, before dividing the pubkeys by divisor.
def shiftdown(pubkey, divisor):
Q = pub2point(pubkey)
# k = 1/divisor
k = pow(divisor, N - 2, N)
for i in range(divisor+1):
P = Q - (i * G)
P = k * P
if (P.y % 2 == 0):
prefix = "02"
else:
prefix = "03"
hx = hex(P.x)[2:].zfill(64)
hy = hex(P.y)[2:].zfill(64)
print(prefix+hx, "04"+hx+hy)
so, if devisor = 5 this mean a just FIVE not any ^ and 2^5 etc.....
DO NOT mess with the code up top, I told you the two areas to tweak, pubkey and qty.
...
Let's go to China ? They can make a BSGS for usb I think.
?
Let's go to China ? They can make a BSGS for usb I think.
?There is no need at the moment. Only for us to solve #120 #125 ... they wouldn't produce it.
But if we can build that network 'Calculating Satoshi's coins' https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791 then it would become interesting to produce it.
Satochi ccoin is a 0.00001 btc per address
...
Let's go to China ? They can make a BSGS for usb I think.?
Let's go to China ? They can make a BSGS for usb I think.
?There is no need at the moment. Only for us to solve #120 #125 ... they wouldn't produce it.
But if we can build that network 'Calculating Satoshi's coins' https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791 then it would become interesting to produce it.
Is there a list with devices/cards and related jumps/sec?
What we need are asics
not to mine coins but for more jumps/sec
and
look at this, may be interesting: Calculating Satoshi's coins https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791
What we need are asics
not to mine coins but for more jumps/sec
and
look at this, may be interesting: Calculating Satoshi's coins https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791
Let's go to China ? They can make a BSGS for usb I think.
?I'm work now with 861 811 060 385 455 217 keys/s but this is not helpful for 120 !!!
Is there a list with devices/cards and related jumps/sec?
What we need are asics
not to mine coins but for more jumps/sec
and
look at this, may be interesting: Calculating Satoshi's coins https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791
What we need are asics
not to mine coins but for more jumps/sec
and
look at this, may be interesting: Calculating Satoshi's coins https://bitcointalksearch.org/topic/calculating-satoshis-coins-5347791
Quote
I try sript with 30 and 34. Then 30 I got 109 pubkeys, then 32 - 137 pubkeys. And Yes - script hard to run, requirements are give me strange errors...
If you are using Python 3.x, all you have to change is:pubkey = '03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4'
to whatever pubkey you want
and at the bottom
shiftdown(pubkey, 32)
change the 32 to however many pubkeys you want.
yes, I do it. I try now find a privkey....
edit: I wright understand what 30,32 etc is a power of 2 ? so If we talk about 120 pubkey, then I use this scripts with "30" I will get pubkey diveded by 2^30 ? so result will be "pubkey of 2^90" ?
NotATether, answer please ?
EDIT:
I'm realy not understand how many exact sustracted from pubkey this code:
# This function makes all the downscaled pubkeys obtained from subtracting
# numbers between 0 and divisor, before dividing the pubkeys by divisor.
def shiftdown(pubkey, divisor):
Q = pub2point(pubkey)
# k = 1/divisor
k = pow(divisor, N - 2, N)
for i in range(divisor+1):
P = Q - (i * G)
P = k * P
if (P.y % 2 == 0):
prefix = "02"
else:
prefix = "03"
hx = hex(P.x)[2:].zfill(64)
hy = hex(P.y)[2:].zfill(64)
print(prefix+hx, "04"+hx+hy)
so, if devisor = 5 this mean a just FIVE not any ^ and 2^5 etc.....
Quote
I try sript with 30 and 34. Then 30 I got 109 pubkeys, then 32 - 137 pubkeys. And Yes - script hard to run, requirements are give me strange errors...
If you are using Python 3.x, all you have to change is:pubkey = '03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4'
to whatever pubkey you want
and at the bottom
shiftdown(pubkey, 32)
change the 32 to however many pubkeys you want.
yes, I do it. I try now find a privkey....
edit: I wright understand what 30,32 etc is a power of 2 ? so If we talk about 120 pubkey, then I use this scripts with "30" I will get pubkey diveded by 2^30 ? so result will be "pubkey of 2^90" ?
Quote
I try sript with 30 and 34. Then 30 I got 109 pubkeys, then 32 - 137 pubkeys. And Yes - script hard to run, requirements are give me strange errors...
If you are using Python 3.x, all you have to change is:pubkey = '03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4'
to whatever pubkey you want
and at the bottom
shiftdown(pubkey, 32)
change the 32 to however many pubkeys you want.
yes, I do it. I try now find a privkey....
edit: I wright understand what 30,32 etc is a power of 2 ? so If we talk about 120 pubkey, then I use this scripts with "30" I will get pubkey diveded by 2^30 ? so result will be "pubkey of 2^90" ?
it was just an example (random k generated)
from 120 puzzle we substract the starting range 800000000000000000000000000000 and we obtain the following K 03D943C68C5F958B14524CDBEF68168D6C018E101F4F7074E0C31686384A82F52F
N/2 - above K = 026C25951D1BB97C7DE3020DF0F725487FC33CC1210A155755514B7BF384AACFAD
From this K which is basically N/2 - Puz120 K + START-RANGE we add random K in the interval (0x1 - 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
We compute 10kk points in the range (N/2 - 10kk, N/2), points which cover the following range if we exclude parity (N/2 - 10kk, N/2 + 10kk)
Maybe i will draw something tomorrow for better understanding.
PS: I'm not saying this method will be exponentially "better" but it will double the chances to find k
Why subtract the starting range when we are going to be adding back to it? Is there a specific reason for that?from 120 puzzle we substract the starting range 800000000000000000000000000000 and we obtain the following K 03D943C68C5F958B14524CDBEF68168D6C018E101F4F7074E0C31686384A82F52F
N/2 - above K = 026C25951D1BB97C7DE3020DF0F725487FC33CC1210A155755514B7BF384AACFAD
From this K which is basically N/2 - Puz120 K + START-RANGE we add random K in the interval (0x1 - 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
We compute 10kk points in the range (N/2 - 10kk, N/2), points which cover the following range if we exclude parity (N/2 - 10kk, N/2 + 10kk)
Maybe i will draw something tomorrow for better understanding.
PS: I'm not saying this method will be exponentially "better" but it will double the chances to find k
I'd just add 120 pubkey straight to N/2 and then do incremental additions.
In your opinion is it better to start below N/2 and then pass through (above N/2) to kind of straddle N/2 on both sides?
I guess I don't understand the excluding parity/y you mentioned earlier and how each pub doubles chance to find K.
EDIT: Ok, regardless of start range subtraction (I get it), how does this possibly speed things up? You would still have to search for key from N/2-whatever through N/2 +1, using kangaroo or BSGS or some other key finder, right? I'm interested, I just don't understand how it speeds it up (however small or big), not saying it doesn't, I'm just trying to understand it better. Thanks.
Quote
I try sript with 30 and 34. Then 30 I got 109 pubkeys, then 32 - 137 pubkeys. And Yes - script hard to run, requirements are give me strange errors...
If you are using Python 3.x, all you have to change is:pubkey = '03a2efa402fd5268400c77c20e574ba86409ededee7c4020e4b9f0edbee53de0d4'
to whatever pubkey you want
and at the bottom
shiftdown(pubkey, 32)
change the 32 to however many pubkeys you want.
it was just an example (random k generated)
from 120 puzzle we substract the starting range 800000000000000000000000000000 and we obtain the following K 03D943C68C5F958B14524CDBEF68168D6C018E101F4F7074E0C31686384A82F52F
N/2 - above K = 026C25951D1BB97C7DE3020DF0F725487FC33CC1210A155755514B7BF384AACFAD
From this K which is basically N/2 - Puz120 K + START-RANGE we add random K in the interval (0x1 - 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
We compute 10kk points in the range (N/2 - 10kk, N/2), points which cover the following range if we exclude parity (N/2 - 10kk, N/2 + 10kk)
Maybe i will draw something tomorrow for better understanding.
PS: I'm not saying this method will be exponentially "better" but it will double the chances to find k
from 120 puzzle we substract the starting range 800000000000000000000000000000 and we obtain the following K 03D943C68C5F958B14524CDBEF68168D6C018E101F4F7074E0C31686384A82F52F
N/2 - above K = 026C25951D1BB97C7DE3020DF0F725487FC33CC1210A155755514B7BF384AACFAD
From this K which is basically N/2 - Puz120 K + START-RANGE we add random K in the interval (0x1 - 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFF)
We compute 10kk points in the range (N/2 - 10kk, N/2), points which cover the following range if we exclude parity (N/2 - 10kk, N/2 + 10kk)
Maybe i will draw something tomorrow for better understanding.
PS: I'm not saying this method will be exponentially "better" but it will double the chances to find k
Sure,
I will just give a simple example.
Lets say you get the key close to the N half, lets take for example a random point 7fffffffffffffffffffffffffffffff5d1777e13d618b66b81ee5de17cf885a (we pushed for example 120 puzzle to this k) which results in
K = 0269da924844fcc5852ef6808f0e0bc9e851bd7b6b23d6e55d4b152ab0101fedfd
The diff between N/2 and our point is 3ff6921a42c4b727ca4968504b9846
With a big enough hash table which we need to compute as we want (random/incremental), lets say we compute from 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681A20A0 to 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 (small example) then our table will contain 0x10000 public keys, but in reality it is 0x20000 (double).
If we discard Y or parity from our K computation when we generate random steps (increments) we have a double change to get it right.
If our random increment difference was bigger than normal hash table size (but not bigger than double) than we will have a match and we can easily compute the right k from the known K.
Dont know if i was clear enough, if not i will try to illustrate it
Made need the illustration now I will just give a simple example.
Lets say you get the key close to the N half, lets take for example a random point 7fffffffffffffffffffffffffffffff5d1777e13d618b66b81ee5de17cf885a (we pushed for example 120 puzzle to this k) which results in
K = 0269da924844fcc5852ef6808f0e0bc9e851bd7b6b23d6e55d4b152ab0101fedfd
The diff between N/2 and our point is 3ff6921a42c4b727ca4968504b9846
With a big enough hash table which we need to compute as we want (random/incremental), lets say we compute from 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681A20A0 to 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 (small example) then our table will contain 0x10000 public keys, but in reality it is 0x20000 (double).
If we discard Y or parity from our K computation when we generate random steps (increments) we have a double change to get it right.
If our random increment difference was bigger than normal hash table size (but not bigger than double) than we will have a match and we can easily compute the right k from the known K.
Dont know if i was clear enough, if not i will try to illustrate it
But one quick question, if we push as you said and the diff between N/2 and our point is 3ff6921a42c4b727ca4968504b9846, would that be big enough to solve since 120 starting range is
800000000000000000000000000000? 120s pubkey added to 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 should at least be a difference of 800000000000000000000000000000, right?
Sure,
I will just give a simple example.
Lets say you get the key close to the N half, lets take for example a random point 7fffffffffffffffffffffffffffffff5d1777e13d618b66b81ee5de17cf885a (we pushed for example 120 puzzle to this k) which results in
K = 0269da924844fcc5852ef6808f0e0bc9e851bd7b6b23d6e55d4b152ab0101fedfd
The diff between N/2 and our point is 3ff6921a42c4b727ca4968504b9846
With a big enough hash table which we need to compute as we want (random/incremental), lets say we compute from 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681A20A0 to 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 (small example) then our table will contain 0x10000 public keys, but in reality it is 0x20000 (double).
If we discard Y or parity from our K computation when we generate random steps (increments) we have a double change to get it right.
If our random increment difference was bigger than normal hash table size (but not bigger than double) than we will have a match and we can easily compute the right k from the known K.
Dont know if i was clear enough, if not i will try to illustrate it
I will just give a simple example.
Lets say you get the key close to the N half, lets take for example a random point 7fffffffffffffffffffffffffffffff5d1777e13d618b66b81ee5de17cf885a (we pushed for example 120 puzzle to this k) which results in
K = 0269da924844fcc5852ef6808f0e0bc9e851bd7b6b23d6e55d4b152ab0101fedfd
The diff between N/2 and our point is 3ff6921a42c4b727ca4968504b9846
With a big enough hash table which we need to compute as we want (random/incremental), lets say we compute from 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681A20A0 to 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 (small example) then our table will contain 0x10000 public keys, but in reality it is 0x20000 (double).
If we discard Y or parity from our K computation when we generate random steps (increments) we have a double change to get it right.
If our random increment difference was bigger than normal hash table size (but not bigger than double) than we will have a match and we can easily compute the right k from the known K.
Dont know if i was clear enough, if not i will try to illustrate it
Another method instead of pubkey reducing is actually increasing it.
Lets not forget about curve properties and how it can actually help us solve a puzzle a little faster.
if you manage to push the K to the right limit in the curve "middle" 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than it will be twice faster.
What i mean with twice faster is that we can try to match a K without parity
If half = 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than all other points after will generate same X but with inverse parity.
Basically it's easier to push the key to the middle and increment it until a match is found because of this property.
Just my 2 cents
I'm tracking, but can you give an example? Lets not forget about curve properties and how it can actually help us solve a puzzle a little faster.
if you manage to push the K to the right limit in the curve "middle" 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than it will be twice faster.
What i mean with twice faster is that we can try to match a K without parity
If half = 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than all other points after will generate same X but with inverse parity.
Basically it's easier to push the key to the middle and increment it until a match is found because of this property.
Just my 2 cents
Another method instead of pubkey reducing is actually increasing it.
Lets not forget about curve properties and how it can actually help us solve a puzzle a little faster.
if you manage to push the K to the right limit in the curve "middle" 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than it will be twice faster.
What i mean with twice faster is that we can try to match a K without parity
If half = 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than all other points after will generate same X but with inverse parity.
Basically it's easier to push the key to the middle and increment it until a match is found because of this property.
Just my 2 cents
Lets not forget about curve properties and how it can actually help us solve a puzzle a little faster.
if you manage to push the K to the right limit in the curve "middle" 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than it will be twice faster.
What i mean with twice faster is that we can try to match a K without parity
If half = 7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 than all other points after will generate same X but with inverse parity.
Basically it's easier to push the key to the middle and increment it until a match is found because of this property.
Just my 2 cents
Jump to: