-snip-
for you 1000 pubkeys in 54 bit range total time for check ?
i don`t know how many time was spent for test but calc say that need average time 2^ 3.8s for 1 Pub with 20Mop/s on CPU in short i can say for check 1000 keys from 54 bit, your actual work close to 74/75/76 bit range and it should be 54 bit total keys x 1000, and get your bit range for real work should be, btw you all are working in opposite direction, you are trying to change resource like dp, G etc, and in my view most fast way is reverse corresponding pubkey, leave all dp files of 115 as its, and just try my 80 pubkeys for 115 bit already generated dp file, and it will save 80% work and time instead to shift dp/G into 120 bit Etar i will give you experiment in other downbit range, in PM mode, then u will come to know whats difrence |
|
|
|
-snip-
Etar
if i am not wrong
you have 49 bit 1000 pubkeys
you shift dp file to 54 bit
and you have this info
" Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 "
if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange
76 bit = 75557863725914323419135
54 bit = 18014398509481983
distance = 4194303 for 1000 pub key
and for 1 pubkey = 419.4303
and for 32*g = 134217.72
in short you used tooo much time as compare to equal 76 bit work
hope u understand
2^37.93 for ALL pubkeys for 1 pubkeys average op is 2^27.98And i didn`t have 1000pubkeys in 49bit range. I solve 1 keys and convert work file to range 54bit. In 54bit i solve 1000pubkeys run any random pubkey for 76 bit, and see you need these 2^37.93 for finish for you 1000 pubkeys in 54 bit range total time for check ? |
|
|
|
-snip-
Etar
if i am not wrong
you have 49 bit 1000 pubkeys
you shift dp file to 54 bit
and you have this info
" Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 "
if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange
76 bit = 75557863725914323419135
54 bit = 18014398509481983
distance = 4194303 for 1000 pub key
and for 1 pubkey = 419.4303
and for 32*g = 134217.72
in short you used tooo much time as compare to equal 76 bit work
hope u understand
2^37.93 for ALL pubkeys for 1 pubkeys average op is 2^27.98And i didn`t have 1000pubkeys in 49bit range. I solve 1 keys and convert work file to range 54bit. In 54bit i solve 1000pubkeys run any random pubkey for 76 bit, and see you need these 2^37.93 for finish |
|
|
|
-snip-
The gain (- 5,4%) is little, how many DPs have you generated for the key in 49 bit?
-snip-
DP Count : 240568 2^17.876 in 49bit workfile. i have source file and converted file. I can share if you want to verify DPs. But each DP after multiplication was verifed with G' and x-coordinate correct. DP bits : 8
Start : 40000000000000
Stop : 7FFFFFFFFFFFFF
Key : 025C396BA4347253BBAAFFAC6D4F9BA092847B27F2599EB2EB225DDA54F9964190
Count : 0 2^-inf
Time : 00s
DP Size : 9.3/30.6MB
DP Count : 240568 2^17.876
HT Max : 8 [@ 01D30E]
HT Min : 0 [@ 000001]
HT Avg : 0.92
HT SDev : 0.95
-snip-
"Total op was 261530636052 = 2^37.93" this for 1000 pubkey or only one ?
For 1000 pubkeys -snip-
Etar, this is a CPU or GPU version ?
Test done on CPU Etar if i am not wrong you have 49 bit 1000 pubkeys you shift dp file to 54 bit and you have this info " Expected operations 2^28.06, Total op was 261530636052 = 2^37.93 " if i am not wrong you total op 2^38 work = to search 1 pubkey in 2^76 bitrange 76 bit = 75557863725914323419135 54 bit = 18014398509481983 distance = 4194303 for 1000 pub key and for 1 pubkey = 419.4303 and for 32*g = 134217.72 in short you used tooo much time as compare to equal 76 bit work hope u understand |
|
|
|
It is necessary to use same jumps otherwise path are incompatible.
And the mean has also to be controlled.
Implementing changing of G is rather an heavy task so I would like to have at least an estimation of the loss due to the fact that all paths of new DP will have all points multiple of 32.
We will probably also use DP28 or DP27 for #120
finally you agree, to go back at normal work for 120 as worked for 115, no implements, no changes, no new developments,  |
|
|
|
Jumps (the points) are the same, only their private keys are different;
So in practical, I let the old #115 DP as they are and for the new search #120 I use inv(32)*G instead of G ? yes above is 1 point, and you need 2.5 points (25dp) in search so if i generate 80 (2.5 per point) coresponding pubkeys, that could save more 80% time saving those 80 keys only need to search in old 115bit save.work file but i know u r hesitate to multipubkeys so better use inv(32)*G instead of G with 1 pubeky more over for 25dp, you can go more downbit to 25bit down, final bit range would be 95bit, but with 2.5m corresponding pubkeys can you imagine, where you can stand in finding solution ( time and resources ) |
|
|
|
Jumps (the points) are the same, only their private keys are different;
So in practical, I let the old #115 DP as they are and for the new search #120 I use inv(32)*G instead of G ? yes above is 1 point, and you need 2.5 points (25dp) in search so if i generate 80 (2.5 per point) coresponding pubkeys, that could save more 80% time saving those 80 keys only need to search in old 115bit save.work file but i know u r hesitate to multipubkeys so better use inv(32)*G instead of G with 1 pubeky |
|
|
|
Hi,
I don't understand well how this can work ?
If you change G, the path will also differ as jumps are a function of the X value.
Jumps (the points) are the same, only their private keys are different; instead of using, for example, 2543*G as jump, you use (2543*32)*G', where G' = inv(32)*G in this way the points are the same and the paths are the same. The same interval A = [1G, 2G...., (2^114 - 1)*G] can be viewed as B = [32*G', 2*32*G'...., 32*(2^114 - 1)*G'] and this interval is a subset of the interval C = [1*G', 2*G', 3*G',...., (2^119 - 1)*G'] Note that C has the same number of elements of D = [1*G, 2*G, ...., (2^119 - 1)*G] but C != D. To recap: A = B, A subset C A subset D What is the difference? Why using C instead of D? The advantage is that the old DPs, that lie in A = B, lie in C too, but now they are uniformly spread out in C, while the same points are not uniformly spread out in D. Now, P lies in the interval D, not in C, but P' = inv(32)*P does, and the private key of P' respect to G' is the same as the private key of P respect to G. ----------------------------------------------------- Note: C is not the original interval D = [0*G, 2*G, ...., (2^119 - 1)*G], C is a 'contraction' of D, on other hand the very original interval (where the real public key P lies) is E = [2^119 *G, ..., (2^120 - 1)*G]. Usually you shift E to D and P to P' = P - 2^119*G; note that it is like you changed G to G' = G - 2^119G. Now I suggest to add another move: move D to C and P' to P'' = inv(32)*P' ; I call this move a 'contraction', because I divide G by 32. Actually you r saying upword in multiple mode And i said long time ago downside multiple mode. Upside *32 mean u still stand 1 part of 32 part And down side u r stand for 32/1 So i know this stage of multiple pub keys you have 90% work n time savings. Hope u will not understand. Other jean luc will leave everything and rush to develop multipub key search ver . Bc after long junps in thinking he will come to this stage in last Example i said 2 x 100 = 200 But he listening 2+2+2 till 200 2+3 till 200 2x2 x2 till 200 Hope u all moving slowly to multiple keys or multiple bits But dont try to understand my words. As its from brainless |
|
|
|
If we attack #64, we will try all priv key one by one, compute the HASH160 until we get a match.
With few mods, the vanitySearch engine can do that. Kangaroo is not usefull here.
For one by one bitcrack could work too. Even peoples created group pool for find 64. Like client server sharing |
|
|
|
Yes thanks for this tip  I'm building a map to compute with accuracy the DP overhead as I didn't yet managed to get the correct analytical expression but only the 2 asymptote (0 and infinity) Tomorrow I will also investigate how long would it take with the VanitySearch engine optimized for V100 to solve #64. Then we will make our choice on attacking #64 or #120. private key for 115 ? |
|
|
|
You have computed about 2^58.36 steps. And you know now the private keys of 2^33.36 DPs in the [1, 2^114 - 1] interval (why you said [2^114,2^115-1]? you know only one public key P in [2^114, 2^115 - 1] range, all the public keys/points you have computed lie in [1, 2^114 - 1])
Yes you're right. I ve forgotten that the start range was shifted to zero. shame on me It will help to solve #120.  my Question you misunderstand example i have 2 pubkeys in 115bit range, 1 key found, for 2nd key how i can use that work file for find in less time, ?? |
|
|
|
Unfortunately I don't see how to reuse the work file on a different range.
This work file is for [2^114,2^115-1].
If you translate the kangaroos, the paths will differ so you have to redo all the job.
There was an interesting question in a previous message of this topic:
Why paths are important and why not adding DP without computing paths ?
Using only DP:
It is like drawing a random number in a reduced space N/2^dpbit so time to solve will be O( sqrt(N/2^dpbit) )
However, it is true, that you can reach a DP faster in this way by computing consecutive points.
Using paths:
It is like drawing a bunch of 2^dpbit random points at each DP, so time to solve is O( sqrt(N)/2^dpbit )
The "gain" using path is 2^dpbit while without paths, the "gain" is only sqrt(2^dpbit)
So even if reaching a DP without path is faster, the gain is not enough to beat path.
" I don't see how to reuse the work file on a different range. This work file is for [2^114,2^115-1]." no different range, same range [2^114,2^115-1] and pubkey of this same range too, then ? in short if an other pubkey is of range [2^114,2^115-1] as workfile already for this[2^114,2^115-1] range |
|
|
|
Congratulations for breaking the World Record too. Good job The last world record was 112 bits, right? Thanks The world record on standard architecture was also 114 bit but on a 114 bit field. Here we have solved a 114bit key on a 256bit field. So yes, we broke the world record on classic architecture  The world record on FPGA is 117.25 bit, it was done using up to 576 FPGA during 6 months. With our architecture, we expect 2 months on 256 V100 to solve #120 (119bit keys), we will see if we will attack it. Yes I will send the satoshi to 1FoundByJLPKangaroo... but before I'm waiting Zielar who is offline at the moment. We will publish the private in a while when altcoin will also be moved. as now you have work file for 115 bit, can we apply an other 115 bit pubkey for check inside your 300gb workfile, and what aspected time to find solution ? |
|
|
|
We (me and zielar) solved #115 after ~2^33.36 DP (DP25) (More than 300GB of DP). I do not know exactly how long the run takes due to unwanted interruption. Congratulations did you forget to send some satoshi to 1FoundByJLPKangaroo111Bht3rtyBav8 |
|
|
|
-snip-
In fact - at the current # 115 level - at all costs everything tries to prevent it from finding the key - from hardware - data loss and tedious restore due to a storm - by placing it ... - nevertheless, together with Jean_Luc_Pons managed to rebuild and improve this arduous process and process continues. This gave a lot of lessons in preparation for # 120.
What I will say more - that the 50% threshold was already exceeded when I mentioned it recently. Over the next hour I will give you the exact statistics from the current situation. It is certain, however, that this time is not as lucky as before and the work is still in progress.
Did you implement the feedback from server to clients? If no - that means that the clients continue to perform "useless work" moving the dead "zombi" kangaroos: If you have let's say 100 different machines working independent, you reproduce only the dead kangaroos found within one machine only (machine 1 reproduce dead kangaroos only found by itself). After merging all these 100 files on the server, the server finds a lot of dead kangaroos however does not send back signal to clients to reproduce them. Clients continue working with that "zombi" because they do not have feedback from the server. That also means that during the next merging the server will receive again the same kangaroos, the server will kill them again, but the "zombies" will continue their jumps on client side. And so on. This could cause the very inefficient work for wider ranges like #115 or more. if jean luc created multi pubkey ver in time, maybe the job for 115 is only for 1 day with zieler gpus at 85bit range anyway they had agreemnet, and cant think beyond thier creation+GPU's |
|
|
|
Thanks for the help. I was able to compile a file for your clients. The program helped fix the extension as needed bat and txt. I started it after 3 minutes at 1050 and got an answer in 65save.txt, but I could not read everything there in hieroglyphs. Help explain how further please.
download and install emeditor right click file and open with emeditor, there is all option and format for open file |
|
|
|
-snip-
mean 789.789 is value can u div pubkey by above value ?
devider must be integer not float. all pubkeys Q=k*G, where k - integer. btw let me say, highest value in ecc is 1 1 = 115792089237316195423570985008687907852837564279074904382605163141518161494337. 0 and above to 0 is 0.11579208923731619542357098500868790785283756427907490438260516314151816149433 7 so each and every digit have value, and i can div them in integar and float too actual low then 1 is called is fractional point,and i can play with each and every point |
|
|
|
-snip-
if need div 789.789 then ?
what you mean? you can devide point only by integer. mean 789.789 is value can u div pubkey by above value ? |
|
|
|
-snip-
BitCrack
apply your algo and show me pubkey div by 789 for
03D041CF467F485A96AB21EC0E1E1E26A344B28A12244320C4BDE48C123653D88F
035776b3684b6a5e9a6307aa53c3d484aabb90244e6371405c114cf8910a9a3bd0 if need div 789.789 then ? |
|
|
|
@mrxtraf
In the private key group (mod n) we can add, negate, and invert - this allows for multiplication and division.
In the public key group (elliptic curve mod p of size n) we can add, negate, and double only. This leads to multiplication by a scalar.
One public key corresponds to exactly one private key, and vice versa. The proof is very easy. Let G is the generator of secp256k1. Let P=k*G is a point on the curve. Let also P=k'*G. Then (k-k')*G=O => (k-k') divides n. But n is prime, hence k=k' (mod n).
That is, you can’t divide the public key by 10? Give me any public key from which you know the private key, I will divide it by 10. And I will give in return the result in the form of a public key. And you yourself divide the private key by 10, get the public key from it and compare. The multiplication (and division, which is multiplication with the inverse) is by scalar only. You cannot multiply two public keys without solving ECDLP first. And if you somehow can, then all coins are belong to you. mrxtraf is saying they can "divide" the public key by 10 by multiplying the public key by the multiplicative inverse of 10 mod n. BitCrack apply your algo and show me pubkey div by 789 for 03D041CF467F485A96AB21EC0E1E1E26A344B28A12244320C4BDE48C123653D88F |
|
|
|
|
Show Posts
