VanitySearch (Yet another address prefix finder)

[nc50lc]

I've never had an issues receiving sending spending eating any BTC from Electrum wallet using any Legacy address generated by vanitysearch, in which I had the private keys.

Thank you for the confirmation. I'd like to see though if there are users which generated nested and native SegWit addresses with VanitySearch. Meaning that I'd like to know if they were able to spend funds from these addresses (the ones starting with 3 and bc1).

That issue was brought by both old versions of Electrum and whatever Vanity address generator they've used must be because of lack of research for SegWit or lack of public info or both.

For Electrum: the older version like v3.3.6 (When SegWit was kinda new), allows the user to create an imported wallet
using an 'uncompressed WIF private key' as SegWit P2WPKH (starts with bc1) or P2WPKH-P2SH (starts with 3).
Reference: https://www.reddit.com/r/Electrum/comments/bec22p/potential_loss_of_funds_if_import_uncompressed/
That's fixed (removed) in the later versions.

For the vanity address generator: There was an option to create SegWit addresses using uncompressed public key flag as stated by others.

To answer your question, transactions created using those SegWit addresses are "non-standard" which means it will be rejected by most nodes when you try to broadcast it.
The only way to spend the funds from them is to send the 'Signed RAW Transaction' directly to a solo miner/pool and ask them to include it in a block.
Here's an example of how "hard" it is to spend them: https://bitcointalk.org/index.php?topic=5192454.0

[1715168059]

1715168059

[GazetaBitcoin]

To answer your question, transactions created using those SegWit addresses are "non-standard" which means it will be rejected by most nodes when you try to broadcast it.
The only way to spend the funds from them is to send the 'Signed RAW Transaction' directly to a solo miner/pool and ask them to include it in a block.
Here's an example of how "hard" it is to spend them: https://bitcointalk.org/index.php?topic=5192454.0

Thank you for the answer. I have one more question though: when you mention the transactions rejected by most of the nodes, you mean the transactions which were created on those previous versions of VanityGen (VanitySearch) / Electrum, right? Meaning that now the problem is not present anymore. So now if I create a nested / native SegWit address with VanitySearch, then if I import it in Electrum and if I sent funds to it, I'll be able afterwards to spend the respective funds. Did I understand correctly?

About the topic you mentioned, I remember I read it a while ago, but I did not pay too much attention to it though.

[nc50lc]

Yes, but not all types of addresses created using vanity address generators.
It's exclusive to SegWit addresses generated from an "Uncompressed Public key".

And yes, now, you cannot import 'uncompressed WIF prv key' as SegWit to Electrum.

[GoVanza]

Do you plan to work AMD cards?

[GoVanza]

That's how it goes. Apparently AMD will stay aside

[shlomogold]

Rather than searching for addresses you should search for pubkey with funds (there are a lot) with a kangaroo or rho program.
It will be much faster, ~2.4e19 years with rho or kangaroo against ~9e28 years with address finder (on 256xTelsa V100)
Do not use my kangaroo program which is limited to 125 bit range key search !

Edit:
For instance this pubkey:
02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c (1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx)
hold 69370BTC

how did you know its pubkey?

[bigvito19]

Rather than searching for addresses you should search for pubkey with funds (there are a lot) with a kangaroo or rho program.
It will be much faster, ~2.4e19 years with rho or kangaroo against ~9e28 years with address finder (on 256xTelsa V100)
Do not use my kangaroo program which is limited to 125 bit range key search !

Edit:
For instance this pubkey:
02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c (1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx)
hold 69370BTC

how did you know its pubkey?

It has a sent transaction when there is a sent transaction you can see the pubkey.

[shlomogold]

@student
If you are looking for full addresses, do not enter in the list a part of them (for instance the 15 first char)
It will be faster to enter full addresses.
That's true that there is 2^96 priv key for an address and if you perform 2^96 key you will find a collision but that would also imply that you search for the whole address range, on the blockchain there is no 2^160 address with fund and it is not possible to have a file of 2^160 address.
So if you want to find a collision between 2 priv key that give the same address, consider using BTCCollider which would require "only" 2^80 operations to reach the collision.
https://github.com/JeanLucPons/BTCCollider

