Topic: VanitySearch (Yet another address prefix finder) - page 3. (Read 31225 times)

Don't people usually use NiceHash to rent their GPUs? Okay, you have the possibility to rent ASIC and GPU, so, my priority is GPU in this case.

But ASICs aren't my priority. NiceHash also offers you to rent GPU hashrate, doesn't it? So, my question is, can I rent GPU hashrate from nicehash and dedicate that hashrate to VanitySearch? I know that's possible via Amazon or Google cloud servers and via other websites that rent GPU rigs but I don't know how possible is it to direct GPU hashrate to specific job on NiceHash.

Yes, I know that but as far as I know you are limited to rigs and can't rent more than what particular rig offers.

That's what I want to know.

Using "split key" can solve that problem: the server will never know your final private key, and you can even create the split key on an offline system.

I think you want to check for marketplace which let you rent GPU for any purpose, such as https://vast.ai/. Take note i DO NOT guarantee security of generated key using such marketplace.



As reminder, NiceHash let you buy or sell hashrate for various algorithm where some of them can be done practically with CPU or GPU. But since AFAIK NiceHash only let you choose the mining pool, the answer is still no.

No. VanitySearch involves not only the hashing algorithm you mentioned (SHA-256) but also additional operations such as Base58 encoding or RIPEMD-160, which is used to convert the hashed data into a human-readable Bitcoin address format. While ASICs are highly optimized for specific tasks, including hashing, they may not be as well-suited for the additional operations involved in VanitySearch.

ASICs are designed for specific tasks and are commonly used for cryptocurrency mining, such as Bitcoin mining. They are optimized for high-speed computation of specific algorithms and are not general-purpose computing devices like CPUs or GPUs.

Talk to WhyFhy, he created (and ended) 1SPLiTKEY.com The easy, secure and mostly free vanity wallet service closed/down.

It's possible, but a very expensive way to create just a Bitcoin address.

I've seen other pay-by-the-hour hosts that offer servers with GPU. I think it's more likely to be used to crack lost passwords than find a rare vanity address though.

I don't think ASIC miners can be used to find vanity addresses. They're build for only one specific task, and it would be too expensive to build a dedicated ASIC to find vanity addresses.

See Rare address hall of fame.

Does anybody have or had a GPU mining rig? And I wonder if any of you with lots of hashing power had tried to generate a Vanity bitcoin address via VanitySearch? I'm talking about those who have at least tens of GPUs or in the best case, hundreds of them. I also wonder if any of you have tried to generate a Vanity address by using powerful AWS servers? Is it possible to direct hashrates rented on Nicehash to generate a vanity Bitcoin address? I know my sentences are full of questions but I'm really curious. If you have tried none of them above, at least what's the longest Vanity address that you have generated?

Best you could do is to contact OP from github, there might be contact methods, or he might be active there.
Else you just need to change the curve parameters, hashing functions and address encoding if they also differ, no need to know a lot about coding.

And if all of that failed, go to service board and post a topic. This is a link to service board.
https://bitcointalk.org/index.php?board=52.0

Hello, I am looking for help to add suport of the SECP224R1, but C++ and CUDA isn't really in my knowledge and expertise.
I have tried for days but the most critical logics just too hard for me to understand.

Does anyone interested in helping to add the support of SECP224R1? Payment is possible to express the gratitude.

Much Appreciated!!!

Hello, I'm new here and have a question about
bojlahg/VanitySearchPublicKey.
if I search there I find only keys with use -t.
-gpu is displayed but does not find any keys
for example:

VanitySearchPK.exe -t 0 -gpu -sk 2000000000000000000000000000000000 -p 633cbe Find no keys but 5000mk/s            (0keys) 1 minute

VanitySearchPK.exe -t 1 -gpu -sk 2000000000000000000000000000000000 -p 633cbe find keys with 5600mk/s very bad (25keys) 1 minute

VanitySearchPK.exe -t 32 -sk 200000000000000000000000000000000 -p 633cbe find keys good but 1000mk/s                (200keys)1 minute

I believe that the program recognizes the GPU
but the gpu performance does nothing

can any help for this

Are you wanting to print every result from say base key 0000000000000000000000000000000000000000000000000000000000000001, to key 00000000000000000000000000000000000000000000000000000000000fffff? Or just search for a specific key within that range?
You can print every result to file using 1*, but it will drastically reduce the speed of the program. I know VanBitCracken can do what you want, but again, if you want to output every result, it will be slow.

You mean provide an argument to search on a specific range?
If so, VanitySearch can't do that but there are forks and other tools that has the feature that you're looking for.

To name two:

• Bitcrack: https://bitcointalksearch.org/topic/bitcrack-a-tool-for-brute-forcing-private-keys-4453897 | use --keyspace to specify the range.
• VanBitCracken: https://bitcointalksearch.org/topic/vanbitcracken-a-program-to-use-for-32-btc-challenge-supports-rtx-30xx-cards-5328080 | has more feature but not open-source.

