VanitySearch (Yet another address prefix finder)

[spider703]

hi all!
i used this version https://github.com/allinbit/VanitySearch/releases/tag/v1.1 and in my in.txt i put 1000 btc address
range from 71 pazle to 160
maybe sometime on my side been high day when i found one from list btc

[BlackAKAAngel]

when sommebody want the vanitysearch with i key range i can send per email i dont want to make oficial on github its work great and great ratio speed

Trusting random Newbies with private key generation is how you risk your funds.

 


now i see how many here are hackers im so sorry but how many stupid you can be  und du loyce bist du wierklich sehr dumm todoy make it oficiel on github that code i just add the range its rewrite code from the https://github.com/JeanLucPons/VanitySearch  i just add the key range

[BlackAKAAngel]

here the   https://github.com/deniboy28/VanitySearch_keyrange.git   with a keyrange start and end

[WanderingPhilospher]

here the   https://github.com/deniboy28/VanitySearch_keyrange.git   with a keyrange start and end

This is not a good one to use for the puzzles (not sure if that is what you are trying to use it for). This is a good one to use for actual vanity addresses, because it will find keys out of the range you are searching in (endo and symm/negation); so while you can use it for the puzzles (technically) it will be much slower than FP's VS-Bitcrack that Ice mentioned above; because it is checking more than one key at a time, so speed seems faster, but it's checking keys in other ranges. So if you just use compression, the speed shown, should be divided by 6, to show what speed you are actually getting, in the range you are searching in.

[BlackAKAAngel]

here the   https://github.com/deniboy28/VanitySearch_keyrange.git   with a keyrange start and end

This is not a good one to use for the puzzles (not sure if that is what you are trying to use it for). This is a good one to use for actual vanity addresses, because it will find keys out of the range you are searching in (endo and symm/negation); so while you can use it for the puzzles (technically) it will be much slower than FP's VS-Bitcrack that Ice mentioned above; because it is checking more than one key at a time, so speed seems faster, but it's checking keys in other ranges. So if you just use compression, the speed shown, should be divided by 6, to show what speed you are actually getting, in the range you are searching in.

dit you check the code?, or the change what are made it on the code i think its generate pure keys just from the given key range

[ethanhunt2023]

when sommebody want the vanitysearch with i key range i can send per email i dont want to make oficial on github its work great and great ratio speed

