really 256 x v100? that would be damn impressive ;-)
Yes that right. 256 x Tesla V100. With the GPU kernel of kangaroo optimized for V100 we have a power of 0.5Tera group operation per second. |
|
|
|
what exactly do you need to search a pubkey for? what's the point?
let's say you have found a pubkey with funds, so?
Personally We (me and zielar) are searching only for puzzle transactions, we have found 2 keys together with funds and of course, we got them ! |
|
|
|
|
Note that AI can solve "smooth" problems. So it is not possible to create a neural network to try to solve ECDLP because crypto over elliptic curve is highly non linear (contrary of smooth) and this non linearity is the base of the blockchain security. Lots of tests of non linearity (unpredictablty) are performed before that a hash function or a crypto system is used.
|
|
|
|
Why did you limited it to 125 bit range?
Exactly because of what said by TheArchaeologist, 125 bit range is already very large range will require ~1 year on 256 V100. If you count only the energy, puzzle #110 and #115 was with benefit but #120 is not or you need to get a low cost electricity. Anyway, the mods to do in order to increase this limit is simple. Yes, but only a fraction of all adresses have published their pubK... I think it would be best to create an AI for this task.
Even considering this small faction, you will still have more odds to win with a kangaroo or rho program. |
|
|
|
Rather than searching for addresses you should search for pubkey with funds (there are a lot) with a kangaroo or rho program. It will be much faster, ~2.4e19 years with rho or kangaroo against ~9e28 years with address finder (on 256xTelsa V100)  Do not use my kangaroo program which is limited to 125 bit range key search ! Edit: For instance this pubkey: 02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c (1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx) hold 69370BTC |
|
|
|
@student If you are looking for full addresses, do not enter in the list a part of them (for instance the 15 first char) It will be faster to enter full addresses. That's true that there is 2^96 priv key for an address and if you perform 2^96 key you will find a collision but that would also imply that you search for the whole address range, on the blockchain there is no 2^160 address with fund and it is not possible to have a file of 2^160 address. So if you want to find a collision between 2 priv key that give the same address, consider using BTCCollider which would require "only" 2^80 operations to reach the collision. https://github.com/JeanLucPons/BTCCollider |
|
|
|
What about removing completely the jD array?
If I remove the distance, I will have to redo walk to get the distance in case of a collision and will make merge difficult with kangaroo indexing, and impossibility to check a work file integrity. The work file will have to contain starting positions and a merge will imply reindexing of the workfile. When working with work file of hundreds of GB, it will take time. A intermediate solution could be to redo the walk of each DP at the output of the GPU but here this is tricky as while the GPU is working, the CPU is occupied to do network transfer of DP. |
|
|
|
1- A script that determines if an addition has reached the end of the curve and looped
If you add 2 points and you know only one of the priv key of the 2 points, you cannot know if you make a turn or not otherwise ECDLP could be solved easily in polynomial time. |
|
|
|
|
VanitySearch can search for fulll adresses but it is unlikely it founds something.
I will try tomorrow with a set of addresses an see if I manage to reproduce the issue.
|
|
|
|
is there maybe some cuda environment setting i'm missing or havent set ?!
Do you have the same issue with the 1.17 and CUDA 10.0 ? However I have significant speed loss if I am searching for a large number of prefixes.
When searching, are you using only compressed, both, only uncompressed ? |
|
|
|
@Jean Luc
If I solved a key at the 100 bit range and I want to reuse the dp file generated from that search, how do I reuse it to search for another pubkey in the exact same range and using the exact same dp?
You just merge the file, but at the moment you will take benefit only from old tames. |
|
|
|
Yes that's normal, the kangaroo counter works fine the first time and when a reconnection happens, the counter is not incremented again but the kangaroo are there. When a reconnection happens, the server does not display new connection. I will fix this ASAP, it is just a display bug. 10 reflects the number of clients which have send DP in the last hour. You can work around this by changing in Constant.h the IDLE timeout. // Timeout before closing connection idle client in sec
#define CLIENT_TIMEOUT 3600.0
The important thing to check is the production of DP using -winfo on the server workfile(s). |
|
|
|
|
You are using a too small DP, too much DPs enter in the HashTable and slow down the search.
The expected RAM to reach 50% probability is 60GB.
And last but not least, you CPU work also and prevent the other threads to work.
Try DP17 or 18 and use -t 0 (no CPU) option.
Kangaroo.exe -d 17 -t 0 -gpu -gpuId 0,1,2,3 -g 136,128,136,128,136,128,136,128 in.txt
|
|
|
|
I tried your tool (DP18) on a V100. [2020-06-22.11:35:35] [Info] DP: 0 TP: 0 853.74 Mpt/s (64 iter/s)
[2020-06-22.11:35:37] [Info] Verifying 40336 results
[2020-06-22.11:35:45] [Info] DP: 0 TP: 0 992.50 Mpt/s (75 iter/s)
[2020-06-22.11:35:48] [Info] Verifying 40362 results
[2020-06-22.11:35:55] [Info] DP: 0 TP: 0 991.18 Mpt/s (75 iter/s)
Kangaroo on a server too, configured in the same way, however, it is not clear how many kangaroo are running in parallel with your program and what grid setting is used. GPU: GPU #0 Tesla V100-PCIE-16GB (80x64 cores) Grid(160x128) (207.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
SolveKeyGPU Thread GPU#0: 2^21.32 kangaroos [11.2s]
[2000.07 MK/s][GPU 2000.07 MK/s][Count 2^37.48][01:52][Server OK]
|
|
|
|
If you can compile the last release, you can do: pons@linpons:~/VanitySearch$ ./VanitySearch -cp 1A838B13505B26867
PrivAddr: p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZM21gaY8WN2CdwnTG57
PubKey: 0230210C23B1A047BC9BDBB13448E67DEDDC108946DE6DE639BCC75D47C0216B1B
Addr (P2PKH): 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe
Addr (P2SH): 32xNiwhBsssQikVNaRPzxpp4UZKc7F789h
Addr (BECH32): bc1q2tnk8f7acx4yl2q327xyj8qmcl74wqfhz3w3zh
|
|
|
|
Tell me is there any option to use multiply GPU on BitCrack or Vanity because i have 1k Gpu idle
What kind of gpu ? |
|
|
|
I don't have any news from Zielar since 2 days, Maybe he has taken few deserved holidays  With the new release, we have a power of 0.5Tops |
|
|
|
|
Ah Ok, the timeout for idle client is 1hour, after the connection is closed. However when the client will send new DP, the connection is restored.
|
|
|
|
|
What about your issue with server which drops client ?
Did you remove the VALIDITY_CHECK ? Is is better ?
|
|
|
|
|
Show Posts