ok. Thank you. I tried it with 1000 full adresses, but the gpu shows me that it is going up to 80% and down to 0%, so the speed decrease is still there, but a bit flatter.
So far I have a file of ~ 10M adresses. It is just to increase the possibility that I will find a collusion. The file has ~350 MB. And that is enough to make it possible to find something in reasonable time I think. At least if you can increase the speed and I will get more rigs to work
Can you make the speed of the software the same, so it doesnt matter if you are looking for 1 or 10M adresses? Or is that impossible?

How did you get 10M addresses? I assume there might be a script that extracts addresses from the blockchain somehow, is it?

[ianek]

Hi, Jean Luc

Is it possible to add a couple of extra features to VanitySearch ?:
- the ability to reuse a Base Key that has already been used, the '-s' parameter is unsuitable (it generates a new key)
- saving the parameters of the path traveled and resuming the program (power failure, the need to turn off the computer, etc.)

With the given parameters [Prob 100.0%] [99% in 00:00:00], the program continues to use gpu, but after reaching 100% and stopping the timer, no keys were found in 4 hours, is this an error or VanitySearch continues to work?

Thank

[Roby4kill.]

Can someone help me with a small issue..

I have an old i3 2012 CPU, that is currently only generating around 650 addresses /sec with 4 threads.


https://i.imgur.com/flQUc6x.png


The thing is, more than a week ago it used to do around 21000 addresses /sec with the same 4 threads.

Why am I only able to generate 600 addresses /sec now? It used to do much more...

This is the current config I've set and not changed since:

start %USERPROFILE%\Desktop\VanitySearch.exe -c -o output.txt 1*


Why is it only doing 600 adresses /sec instead of 21000 per /sec as it used?

I don't get it.

[nc50lc]

-snip-
start %USERPROFILE%\Desktop\VanitySearch.exe -c -o output.txt 1*

Why is it only doing 600 adresses /sec instead of 21000 per /sec as it used?

If it's not a hardware issue, my guess is: Vanityseach might be struggling to write on that output file due to its current size.

Have you been using the same 'output.txt' file since the start?
If yes, try to use a new text file like "-o output2.txt" and see if it will speed-up.

[Roby4kill.]

-snip-
start %USERPROFILE%\Desktop\VanitySearch.exe -c -o output.txt 1*

Why is it only doing 600 adresses /sec instead of 21000 per /sec as it used?

If it's not a hardware issue, my guess is: Vanityseach might be struggling to write on that output file due to its current size.

Have you been using the same 'output.txt' file since the start?
If yes, try to use a new text file like "-o output2.txt" and see if it will speed-up.

Won't solve the issue.

Tried:
-other output file names .txt that are even empty / fresh files
-restarting the system
-change thread numbers (will do the same no matter what I do)
-set different priority on the process in task manager (normal/high/realtime - makes no difference)
-run as administrator and so on
-Changed file locations from desktop to other partitions / folders. Won't solve


Don't know what to do. The CPU is in good standing / temps


Won't solve it no matter what I do.

Also, might the "1*" be the problem? I don't necessarily want it to generate prefixed addresses.
I want it to generate any random addresses, no matter the prefix.
Is 1* the only way of doing that?

[nc50lc]

Won't solve the issue.

Don't know but your previous speed doesn't sound right for an old i3 CPU from 2012 (third-gen maybe) when searching for '1*'.
You'll likely get 1000-2000 per update of "Found" at best (based from my PC w/ i3-4130 procie).

Other than the additional -c which is unnecessary for a wildcard prefix, I can't find any issues with the command you're using.
If you previously used an older version with faster result, then downgrade to that.

The weird thing is, your processor can search for Million keys per second, while it can only "no-prefix-search" random address & key pair @ thousands per second.
Perhaps it's not meant for that use-case.

[Roby4kill.]

Won't solve the issue.

Don't know but your previous speed doesn't sound right for an old i3 CPU from 2012 (third-gen maybe) when searching for '1*'.
You'll likely get 1000-2000 per update of "Found" at best (based from my PC w/ i3-4130 procie).

Other than the additional -c which is unnecessary for a wildcard prefix, I can't find any issues with the command you're using.
If you previously used an older version with faster result, then downgrade to that.

The weird thing is, your processor can search for Million keys per second, while it can only "no-prefix-search" random address & key pair @ thousands per second.
Perhaps it's not meant for that use-case.

I swear to god it used to find 20.000 addresses per second.
As soon as I started the software, in the first second it showed [Found 21529], as example. The next second was [Found 37176], as example. That's nearly 20k per second.