When there is already so many versions on github for such features (For example. https://github.com/FixedPaul/VanitySearch-Bitcrack) then why would someone go through an email attachment.

I wanted to know if “FixedPaul/VanitySearch-Bitcrack” needs these settings for Linux:

Edit the makefile and set up the appropriate CUDA SDK and compiler paths for nvcc.
Or pass them as variables to make commands.

Install libgmp:

sudo apt install -y libgmp-dev

CUDA = /usr/local/cuda-11.0
CXXCUDA = /usr/bin/g++

make gpu=1 CCAP=2.0 all

[WhyFhy]

I've stumbled across what appears to be character clustering in P2SH Base58 addresses that I can't find documented anywhere.
I'm calling them "compression basins."
Ten specific characters (N, R, S, T, U, Y, b, e, g, m) exhibit higher co-occurrence rates than the other 48 Base58 characters when searching P2SH prefixes with vanitysearch.
Using -c 3*turn*me*beg* on a 4090,
I hit 3FtURnMeBegsZLGKQrxggR9BoZxmGNKMyR in 10-20 minutes, that's 12 basin characters forming 4 readable words.
The natural clustering (including the unintended 's' in "begs" and "my") suggests this maybe isn't just luck.

Theory:
This appears to be a probabilistic advantage through Hash160 & Base58 encoding properties.
Substring searches using these basin characters are noticeably more likely to converge.
Challenge:
Beat 12 characters / 4 words (intentional or not). First person posts proof here gets $5 BTC.

Case insensitive accepted
Wildcards allowed
Must use basin character subset N, R, S, T, U, Y, b, e, g, m

Has anyone encountered research on non-uniform character distribution in Base58 post-Hash160?

*Checking into it deeper, I do believe these may be resulting clusters from searching the 31h1 to 3R2c range?

**Clarification by beat I mean baseline 12 basin characters AND 4 readable words, with at least one margin exceeded 5 words/12 chars or 4 words/13 chars

[WanderingPhilospher]

I've stumbled across what appears to be character clustering in P2SH Base58 addresses that I can't find documented anywhere.
I'm calling them "compression basins."
Ten specific characters (N, R, S, T, U, Y, b, e, g, m) exhibit higher co-occurrence rates than the other 48 Base58 characters when searching P2SH prefixes with vanitysearch.
Using -c 3*turn*me*beg* on a 4090,
I hit 3FtURnMeBegsZLGKQrxggR9BoZxmGNKMyR in 10-20 minutes, that's 12 basin characters forming 4 readable words.
The natural clustering (including the unintended 's' in "begs" and "my") suggests this maybe isn't just luck.

Theory:
This appears to be a probabilistic advantage through Hash160 & Base58 encoding properties.
Substring searches using these basin characters are noticeably more likely to converge.
Challenge:
Beat 12 characters / 4 words (intentional or not). First person posts proof here gets $5 BTC.

Case insensitive accepted
Wildcards allowed
Must use basin character subset N, R, S, T, U, Y, b, e, g, m

Has anyone encountered research on non-uniform character distribution in Base58 post-Hash160?

*Checking into it deeper, I do believe these may be resulting clusters from searching the 31h1 to 3R2c range?

Would this count?

3BeMeByMyW2muK4VeQLUSV8dxVaypnRNi4

You said 12 characters / 4 words; / could be either/or. The above is at least 5 words, that's why I ask.

[WhyFhy]

I've stumbled across what appears to be character clustering in P2SH Base58 addresses that I can't find documented anywhere.
I'm calling them "compression basins."
Ten specific characters (N, R, S, T, U, Y, b, e, g, m) exhibit higher co-occurrence rates than the other 48 Base58 characters when searching P2SH prefixes with vanitysearch.
Using -c 3*turn*me*beg* on a 4090,
I hit 3FtURnMeBegsZLGKQrxggR9BoZxmGNKMyR in 10-20 minutes, that's 12 basin characters forming 4 readable words.
The natural clustering (including the unintended 's' in "begs" and "my") suggests this maybe isn't just luck.

Theory:
This appears to be a probabilistic advantage through Hash160 & Base58 encoding properties.
Substring searches using these basin characters are noticeably more likely to converge.
Challenge:
Beat 12 characters / 4 words (intentional or not). First person posts proof here gets $5 BTC.

Case insensitive accepted
Wildcards allowed
Must use basin character subset N, R, S, T, U, Y, b, e, g, m

Has anyone encountered research on non-uniform character distribution in Base58 post-Hash160?

*Checking into it deeper, I do believe these may be resulting clusters from searching the 31h1 to 3R2c range?

Would this count?

3BeMeByMyW2muK4VeQLUSV8dxVaypnRNi4

You said 12 characters / 4 words; / could be either/or. The above is at least 5 words, that's why I ask.

Clarification by beat I mean baseline 12 basin characters AND 4 readable words, with at least one margin exceeded 5 words/12 chars or 4 words/13 chars
But this entry is close and lightly supports the idea.

[WanderingPhilospher]

Clarification by beat I mean baseline 12 basin characters AND 4 readable words, with at least one margin exceeded 5 words/12 chars or 4 words/13 chars
But this entry is close and lightly supports the idea.

So then this would count?

3NeQbe8hLFNwYxbetbeTwC5beSmeTFji5G

[WhyFhy]

Clarification by beat I mean baseline 12 basin characters AND 4 readable words, with at least one margin exceeded 5 words/12 chars or 4 words/13 chars
But this entry is close and lightly supports the idea.

So then this would count?

3NeQbe8hLFNwYxbetbeTwC5beSmeTFji5G

this qualifies, it appears it took hardly any time either. Pm me a wallet I shoot you the $5

[pliego]

This whole theory about character clustering in Base58 is actually pretty wild. I’ve always felt like certain patterns in P2SH prefixes hit way faster than they should, and seeing it laid out as 'compression basins' explains a lot of those weird streaks I've seen on my own logs. I actually spent a few hours messing with the settings on my rig to see if I could force a longer string of those specific characters, and it’s definitely not just random luck. It’s one of those deep-dive technical details that makes you realize how much we still don't fully document about address generation. Definitely more interesting than just watching hashes fly by

[Morexl]

how to use this option "-rp privkey partialkeyfile: Reconstruct final private key(s) from partial key(s) info".

if the find too many keys with the same prefix.

[kTimesG]

how to use this option "-rp privkey partialkeyfile: Reconstruct final private key(s) from partial key(s) info".

if the find too many keys with the same prefix.

Have you bothered to read the README? It's literally just two scrolls down from where your above quote is mentioned how to "Generate a vanity address for a third party using split-key" which shows that "-rp" is used by Alice to reconstruct a final private key from the previously generated split key info and Bob's found key. Who would have thought!

[Garys27]

I've stumbled across what appears to be character clustering in P2SH Base58 addresses that I can't find documented anywhere.
I'm calling them "compression basins."
Ten specific characters (N, R, S, T, U, Y, b, e, g, m) exhibit higher co-occurrence rates than the other 48 Base58 characters when searching P2SH prefixes with vanitysearch.
Using -c 3*turn*me*beg* on a 4090,
I hit 3FtURnMeBegsZLGKQrxggR9BoZxmGNKMyR in 10-20 minutes, that's 12 basin characters forming 4 readable words.
The natural clustering (including the unintended 's' in "begs" and "my") suggests this maybe isn't just luck.

Theory:
This appears to be a probabilistic advantage through Hash160 & Base58 encoding properties.
Substring searches using these basin characters are noticeably more likely to converge.
Challenge:
Beat 12 characters / 4 words (intentional or not). First person posts proof here gets $5 BTC.

Case insensitive accepted
Wildcards allowed
Must use basin character subset N, R, S, T, U, Y, b, e, g, m

Has anyone encountered research on non-uniform character distribution in Base58 post-Hash160?

*Checking into it deeper, I do believe these may be resulting clusters from searching the 31h1 to 3R2c range?

**Clarification by beat I mean baseline 12 basin characters AND 4 readable words, with at least one margin exceeded 5 words/12 chars or 4 words/13 chars

when using wildcards I get this error, is this going to effect search or is it normal 3*Be*MY*

GPUEngine: Wrong totalPrefix 0!=1249031367!
GPUEngine: Wrong totalPrefix 0!=1249031367!
GPUEngine: Wrong totalPrefix 0!=1249031367!
GPUEngine: Wrong totalPrefix 0!=1249031367!