VanitySearch (Yet another address prefix finder) - page 24.

MrFreeDragon

sr. member

Activity: 443

Merit: 350

Quote from: xhomerx10 on October 11, 2020, 01:24:50 PM

-snip-
I've noticed that is you duplicate the seed value, you will generate the same addresses each time the program is run. Would the same seed value result in the same addresses on another computer?
-snip-

As far as I know this soft works, it starts with the base key (as the starting private key) and increment it by 1 calculating the bitcoin address for every key (together with additional keys due to symmetry and endomorphism). For better security the random start key is used.
However if you use the same base key, you should receive the same final results (probably not in the same order as the work is performed not by one core, but by multi CPU/GPU cores)

Jean_Luc

sr. member

Activity: 462

Merit: 701

Yes, if you specify manually the same seed, the calculation will be the same.

xhomerx10

legendary

Activity: 3808

Merit: 7912

Quote from: Jean_Luc on October 11, 2020, 12:51:12 PM

Quote from: shlomogold on October 11, 2020, 12: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.

I've noticed that is you duplicate the seed value, you will generate the same addresses each time the program is run. Would the same seed value result in the same addresses on another computer?

Anyone care to try?

Code:

vanitysearch -t 2 -gpu -gpuId 0 -c -s 0000000000000000000000000000000000000000000000000000000000000001 -u -o seetest.txt 1vanity

output

Code:

PubAddress: 1vaNitynLfQsJRMYQKMkbdSg8rLkSjhwv
Priv (WIF): p2pkh:5KbzFV78qNVj1PLRHXYBhG7icZTkifPZEKLchTGDWy5b7mv69qq
Priv (HEX): 0xEB775B6D709EF23F77B4D4A83A9B2EFDDEC07EF17B198320AB0BE94D128FCB9F
PubAddress: 1vaNity5aynUujBya8CMdrvZgx61sK5bZ
Priv (WIF): p2pkh:5Jn7TQNRSgjKaHfTbUEB3GuPxPaEeYAXDbKXhi8ptZLHZiXDhcJ
Priv (HEX): 0x7EC229EA229D8EE34BBC733ADC99ECA1DDCCC543D9C5714DC9626D13CBCD311D
PubAddress: 1vaniTySykD7CsMLDe79zEgRtzmsLDjkx
Priv (WIF): p2pkh:5Jh8WUtmjHQZkDPix71P78RPJu7KaCQt3sUBJVxtYknog3ZVTyZ
Priv (HEX): 0x73725230D841E056B39063C84D3D721BA08616210B1614B6E0F61FA20BA5D660
PubAddress: 1vaNiTyNULTxWy1W9y5u65YypG4mnjfXk
Priv (WIF): p2pkh:5Jn7TQNRSgjKaHfTbUEB3GuPxPaEeWxyHSCYURBzPZjaoT8Loxy
Priv (HEX): 0x7EC229EA229D8EE34BBC733ADC99ECA1DDCCC543D00F714DC9626D13CBC665D5
PubAddress: 1VAniTyzcxeBzAviTpjdoVwu6Pdda4eus
Priv (WIF): p2pkh:5JoCtBynZf5t5YgoPWHd69BYs4LQtUE61eA4cc2YQXTBgNcnWCh
Priv (HEX): 0x813DD615DD62711CB4438CC52366135CDCE217A2EE6A2EEDF66FF17904702C64

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: shlomogold on October 11, 2020, 12: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.

shlomogold

jr. member

Activity: 75

Merit: 2

Quote from: Jean_Luc on October 09, 2020, 10:20:21 AM

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.

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?

Jean_Luc

sr. member

Activity: 462

Merit: 701

There is no way with VanitySearch to specify a priv key range.

bigvito19

full member

Activity: 706

Merit: 111

How to go about generating keys from specific ranges?

Jean_Luc

sr. member

Activity: 462

Merit: 701

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.

POD5

member

Activity: 251

Merit: 10

Keep smiling if you're loosing!

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?

inklbot

newbie

Activity: 1

Merit: 0

Can I use it on ubuntu 20.04?

If so, what version of cuda should i have?

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

@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:

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}]>>

Currently I'm busy with another project so I might make a PR for this if I find the time to.

nc50lc

legendary

Activity: 2646

Merit: 6681

Self-proclaimed Genius

Quote from: NotATether on September 18, 2020, 04:15:19 PM

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)

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').
If you really want the prefix whole, you can add 'A' before 'Tether' but that will increase the difficulty a lot.

Quote from: NotATether on September 18, 2020, 04:15:19 PM

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.

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

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:

Code:

Ignoring prefix "3Tether" (Unreachable, 31h1 to 3R2c only)

xhomerx10

legendary

Activity: 3808

Merit: 7912

Quote from: Marynarz on September 18, 2020, 03:22:04 AM

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

Marynarz

jr. member

Activity: 40

Merit: 2

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.

bigvito19

full member

Activity: 706

Merit: 111

@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

Jean_Luc

sr. member

Activity: 462

Merit: 701

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);    \
  }

bitcoinunide

newbie

Activity: 17

Merit: 38

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!

Atariko

newbie

Activity: 12

Merit: 0

Quote from: Jean_Luc on September 09, 2020, 09:00:25 AM

Quote from: Atariko on September 08, 2020, 01:50:19 PM

Quote from: Jean_Luc on September 08, 2020, 11:12:00 AM

Quote from: Atariko on September 08, 2020, 10:51:25 AM

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.

Jean_Luc

sr. member

Activity: 462

Merit: 701

Quote from: Atariko on September 08, 2020, 01:50:19 PM

Quote from: Jean_Luc on September 08, 2020, 11:12:00 AM

Quote from: Atariko on September 08, 2020, 10:51:25 AM

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]

Topic: VanitySearch (Yet another address prefix finder) - page 24. (Read 33086 times)