Topic: VanitySearch (Yet another address prefix finder) - page 23. (Read 32072 times)
There is no way with VanitySearch to specify a priv key range.
How to go about generating keys from specific ranges?
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.
CryptGenRandom() for windows and /dev/urandom for linux.
Is there the possibility that one of the keys generated by VanitySearch coincide with the keys generated by a common BTC wallet, no matter if a newest or oldest, or even an upcoming key?
Can I use it on ubuntu 20.04?
If so, what version of cuda should i have?
If so, what version of cuda should i have?
@Jean_Luc, would it be possible to display at the end of the last line of the progress, the prefix that is being searched for? It helps when generating dozens of addresses to an output file and you want to know which ones have not been found yet.
This is a trivial addition to the project so I'm thinking about displaying the prefix at this position:
Currently I'm busy with another project so I might make a PR for this if I find the time to.
This is a trivial addition to the project so I'm thinking about displaying the prefix at this position:
Code:
VanitySearch v1.19
Search: 104 prefixes (Lookup size 426) [Compressed]
Start Fri Sep 18 22:14:01 2020
Base Key: xxxxxxxxxxxxxxxxxxxxxx
Number of CPU thread: 4
[9.81 Mkey/s][GPU 0.00 Mkey/s][Total 2^40.59][Prob 64.3%][70% in 07:53:29][Found 103] <<[Prefix {PREFIX}]>>
Search: 104 prefixes (Lookup size 426) [Compressed]
Start Fri Sep 18 22:14:01 2020
Base Key: xxxxxxxxxxxxxxxxxxxxxx
Number of CPU thread: 4
[9.81 Mkey/s][GPU 0.00 Mkey/s][Total 2^40.59][Prob 64.3%][70% in 07:53:29][Found 103] <<[Prefix {PREFIX}]>>
Currently I'm busy with another project so I might make a PR for this if I find the time to.
EDIT: Is searching by prefix 3 even possible? I tried to generate 3Tether, and got this error:
Like the error said, it is out of the available prefix for Nested SegWit address, you also cannot use lowercase char as the second character (after '1').Code:
Ignoring prefix "3Tether" (Unreachable, 31h1 to 3R2c only)
If you really want the prefix whole, you can add 'A' before 'Tether' but that will increase the difficulty a lot.
Is there a speed difference in searching for 1, 3, and bc1q? Particularly, does each key iteration for "1" address take longer than an iteration for a "3" or "bc1q" address?
This only based form a simple test by checking the difficulty when generating different address types with 2-character prefix:- bc1qas: Difficulty: 1024
- 3As: Difficulty: 1354
- 1As: Difficulty: 1354
- 1as: Difficulty: 78509
Based from the difficulty, it's quite slower than native SegWit and in par with legacy when you use an uppercase as the second character.
This thread is very long so I didn't bother to read all the posts, so my apologies if this question has been answered before.
Is there a speed difference in searching for 1, 3, and bc1q? Particularly, does each key iteration for "1" address take longer than an iteration for a "3" or "bc1q" address? I plan on generating a large number of "3" addresses but I only have 4 Xeons at my disposal.
EDIT: Is searching by prefix 3 even possible? I tried to generate 3Tether, and got this error:
Is there a speed difference in searching for 1, 3, and bc1q? Particularly, does each key iteration for "1" address take longer than an iteration for a "3" or "bc1q" address? I plan on generating a large number of "3" addresses but I only have 4 Xeons at my disposal.
EDIT: Is searching by prefix 3 even possible? I tried to generate 3Tether, and got this error:
Code:
Ignoring prefix "3Tether" (Unreachable, 31h1 to 3R2c only)
Does any of the users have an Nvidia Titan X Pascal 12 GB graphics card? I would like to know what the result is on Kangaroo or VanitySearch.
Based on benchmarking results I would guess it comes in around 700Mkeys/s
Does any of the users have an Nvidia Titan X Pascal 12 GB graphics card? I would like to know what the result is on Kangaroo or VanitySearch.
@Jean_Luc
So you couldn't add where we could search for collisions with a public key? or a prefix at least?
https://github.com/JeanLucPons/BTCCollider
So you couldn't add where we could search for collisions with a public key? or a prefix at least?
https://github.com/JeanLucPons/BTCCollider
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.
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); \
}
Hello Jean Luc & VanitySearch enthusiasts,
what is the specific calculation for key merging of Bech32 Address Format?
What is the difference by calculating the final private key of legacy & P2SH to Bech32?
I am working on a secure splitkey-only Vanity address service and i need to build a javascript keymergingtool for Bech32 (for using in inkognito browser offline).
I already tried to understand the main.cpp in line 248 'reconstructadd' function, to get the specific mathematical operation, but i dont understood it.
So how do i compute a bech32 address from partialkeys?
Thanks for your answers and especially Jean Luc for your awesome Software!
what is the specific calculation for key merging of Bech32 Address Format?
What is the difference by calculating the final private key of legacy & P2SH to Bech32?
I am working on a secure splitkey-only Vanity address service and i need to build a javascript keymergingtool for Bech32 (for using in inkognito browser offline).
I already tried to understand the main.cpp in line 248 'reconstructadd' function, to get the specific mathematical operation, but i dont understood it.
So how do i compute a bech32 address from partialkeys?
Thanks for your answers and especially Jean Luc for your awesome Software!
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]
I wonder why it works for you and not for me.
My configuration: windows 10 latest updates , graphics card MSI 2070 super and cuda last version. What could be the problem? Can someone else on the site run my build and check? Link above.
P.S. VanitySearch119.exe -r 100000 -t 0 -g 320,256 -o found.txt -i 50.txt This configuration works without problems.
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]
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
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 ?
Why don't VanitySearch1.18 and VanitySearch1.19 versions work for me, reports the error GPUEngine: Launch: an illegal memory access was encountered, and VanitySearch1.17 version works correctly? Help me to understand.
Why is there no answer? Jean Luc ask for an answer on this question. All data I have provided.
@Jean_Luc
What exactly is the base key and why we can't manually change it?
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.
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.
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.
@Jean_Luc
What exactly is the base key and why we can't manually change it?
Jump to: