Bitcoin Forum
June 16, 2024, 08:03:37 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
121  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 27, 2020, 05:04:25 AM
I switched to CUDA10.2 at the 1.6. can it be the reason of your keyrate issue ? Wrong driver ?
122  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 27, 2020, 04:58:31 AM
I uploaded the new release with the -wsplit option.
IMHO, this is a great option.
It does not prevent to solve the key even if the hashtable is reseted at each backup because paths continue and collision may occur in the small hashtable.
Of course merging offline should solve before.

On the little test i did (reset every 10seconds, DP10), the server solved the 64bit key in 1:41
The merge solved after 1:12

Code:
[Client 0][Kang 2^-inf][DP Count 2^-inf/2^23.05][Dead 0][04s][2.0/4.0MB]
New connection from 127.0.0.1:58358
[Client 1][Kang 2^18.58][DP Count 2^-inf/2^23.05][Dead 0][08s][2.0/4.0MB]
New connection from 172.24.9.18:52090
[Client 2][Kang 2^18.61][DP Count 2^16.17/2^23.05][Dead 0][10s][4.2/14.1MB]
SaveWork: save.work_27May20_063455...............done [4.2 MB] [00s] Wed May 27 06:34:55 2020
[Client 2][Kang 2^18.61][DP Count 2^20.25/2^23.05][Dead 0][20s][40.1/73.9MB]
SaveWork: save.work_27May20_063505...............done [40.1 MB] [00s] Wed May 27 06:35:06 2020
[Client 2][Kang 2^18.61][DP Count 2^20.17/2^23.05][Dead 0][30s][37.9/71.5MB]
SaveWork: save.work_27May20_063516...............done [37.9 MB] [00s] Wed May 27 06:35:16 2020
[Client 2][Kang 2^18.61][DP Count 2^20.55/2^23.05][Dead 0][41s][48.9/82.8MB]
SaveWork: save.work_27May20_063526...............done [48.9 MB] [00s] Wed May 27 06:35:27 2020
[Client 2][Kang 2^18.61][DP Count 2^20.29/2^23.05][Dead 0][51s][41.1/74.9MB]
SaveWork: save.work_27May20_063537...............done [41.1 MB] [00s] Wed May 27 06:35:37 2020
[Client 2][Kang 2^18.61][DP Count 2^20.30/2^23.05][Dead 0][01:02][41.5/75.2MB]
SaveWork: save.work_27May20_063547...............done [41.5 MB] [00s] Wed May 27 06:35:48 2020
[Client 2][Kang 2^18.61][DP Count 2^20.28/2^23.05][Dead 0][01:12][40.9/74.6MB]
SaveWork: save.work_27May20_063558...............done [40.9 MB] [00s] Wed May 27 06:35:58 2020  <= offline merge solved there
[Client 2][Kang 2^18.61][DP Count 2^20.19/2^23.05][Dead 0][01:22][38.5/72.2MB]
SaveWork: save.work_27May20_063608...............done [38.5 MB] [00s] Wed May 27 06:36:08 2020
[Client 2][Kang 2^18.61][DP Count 2^20.55/2^23.05][Dead 0][01:33][48.8/82.7MB]
SaveWork: save.work_27May20_063618...............done [48.8 MB] [00s] Wed May 27 06:36:19 2020
[Client 2][Kang 2^18.61][DP Count 2^19.98/2^23.05][Dead 0][01:41][33.5/66.8MB]
Key# 0 [1S]Pub:  0x03BB113592002132E6EF387C3AEBC04667670D4CD40B2103C7D0EE4969E9FF56E4
       Priv: 0x5B3F38AF935A3640D158E871CE6E9666DB862636383386EE510F18CCC3BD72EB

Concerning your hashrate problem I don't see any trivial reason, do you see timeout or error message at the client level, may be the server is a bit overloaded ?
I'm investigating...
123  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 27, 2020, 04:17:39 AM
Yeah, i turn off because a work file is visible bigger on realtime.
I would try your suggestion and give you opinion later.
I have 2^30.08/2^32.55 now so it is bad moment again to make changes in source, but i would try with -g. On 10 machines my hashrate was down do 200mkeys/s and no workload activity  on GPUS in nvidia-smi... Still connected .. what can be reason? Hashrate real would be ~ 13000mkeys , not 200😁

OK, I'm adding a -wsplit option to the server, it will reset the hashTable at each backup and save to fileName + timestamp. eg save39.work_27May20_061427.
This will decrease RAM usage, improve server performance for insertion. The merge can be done offline without stopping the server.
124  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 27, 2020, 03:03:23 AM
I saw the number of kangaroos in the counter (probably 2^33.08), but I do not remember, because after turning off the server to change the save file - again I see 2^inf only, so I

Wow 2^33.08 kangaroo ! With DP23, the overhead is still a bit large.
Why do you turn off the server ? The work file is too big ?
If I was you, I would reduce the grid size of the GPUs and/or reduce the GPU_GRP_SIZE to 64.
By reducing the gridx and gridy by 2 and the GPU_GRP_SIZE to 64 you will have 2^30 kangaroo and will be nice with dp23.
You will probably loose in performance. Make a test on a single GPU of each type to see what is the performance with reduced grid and GPU_GRP_SIZE.
You can also engage less machine and try to see what is the best trade off.

Yes if you turn off the server, at the reconnection, the kangaroo are not counted, i will fix this.

Jean_Luc, I want to look at the table which is saved to workfile. But as I understood, only 128bit are saved for X-coordinate and 126bit for distance (together with 1 bit for sign and 1 bit for kangaroo type).

Anyway, what is the easiest way to receive the whole table in txt format. I easily could read from binary file the head, dp, start/stop ranges, x/y coordinates for key. After that the hash table is saved with a lot of 0 bytes....
Can you just briefly describe the hash table structure which is saved to binary file?

Yes the 0 are the HASH entry header, if you have lots of 0, the hash table is not very filled.
As mentioned above, you can have a look at the HashTable::SaveTable() function to understand the format.
125  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 06:45:46 PM
My RAM value has allow me to launch DP=22 when i divide them /2.
There was good ?Smiley

Yes, launch with -d 23, that should be enough.
126  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 05:19:31 PM
- should I continue with CURRENT clients?

No

- if not - what should the start command of new clients look like?

Starts by default, if not enough ram at the server side, get the default grid size of each GPU and divide the second number by 2 in order to minimize number of kangaroo, it still not enough memory at the server side divide also the first number by 2. The new server give the total number of kangaroo, total number of kangaroo*2^dpbit should not exceed 2^54.

- what should the server start command look like?

I don't know your exact config but if my "383 boards" estimation is OK, use -d 24 maybe 25 if you have enough RAM.
Expected RAM should not exceed RamOnYourSytem/2.

- what is the most reasonable option for me right now?

Keep your present work28 file, start server and clients from scratch and save every hour or 2 hours the server file, do not restart the server and try a merge offline with your old save28, it may solve the key.


As MrFreeDragon, Do not send fund to 1FoundByJLPKangaroo111Bht3rtyBav8, only one satoshi (0.00000001 BTC) from the solved address if you want to please me Smiley
127  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 03:43:20 PM
If somebody found a key, I would really appreciate that 1 satoshi from the solved address is given to
1FoundByJLPKangaroo111Bht3rtyBav8
Thanks Wink
-snip-
Is this the address you control the private key, or did you just create "beautiful" address? So funds sent there will be burned...

A beautiful address Smiley

@jean luc maybe you can manage it to create a community server and when key will be found everyone get the piece for the work he have done.

And you will get your dev fee btc too

Quite a hard task to make it secure and to develop...
128  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 02:53:24 PM
Edit: but when for ex. we want create pool to do job toghether, we don`t know how many kangaroos will be totaly, because we don`t know how many GPU will be used.
How calculate correct DP in that case?

