Latest posts of: Jean

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 »

1	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 29, 2024, 07:06:29 PM
It is possible to reduce a little bit the complexity of the classic kangaroo algorithm by spreading the starting kangaroo in a non uniform maner. Roughly speaking, if the private key lies in certain areas it will be found faster. As a counterpart if it lies in certain other areas it will be found slower. But in average, considering the whole range, the compexity is well reduced. It you read and understand carefully the reference in the gitbub page, you will find the trick

2	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 27, 2024, 07:25:26 PM
Quote from: Chail35 on March 27, 2024, 07:20:52 PM Are you going to modify the code to be able to search the 130 bit? There is a new NVIDIA GPU that was announced, the GB200 which is exponentially more powerful than the current gpus. I don't think so, unless someone proove me he has the needed power and is ready to beat the world record

3	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 27, 2024, 07:13:12 PM
Quote from: AndrewWeb on March 27, 2024, 04:32:59 PM If you have the public key of Puzzle 66, you can find the privat key in seconds. Yes but we don't have it, so brute force and 2^65 itérations for 50% of success, 2^64 for 25% etc...

4	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 27, 2024, 07:22:44 AM
I checked on #125 with a RTX 4500 and a A100 (the H100 is not yet available). The needed time evolve linearly with the number of board and you have to multiply by sqrt(32) for #130 So ~1 year to solve #130 with ~1000 RTX 4500 using this program with the required mods. Kangaroo v2.2 Start:10000000000000000000000000000000 Stop :1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Keys :1 Number of CPU thread: 0 Range width: 2^124 Jump Avg distance: 2^62.04 Number of kangaroos: 2^20.81 Suggested DP: 38 Expected operations: 2^63.10 Expected RAM: 1387.8MB DP size: 38 [0xfffffffffc000000] GPU: GPU #0 NVIDIA RTX A4500 (56x0 cores) Grid(112x128) (147.0 MB used) SolveKeyGPU Thread GPU#0: creating kangaroos... SolveKeyGPU Thread GPU#0: 2^20.81 kangaroos [9.9s] [1514.20 MK/s][GPU 1514.20 MK/s][Count 2^34.77][Dead 0][22s (Avg 207.606y)][2.0/4.0MB] Kangaroo v2.2 Start:10000000000000000000000000000000 Stop :1FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Keys :1 Number of CPU thread: 0 Range width: 2^124 Jump Avg distance: 2^62.04 Number of kangaroos: 2^21.75 Suggested DP: 37 Expected operations: 2^63.10 Expected RAM: 2760.3MB DP size: 37 [0xfffffffff8000000] GPU: GPU #0 NVIDIA A100-PCIE-40GB (108x0 cores) Grid(216x128) (277.0 MB used) SolveKeyGPU Thread GPU#0: creating kangaroos... SolveKeyGPU Thread GPU#0: 2^21.75 kangaroos [22.7s] [3824.79 MK/s][GPU 3824.79 MK/s][Count 2^33.84][Dead 0][06s (Avg 82.0929y)][2.0/4.0MB] --------- With a H100 (PCIe) (on #130) Kangaroo v2.2 Start:200000000000000000000000000000000 Stop :3FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF Keys :1 Number of CPU thread: 0 Range width: 2^129 Jump Avg distance: 2^64.01 Number of kangaroos: 2^21.83 Suggested DP: 40 Expected operations: 2^65.62 Expected RAM: 1985.4MB DP size: 40 [0xffffffffff000000] GPU: GPU #0 NVIDIA H100 PCIe (114x0 cores) Grid(228x128) (292.0 MB used) SolveKeyGPU Thread GPU#0: creating kangaroos... SolveKeyGPU Thread GPU#0: 2^21.83 kangaroos [23.3s] [5113.99 MK/s][GPU 5113.99 MK/s][Count 2^34.26][Dead 0][06s (Avg 352.678y)][2.0/4.0MB] You can find the cotation of the hypervisors we use for scientific calculation there (page 12 of my presentation): https://indico.esrf.fr/event/93/contributions/559/

5	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 26, 2024, 05:30:22 PM
I'll try tomorow with a H100 (if free) just to see the performance. At my job we have only gpu dedicated to scientific calculus which may be less adapted to integer calculus than a 4090. In any case it will require a large number of boards and considerable amout of time to get the BTC