Don't use address prefix because it will slow down your search, when you give a prefix of an address the program will generate private keys, derives their public keys, hashes the public key twice and then performs another double hash on the rmd160 hash to derive the address and then checks to see if the prefix matches with your desired prefix.
You should find a tool that searches for rmd160 prefix. I haven't seen any tool searching for such prefixes, they either search for the whole hash or just slow you down by searching for prefix match on addresses. Why are you using CPU? it's a waste of time, you should use GPU only.

If I want to run the vanitysearch program to search for private keys from 1 to a specific number and output the results, how can I do that?
Base Key: 0000000000000000000000000000000000000000000000000000000000000001

Difficulty: 1208925819614629174706176
Search: 11111111111 [Compressed]
Start Sun Apr  9 10:13:28 2023
Base Key: 0000000000000000000000000000000000000000000000000000000000000001
Number of CPU thread: 12

[/quote]

This is kind of what I was thinking, is that with some non-standard switches or inputs or something, it could be "convinced" to output something, maybe even just in hex or some other output that can be converted into something that work with nostr?  Pardon my ignorance on it, but is it as simple as just going to npub1 instead of bc1q or similar?  I'm learning a lot, but I'm not well versed on address types and how they interact with the systems.

None of those are Nostr vanity generators. AFAIK, nobody has made one yet, which is not unreasonable when you consider that Nostr is a very recent invention.

[for the record, VanitySearch cannot find Taproot addresses, but it should be as simple as checking for an input prefix that is either bc1q or bc1p to allow that. I was able to use VanitySearch to generate arbitrary prefixes not starting with 1, 3, etc, in my experimental builds.]

You could go to project development : https://bitcointalk.org/index.php?board=12.0 there are some windows GPU versions, some are not open source, so do your research before using.

I did try to look through this to see if it has been answered, but attempting to find a GPU accelerated nostr vanity address generator, and this is as close as I've found so far.  Obviously not the same thing but, just trying to figure out if there is a branch of this that could do that, or something else made to do so?  Using CPU only is brutal.

This is what I ended up settling with:


The ugly AND operators are the direct result of Intel not having any kind of "AND bytes/words/dwords/quadwords inside XMM register" instruction. Indeed, there are no packed bitwise instructions operating on single SIMD registers at all - the kinds of instructions are there are mostly designed with video decoding algorithms in mind.

There's no real performance improvement from using this over the old code.

Yes, I know there is MOVMSKPS, but that is for floats, so it hardly suits byte inputs. Not only would I have to restrict inputs to 4 chars at a time, I would also have to pad them with zeroes which will negatively affect performance.

Hence this code has been pushed right now to the repo, but nothing calls it - this is despite coverage tests saying it got hit 16 million times (over the span of a few minutes) whereas the char_is_match other function would be (and still is) called several hundreds of millions of times.

So the only real performance improvement I pushed in this latest commit is to disable the UTF8 character matching and treat everything as ASCII - that did increase Mkey performance on 8x "Intel(R) Xeon(R) CPU E31240 @ 3.30GHz" by about 0.1MKey/s (up from 0.9 MKey/s average - VanitySearch reports large speeds for the first few seconds but then it comes down as the estimates become more accurate).

Meanwhile the non-regex mode (also in my fork) runs at 2.20MKey/s once the dust is settled - roughly the same as original VanitySearch.

hmm its actually in std::experimental so i guess that means its not officially in the standard yet. it was originally a third-party library that i had used in an old version of a program of mine, then a few years ago it got promoted to get absorbed into the c++ standard library. not sure if its on track to become official with c++23 or not. anyway i just know i really liked how relatively simple it made writing vectorized code 😎

This is very useful, thanks!

Is this part of the base standard, or a C++11/14/17/20 extension?

Meanwhile I have already made an optimized matcher for consecutive character matches:

edited for garbage code formatting pasted from my phone


This actually only uses SSE2. I'm not sure why JLP compiled with SSSE3, is he using some of those newer instructions in his SECP256k1 class?

Anyway, I haven't benchmarked this yet, but the way this is supposed to work, is that the regular expression is already represented as a linked list like this:


^1tryme.*

start --> char --> char --> char --> char --> char --> char --> quant
                                                                                              v
                                                                                             any

so you can actually go down in some of these nodes if necessary.

Now instead of comparing each of these char nodes as is presently done, which is inefficient, we can take advantage of the fact that XMM registers can hold up to 16 char values. So we can combine sets of 2-16 char nodes into a single char16 node, and pad it (as well as the input string!) with NULs if necessary :

start --> char16 --> quant
                                 v
                               any

This has roughly the same overhead as a single "char" old-school comparison. Considering that the "char" node match function is called hundreds of millions of times in the span of a few seconds, owing to the fact that most people will usually search for just a certain pattern of strings, this will translate to 6-8x less of these calls being made depending on the regex string.