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?