6	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: March 25, 2024, 06:01:56 PM
After quick look at kangaroo code, looks like there is 3-bits of 128-bit value used for something. So, it actually really 125-bit max. I can be wrong and I think only JLP can answer 100%. [/quote] Hello, Yes you are right. The GPU code should also be modified to return good distances. Do not try to solve this puzzle, it will take years using a rendering farm !

7	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: October 11, 2020, 07:11:47 PM
Yes, if you specify manually the same seed, the calculation will be the same.

8	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: October 11, 2020, 05:51:12 PM
Quote from: shlomogold on October 11, 2020, 05:11:13 PM does this mean that if we could've recreated someone's system at a time (same OS, processor, time and date, etc.), we could be closer to generating the same keys this person generated back then or am I completely misunderstanding how it works? Theoretically it is not possible. The system gets entropy from keyboard inputs, disk usage, network, etc... Then it computes secure hashes from that inputs to generate random number.

9	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: October 10, 2020, 03:17:30 PM
There is no way with VanitySearch to specify a priv key range.

10	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: October 09, 2020, 03:20:21 PM
Note that with VanitySearch, the generation of the base key (if no seed specified) is done through secure RNG of the system: CryptGenRandom() for windows and /dev/urandom for linux.

11	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: September 11, 2020, 01:45:37 PM
The final private key reconstruction is explained in the README for the simple case https://github.com/JeanLucPons/VanitySearch#how-it-works This is what is done at the line 323 of main.cpp. Then you find the 5 other cases for symmetry and endomorphism. The information of which case (out of the 6) has matched during the search is not in the partial key file, the reconstruction just test the 6 cases until one match. For the reconstruction of a BECH32 address, you simply compute a BECH32 address from the final private key, this is what is done the CHECK_ADDR() macro at line 238 of main.cpp. Note: The secret private key passed through the command line for reconstruction is stored in e. Code: #define CHECK_ADDR() \ fullPriv.ModAddK1order(&e, &partialPrivKey); \ # Compute the final private key (partialKey + secretKey mod n) p = secp->ComputePublicKey(&fullPriv); \ # Compute the corresponding public key cAddr = secp->GetAddress(addrType, compressed, p); \ # Compute the corresponding address (for BECH32, addrType=2 defined in SECP256k1.h) if (cAddr == addr) { \ # Test if it matches found = true; \ string pAddr = secp->GetPrivAddress(compressed, fullPriv); \ string pAddrHex = fullPriv.GetBase16(); \ outputAdd(outputFile, addrType, addr, pAddr, pAddrHex); \ }

12	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: September 09, 2020, 02:00:25 PM
Quote from: Atariko on September 08, 2020, 06:50:19 PM Quote from: Jean_Luc on September 08, 2020, 04:12:00 PM Quote from: Atariko on September 08, 2020, 03:51:25 PM Why is there no answer? Jean Luc ask for an answer on this question. All data I have provided. I'm sorry but I didn't manage to reproduce the issue. It is the same if you try to reduce the grid size ? When reducing the grid, the error -GPUEngine: Launch: unspecified launch failure. And when enlarging the grid, the error -GPUEngine: Kernel: too many resources requested for launch. https://fex.net/ru/s/sfypzfa link to check I tried your file and for me it is ok... Code: C:\C++\VanitySearch>x64\Release\VanitySearch.exe -t 0 -gpu -g 320,256 -i 500.txt VanitySearch v1.19 Search: 500 addresses (Lookup size 33,[3,47]) [Compressed] Start Wed Sep 9 15:57:18 2020 Base Key: E7D91B106BF65AFD901C7E2ED61D78DFD4C2EB2C8CCDFE8C108A40DABFCF8443 Number of CPU thread: 0 GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(320x256) [188.53 Mkey/s][GPU 188.53 Mkey/s][Total 2^33.61][Prob 0.0%][50% in 1.70385e+32y][Found 0]

13	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: September 08, 2020, 04:12:00 PM
Quote from: Atariko on September 08, 2020, 03:51:25 PM Why is there no answer? Jean Luc ask for an answer on this question. All data I have provided. I'm sorry but I didn't manage to reproduce the issue. It is the same if you try to reduce the grid size ?