If you launch a server and you wait for an arbitrary number of kangaroo you cannot choose an optimal DP.
So it could be good to choose it according to the RAM you have on the server but you may fall in RAM overflow if too much kangaroo participate.
In that case, the server should be much improved: it must manage kangaroos and distribute kangaroo to clients. This is a hard task.

129  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 02:40:45 PM
If somebody found a key, I would really appreciate that 1 satoshi from the solved address is given to
1FoundByJLPKangaroo111Bht3rtyBav8
Thanks Wink


@etar
If you choose DP=26 you still have a large overhead (you will need 2 times more iterations), DP=24 should be ok but needed RAM will also growth.
130  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 01:59:01 PM
I like the race between HardWareCollector and zielar Smiley

To choose the DP mask, you first have to calculate your kangaroo number.

460000Mkeys with 2080 Ti (default setting) at ~1.2GKs
=> 383 boards * 2^21.09 = 2^29.6 kangaroo
DP28 => overhead = 2^29.6 * 2^28 = 2^57.6

The overhead here is greater than the expected number of iteration.
As said by HC, DP28 is too large for so much kangaroo and 109bit range.

I recall choose nbKangaroo * 2^dpbit the smallest possible comparing 2^55.5

Edit:
And avoid restarting clients, each time you restart a client, you add more kangaroos and stop others (you break paths)

Edit 2:
The suggested DP is a bad approximation and depend on number of kangaroo, so it differs from a configuration to an other.
131  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 01:40:02 PM
Yes I switched to Visual Studio 2019 and Cuda 10.2.
Unfortunately I can't build Cuda 10 in the next few days.
132  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 01:01:01 PM
I published the 1.6.
133  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 11:53:38 AM
The total number of jumps is equal to number of DP * 2^dpbit => 2^(28+28.7) = 2^56.6 (2 times more)
But I don't the total number of kangaroo to evaluate the overhead ?
For the seed I will switch to cryptosecure rng.

Kangaroos should collide at ~sqrt(n)/NumKangaroos jumps. Otherwise something is very wrong.

Right, i mean total number of jumps.
134  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 11:22:16 AM
No there is not yet feedback to eliminate dead kangaroo and when 2 kangaroos collide in the same herd they starts to produce a new dead at each dp but this is normal only one DP is added to the hash table.

An other things is when you reach ~sqrt(n) jumps, kangaroo starts to walk their neighbor.

As there is no feedback, the number of dead will increase a lot. At this stage, it is better to restart clients.

If 2 clients choose a same starting position you have dead kangaroos since the beginning.
Here I need to improve the seed which is at the second, so if 2 clients starts at the same second they will be identical and dead will increase at high speed immediatly when they starts.

To evaluate the chance of falling in a above trap, you need to know the total number of kangaroo which is used to determine the DP overhead.

I will also add a kangaroo counter in the server to help.

I will publish a release with server fix, -o option, idle client closure timeout to 1 hours, and add a kangaroo counter.

The probability to find the key at ~2*sqrt(n) jumps is roughly 50% and should be roughly 80% at 4*sqrt(n) jumps (this does dot take in consideration the DP overhead).

Edit: If you change NB_JUMP, you break the compatibility with previous work file.
Edit2: If you decrease DPbit, you will still be able to use the previous work file, a DP with 20 leading 0 bits is also a DP with 18 leading 0 bits...

135  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 26, 2020, 03:36:05 AM
Thank you very much for your commitment. Without your immediate action it would not have happened in a month :-) 3 hours have just passed without restarting with 92 machines loaded, so I can confirm that the problem has been solved!

That's great !

On my side the server ends correctly after 5h25 on the 80bit test and the clients were correctly closed.

