Bitcoin Forum
May 22, 2022, 08:52:04 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  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 »
1  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.
2  Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder) on: October 11, 2020, 05:51:12 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.

3  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.
4  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.
5  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);    \
  }
6  Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder) on: September 09, 2020, 02:00: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]
7  Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder) on: September 08, 2020, 04:12:00 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 ?
8  Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder) on: September 08, 2020, 10:33:44 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.
9  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.
10  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: September 04, 2020, 05:56:28 AM
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
11  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: September 03, 2020, 01:51:11 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.
12  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
13  Bitcoin / Development & Technical Discussion / Re: VanitySearch (Yet another address prefix finder) on: August 26, 2020, 08:38:53 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
14  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: August 11, 2020, 03:01:16 PM
Ah...this google translator Tongue 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.
15  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: August 11, 2020, 08:54:13 AM
It happened when solving the problem with DP 13, I also wanted to add with over 6 million kangaroos dead.

The problem occurred in v2.1

What do you mean by "adding 6 million kangaroos dead" ?
Did you modify the code ?
16  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: August 11, 2020, 06:32:01 AM
Could someone explain to me why this happened?

This should not happen. Which release is producing wrong collisions and in which cases (merging work file, basic usage, ..) ?

Could someone tell me how to set the parameter -m ? And what does 'expected operations' number mean?
On the plot in github I see that there is chance like +- 99% when the number of group operations is 6*sqrt(n).
If for example program shows 'Expected operations: 2^44.10', when may I assume there is no result? 2^44.10? 2^45? Sooner, later?

The expected number of operation is the average number of group operations needed to solve the key (including the DP overhead). It correspond to ~50% probability.
If you use -m 3 and if the search is aborted, you are sure at ~99.7% that the key is not in the given range.
17  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: August 10, 2020, 10:37:17 AM
Hi,

I published a new release 2.2:
https://github.com/JeanLucPons/Kangaroo/releases/tag/2.2

Slight performance increase:
    ModInv performance increase (Thanks to Peter Dettman)
    GPU kernel performance increase

Thanks to gmaxwell for pointing me out this interesting PR of bitcoin core Smiley

18  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: August 05, 2020, 10:37:45 AM
I won't implement a rho method for secp256k1. It is not feasible to reach a solution using this method.

I haven't seen this paper discussed here: https://cr.yp.to/dlog/cuberoot-20120919.pdf

There are a number of good points in it but particularly the point of generating *better* distinguished points by preferentially keeping ones that have longer walk lengths is interesting.

Thanks for the reading. I didn't read it yet.
I suppose that when you speak of walk length, you mean the total number of jumps of the walk, not the total traveled distance.
The problem of storing length of walk is that on GPU access to global memory is very slow. I will see if I manage to improve things.
19  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: July 22, 2020, 02:15:13 PM
Jean_Luc,

Could be of interest to you:

https://github.com/bitcoin-core/secp256k1/pull/767


Thanks for the reading Wink
It seems they have built a very similar algorithm than my DRS62 modular inversion.
It is clearly faster than the Fermat/Euler method for secp256k1 prime.
Depending on platform, the DRS62 cost is around 150 ModSquare (with ModSquare optimized for secp256k1 prime).
20  Bitcoin / Development & Technical Discussion / Re: Pollard's kangaroo ECDLP solver on: July 10, 2020, 07:03:24 AM
Searching on range larger than 126 bits will decrease performance a lot.
If you want to modify the code, the modification are not very difficult.
You have to change the structure and the interface in the HashTable to accept larger distance and restore 256 bit distance in the GPU code.
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!