14	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: September 08, 2020, 10:33:44 AM
Quote from: bigvito19 on September 08, 2020, 10:20:57 AM @Jean_Luc What exactly is the base key and why we can't manually change it? The base key is the key used for starting calculation from. This key is transformed (translation,symmetry and endomorphism) until the target prefix is reached. This base key is generated randomly or from a pass phrase. There is no way to set it manually to a specific value.

15	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: September 08, 2020, 06:11:27 AM
In fact a parallel kangaroo program that look for a single key creates several pubkeys from this key (by simply translating it). So this is a multi key search but this does not decrease the probability to solve this single key. It just allows a simple parallelization. Usually, for a multi target attack, the first key has no benefit but the following keys can gain from the previous calculation. If you want to search a pubkey with a x starting with 32 leading F (between n and p), you will have to perform ~2^128 group operations.

16	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: September 04, 2020, 05:56:28 AM
Quote from: Marynarz on September 03, 2020, 05:41:24 PM Unfortunately I am not using Kangaroo in server mode. The wsplit option works also for normal mode. It is a very useful option to avoid large hashtable in RAM which decrease performance. If you plan to have a large master workfile (>100GB), you can use partitioned workfiles for speeding up the merge process. https://github.com/JeanLucPons/Kangaroo#how-to-deal-with-work-files

17	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: September 03, 2020, 01:51:11 PM
Quote from: Marynarz on September 01, 2020, 08:37:31 PM Hi, Does anyone know why my speed is so small, the card is GTX Titan Z. At the beginning of the process, the speed was the same ? Avoid to have too large hashtable in RAM even if you have enough RAM on your system, it is preferable to use -wsplit and merge workfile offline.

18	Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)	on: August 26, 2020, 02:32:59 PM
Could you try to run cuda-memcheck with your input address file ? Code: "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\bin\cuda-memcheck.exe" VanitySearch119.exe -gpu -r 1000000 -t 0 -g 320,256 -o found.txt -i 50.txt -stop

Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder)

on: August 26, 2020, 08:38:53 AM

Quote from: Atariko on August 26, 2020, 07:35:44 AM

The Cuda version is the most recent and the graphics card drivers are the same. The bug is present on versions VanitySearch1.18 and VanitySearch1.19. What to do help. Videocard 2070super. Sorry for google translate

Hello,

Could you try to run cuda-memcheck.exe. I didn't manage to reproduce this issue. It may end with "Error: process didn't terminate successfully" but this does not prevent the program to run, this error happens in the exit function...

Code:

C:\C++\VanitySearch>"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.0\bin\cuda-memcheck.exe" --tool memcheck x64\Release\VanitySearch.exe -t 0 -gpu -stop 1Tst
========= CUDA-MEMCHECK
VanitySearch v1.19
Difficulty: 4553521
Search: 1Tst [Compressed]
Start Wed Aug 26 10:26:21 2020
Base Key: 83F4E602C7131AFCED71A0BD26861B5EED0402F945D3BE944D7E4148FCCA31CB
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1050 Ti (6x128 cores) Grid(48x128)
[0.00 Mkey/s][GPU 0.00 Mkey/s][Total 2^-inf][Prob 0.0%][50% in infy][Found 0]
PubAddress: 1TstZdrmCC2HqcacyiteMUxkHTFsoLGxq
Priv (WIF): p2pkh:L3n1tjjp5VBMncFo3PUWBV8fgYPov7JDeQe5SXNXWqrfH17E1ksu
Priv (HEX): 0xC3A4B99A401854FCDF9E276F831E807DDB92031B47843371E503FD1447F0784D
========= Error: process didn't terminate successfully
========= No CUDA-MEMCHECK results found

20	Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver	on: August 11, 2020, 03:01:16 PM
Quote from: Marynarz on August 11, 2020, 09:01:43 AM Ah...this google translator over 6 million dead kangaroo appeared while solving the problem with DP13, I solved the problem using the -t 4 processor if it matters. PS. I didn't modify the code. OK could give me your input file and how you launched the program ? Lots of dead kangaroos usually means that you search for a key which is out of the specified range.

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 »