Code:
Kangaroo v1.5dbg
Start:B60E83280258A40F9CDF1649744D730D6E939DE92A2B00000000000000000000
Stop :B60E83280258A40F9CDF1649744D730D6E939DE92A2BE19BFFFFFFFFFFFFFFFF
Keys :1
Range width: 2^80
Expected operations: 2^41.05
Expected RAM: 344.2MB
DP size: 18 [0xFFFFC00000000000]
Kangaroo server is ready and listening to TCP port 17403 ...
[Client 3][DP Count 2^20.69/2^23.05][Dead 0][46:36][53.5/87.4MB]
New connection from 127.0.0.1:59904
[Client 4][DP Count 2^23.68/2^23.05][Dead 158][05:25:15][412.7/522.3MB]
Key# 0 [1S]Pub:  0x0284A930C243C0C2F67FDE3E0A98CE6DB0DB9AB5570DAD9338CADE6D181A431246
       Priv: 0xB60E83280258A40F9CDF1649744D730D6E939DE92A2BE19B0D19A3D64A1DE032

Closing connection with 172.24.9.18:51060

Closing connection with 172.24.9.18:51058

Closing connection with 127.0.0.1:59813

Closing connection with 127.0.0.1:59904
136  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 25, 2020, 08:18:12 PM
I Would be very happy if #110 will be solved tomorrow Smiley
137  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 25, 2020, 06:52:14 PM
that what we found.. you say that "this check is added on the dgb version" so in that case this led to errors in early version.
thanks a lot for job! Hope server will work like sharm.

This check was already there in the first debug release tested by zielar that crashes.
As I said, in normal condition a corrupted hash should not happen.
The thing that seems to solve the problem is that:

thread.cpp
Code:
#ifndef WIN64
  pthread_mutex_init(&ghMutex, NULL); // Why ?
  setvbuf(stdout, NULL, _IONBF, 0);
#else
  ghMutex = CreateMutex(NULL,FALSE,NULL);
#endif

I did that already on linux, and added a "why" ? in the comment because I didn't understand this.
On Linux without the reinitialization on the mutex on the Processthread function of the server, it results in an immediate hanging although there was not lock of this mutex before.
On windows, it seems that the mutex does not work correctly and that the local DP cache can be corrupted.
The mutexes are initialised in the class constructor so in the main thread.
So I think the issue is due to the ownership of the mutex but this is not not yet fully clear.
3h10 without crash....

138  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 25, 2020, 06:17:59 PM
-snip-

Yes, this is why the Read function has a loop until it reached the end of the transmission.
I prefer to do like this rather than extending the packet length.
the new server is stil running: 2h07, 2^22.28 DP. i cross the finger Smiley
i test release 1.5 (not debug version):
connect to server, send byte=2 to server(comand to send DP), than i send word=1(mean 1DP will be send), than send random 40bytes(like DP) than server return me status 0(mean ok) and crashed!


The number of DP is on 4 byte. But if you send a random hash, on the original 1.5, they're is no check of the hash validity so when added to the hashtable you have an illegal access. This check is added on the dgb version. However, on normal situation this should not happen. The server is badly protected against protocol attack.
2h35 without chrash...

139  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 25, 2020, 05:49:05 PM
@jeanLuc maybe i am wrong but i can`t see  in the code any limits on the number of transferred DP for 1 time.
Packet in tcp connection can send only 65536 bytes max. I don`t know which size have 1 DP
Maybe huge rig can produce a lot of DP and when send this amount to server this overhead packet and can cause unxpected error?
When i send BIG file in my app to server i divide this file on part each not more than 65536bytes.

Yes, this is why the Read function has a loop until it reached the end of the transmission.
I prefer to do like this rather than extending the packet length.
the new server is stil running: 2h07, 2^22.28 DP. i cross the finger Smiley
140  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: May 25, 2020, 04:43:48 PM
I uploaded a new dbg file (which is in fact a release)
May be a problem of mutex ownership.
I have a this server running since one hour with 4 clients,2^21.2 DP without problem

Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!