I checked the text file and it indeed contained almost 40k PUBLIC addresses only. NOT including the PRIV KEYs and other Lines. I use Notepad++ and can count.
Yes, it did 20k per second.

The weird thing is that it does not do that anymore, and it only does around 600 Addresses per second with THE SAME settings.

This is why I'm asking, I haven't done any OS updates since then. One day it just stopped finding 20k per second, and it did only around 600.


I used VanitySearch 1.18 but I also tried other versions. Same result - around 600 addresses per second, not 20k as it used to do a while back.
It's weird.


EDIT:

I have an AMD GPU (RX480 @ 4GB). From what I know, VanitySearch doesn't support OpenCL or any way of using AMD GPUs.

What's the best way of maximizing the generation speed ? Is there any good config out there?

[nc50lc]

Okay, I've ran some tests and noticed that:
My antivirus is acting up whenever I'm using vanitysearch, it's not detecting anything but consuming a lot of resources.
Much higher than what Vanitysearch is using; so I've included it to my AV's "exceptions list".
And it worked!

What's the best way of maximizing the generation speed ? Is there any good config out there?

Somehow, vanitysearch isn't using all of the cores or even processing power when using that command, there should be something wrong.

Whatever the reason is, I've tried to use 1 thread and it resulted with a slightly slower rate (just about -10%).
So, try to run 3-4 instances of Vanitysearch running with the same command but pointing to different output files.

Creating batch files is a good shortcut to do this, eg.:
instance1.bat

Code:

vanitysearch -t 1 -o output1.txt 1*

instance2.bat

Code:

vanitysearch -t 1 -o output2.txt 1*

instance3.bat

Code:

vanitysearch -t 1 -o output3.txt 1*

...And so forth

Each instance will be slower than a solo instance but overall number of generated addresses and keys could be higher.

[Roby4kill.]

Okay, I've ran some tests and noticed that:
My antivirus is acting up whenever I'm using vanitysearch, it's not detecting anything but consuming a lot of resources.
Much higher than what Vanitysearch is using; so I've included it to my AV's "exceptions list".
And it worked!

What's the best way of maximizing the generation speed ? Is there any good config out there?

Somehow, vanitysearch isn't using all of the cores or even processing power when using that command, there should be something wrong.

Whatever the reason is, I've tried to use 1 thread and it resulted with a slightly slower rate (just about -10%).
So, try to run 3-4 instances of Vanitysearch running with the same command but pointing to different output files.

Creating batch files is a good shortcut to do this, eg.:
instance1.bat

Code:

vanitysearch -t 1 -o output1.txt 1*

instance2.bat

Code:

vanitysearch -t 1 -o output2.txt 1*

instance3.bat

Code:

vanitysearch -t 1 -o output3.txt 1*

...And so forth

Each instance will be slower than a solo instance but overall number of generated addresses and keys could be higher.

Yeah, I already thought about that, to use different instances of Vanity

I don't run an antivirus though. I'm pretty sure there's an issue with cpu thread selections on some CPUs and that's what I'm encountering atm.

I also don't run an AV because I don't need one, I tried with Defender off aswell and same result. Nothing is using my processor except vanity.

[Atariko]

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.

[nc50lc]

I don't run an antivirus though. I'm pretty sure there's an issue with cpu thread selections on some CPUs and that's what I'm encountering atm.

Run it using a different command, like vanitysearch -o output.txt 1a.
If it consumes all of your CPU resource, then it's not "that issue".

I think the problem is the way you want to use vanitysearch, it's not meant for creating bulk random addresses IMO.
I'm pretty sure that there are other tools that can do that bulk address generation better (I don't have one however).

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?

You have the same issue as this guy: Issue #70
And one of v1.18's release note was "Updated to CUDAv11", maybe it has something to do with your drivers.

[Atariko]

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.

GPUEngine: Launch: an illegal memory access was encountered

PS C:\WINDOWS\system32> nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2020 NVIDIA Corporation
Built on Wed_Jul_22_19:09:35_Pacific_Daylight_Time_2020
Cuda compilation tools, release 11.0, V11.0.221
Build cuda_11.0_bu.relgpu_drvr445TC445_37.28845127_0
PS C:\WINDOWS\system32>

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

[Jean_Luc]

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