Topic: segvan: Segwit vanity address & bulk address generator (Read 2596 times)

Old thread, but pulled this up as I've been trying to make a segwit vanity address and this seems to be the best option now. I know this is a fairly big gravedig but I'm currently using this on an eight-core cloud machine (with all egress blocked) to try to find a vanity address containing 'Diamond' - now trying to just make one with 'DCardz' at the start to save time.


(I've since gone from running it on 8 cores to 12 cores)

I've tested it with smaller addresses and it works well. I wonder where the original creator went, though. Are there any alternatives to segvan which are being maintained by members of the community who are still active or is this the main option? Anything faster floating about perhaps?

Leaving the previous for posterity but I've now realized that Jean_Luc maintains a vanity address generator that supports segwit. Github link is here. It doesn't appear in searches however, while this one appears quite high. Hopefully by posting on this people who are looking for a segwit vanity generator will see this post and be redirected

Nice work. I used the faster branch of Segvan to generate a few addresses in the last day and a half on my Ryzen CPU with 8 instances. The string I wanted was computationally difficult to come by. It probably would have taken forever on Vanitygen, if gmaxwell's post is anything to go by.

Hi "Michael",

Hope you are doing well.  If you still need access to AWS, please DM me and I can provide that.

Best regards,
Ben

Notice:  As a pseudonymous developer who can only pay in BTC, I am currently seeking a legitimate means of Amazon EC2 access.  The most immediate (but not only) motivation therefor is for work on a segvan client/server trustless tweak generator.  Trustworthy persons with their own EC2 accounts are invited to work with me.  This is for long-term legitimate development:  I am NOT trying to buy an account; offers of such will be treated as spam.

(Translation:  Plan A embraced BCH, and lacked EC2’s flexibility anyway.)

---

Quote from: mattcode on March 10, 2018, 09:29:02 AM

Quote from: nullius on February 13, 2018, 08:54:39 AM

I’ve also been seriously mulling ideas for an online service which finds “vanity tweaks” for a private key held by a user—essentially, convenient results from rented time on powerful CPUs in the “cloud” (much though I loathe that word).  I’m curious as to how popular such a service could be.  Anybody interested?

I'd be interested in a service like that. Please could you PM me if you ever get round to doing it? Thanks :)

Please see above.  I’m currently trying to do a 2⁴⁵ (9 characters of Bech32) search on a very slow laptop; I estimate that after both cores spin sipa’s keygrinder 24/7 for two months, I will then have about a 1% chance of having found a match.  Getting access to some fast cloud computing would give me both the impetus and the opportunity to develop a production-quality client/server implementation.

---

Quote from: mattcode on March 19, 2018, 04:46:50 PM

I just used segvan to find 3Jjjjj8466bZXCFJQGDk1reaAXwrri39Vz, 3AAaAAMy2auJ1c5wCRj7Qbzx8qshh9cVrx and 3FffFFLntXU14ePkYK3pyASx2Smaw5TfF1 :)

Unfortunately I had to build from master instead of the sipa_grind branch so I think I'm missing out on the huge performance improvements. Is the sipa_grind meant to be working right now?

I also noticed the 333333mR6i1xHnDQAy1xUwvbGXFqjGgzUU address in your signature and profile!

Apples to apples, rounding liberally, the same patterns with the same codepath give me about 7000 keys/sec generating keys one by one, and 35000 keys/sec with sipa’s keygrinder.  Thus, about a 5x speedup.  (For comparison, with OpenSSL on the same hardware, I maxed out at about 1400 keys/sec.  Core’s secp256k1 really blows OpenSSL away; it is something to be most thankful for when synching the blockchain.)

---

Quote from: Velkro on March 15, 2018, 09:28:20 PM

If you want this to become more popular like vanitygen original version, you need to make windows version of it.
Most users using Windows while generating their private keys. You need above average knowledge to compile it yourself and use linux.

Please see the discussion of Windows porting in a Segwit vanity address generator request thread which pushed me to make an initial release of segvan.

My current priorities are approximately:

0.0. Stable, feature-complete, well-tested implementation on FreeBSD and Linux.  This is much more popular than I’d expected when I whipped up v0.0.0 on an idle afternoon in December.  I want to do it right.

0.1. Packaging on FreeBSD ports and at least one or two popular Linux distributions such as Debian (depending on acceptance by those with commit bits).  This would cut down on the “above average knowledge to compile it” part.  As of this writing, there are 31593 FreeBSD ports available; and the Debian homepage currently claims >51000 packages.  I understand that lack of application compatibility is one of the major problems faced by Microsoft Windows users; and if I have a popular application, I will try to see how I can help with that.

1. Online services, possibly including a stripped-down trustless tweak generation client usable in some way with Microsoft Windows, among others.  This is a high priority to me, since I myself am poor in hardware; and the v1 network protocol I have in mind would make it almost trivial to support securely ordering up vanity addresses from your Windows PC, your iPhone, or whatever.

2. If that does not resolve demand, then maybe a Windows port, potentially with fewer features.  The modularization I am now doing should help with portability.  For example, one of the first roadblocks I hit with a mingw build was POSIX regex support.  The ultra-fast prefix checker I’m currently playing with is portable C code; a Windows build might include that and omit regex support, at least initially.

---

Quote from: Sellingaccs on March 19, 2018, 05:03:49 PM

Code:

pc@pc:~/segvan$ ./segvan -r accs

Anchored regexes will usually be significantly faster (or less slow, depending on your perspective).  Thus, try ^bc1qaccs unless you truly desire every match appearing anywhere in the string.  Giving the HRP/separator prefix is necessary, since segvan currently matches against a whole address; and no warning will be given if you provide an impossible pattern.

So do you need help compiling that btach, or what is your point?
If you need help compiling, i will need to know your linux distribution for it.

Let me know if you need such a help via PM, and i will post the guide here publicly (will compile through a VM (Virtual Machine)).
To me it seems just very unclear what kind of help you need here, if you need any.

Sorry, I meant that everything was working fine, but after reading some previous posts I thought that there would be some magic performance improvements hidden away in the sipa_grind branch to try before I started throwing a load of hardware at finding some nice addresses.

What do you mean by that?
Native segwit addresses are done by this kind of command:


And P2SH or standard segwit addresses (P2SH) with following pattern:

All of those are done with the same pattern, allthough different kind of options. The later on option with "-R" is supported by more people, rather than the standard segwit addresses shown by the first pattern. Im not that familiar with nullius's segwit address vanity generator, but feel free to quote or PM and ask questions if you have any problems.
Im not really that experienced with this script, and probably nullius will be able to advise you better.

Best Regards, Sellingaccs

I just used segvan to find 3Jjjjj8466bZXCFJQGDk1reaAXwrri39Vz, 3AAaAAMy2auJ1c5wCRj7Qbzx8qshh9cVrx and 3FffFFLntXU14ePkYK3pyASx2Smaw5TfF1

Unfortunately I had to build from master instead of the sipa_grind branch so I think I'm missing out on the huge performance improvements. Is the sipa_grind meant to be working right now?

If you want this to become more popular like vanitygen original version, you need to make windows version of it.
Most users using Windows while generating their private keys. You need above average knowledge to compile it yourself and use linux.

I'd be interested in a service like that. Please could you PM me if you ever get round to doing it? Thanks

I just really need to figure this out already. I need more time in the day to go over this over and over until I can run it normally. Thanks for creating it and I'll be sure to post my address some day when I finally figure out what I'm doing 

My apologies.  I usually publish software with a manpage, plus a usage info printout on entry of incorrect options; but in this case, I consider the options interface to be unstable.  It may change.  For now, here is an ad hoc rundown of (only) the most important options:


The two modes are exclusive of each other.  However, within each mode, different address types can be handled simultaneously.  If you want to search for both "3" addresses and bech32 addresses, each key tested will be tested against both patterns.

For bech32, case-insensitive search is always used (regardless of options) for reason that Bech32 addresses themselves are case-insensitive.

Patterns are POSIX Extended Regex (not PCRE or similar).  No attempt whatsoever will be made to prevent you from searching on an impossible pattern.  If you enter a pattern which cannot be matched by a valid address, then segvan will spin forever.

Upon SIGINT (Ctrl-C in the terminal), segvan will gracefully exit after it has finished the current iteration.  SIGINFO (on BSD) or SIGUSR1 (Linux) will print statistics to stderr.

Addresses and WIF-encoded private keys are output together on an output line, with an intervening tab.  This is intended to be friendly for piping through shell scripts.

By default (which may change), private keys use a WIF version which is specific to Electrum, and tells Electrum which address type to use.  This has been tested by me with Electrum 3.

There is currently no multithreading.  Vanity search is probabilistic, with no state or need for synchronization between search threads; therefore, you can get similar performance to what multithreading would provide by running one segvan process per CPU core.

More options exist, but I am reluctant to document them before they’re stable.  Also, there is a hidden option for generating old-style P2PKH “1” addresses.  I’m not sure whether I want to document that, because I desire to promote Segwit use.  At present, the only valid reason for generating new P2PKH addresses is if you need a Bitcoin key which can be used to sign arbitrary messages, such as forum “stake” messages.  (For that particular purpose, I suggest staking a PGP key instead.)

I hope this helps.  Please be advised that a major update is planned; it has been stalled the past week or so, due to some unfortunate and irrelevant distractions.  For now, the code in the master branch is non-feature-complete, but reliable for use; and the code in the keygrind branch is working, but not fully tested.

Nice work on the segwit vanity gen!
However, im currently facing some trouble as i cannot find any decent documentation about how this script works:

It's missing the --help argument, so what are the programmed options for this, and how do i use this?
Also, can i use the segwit addresses with electrum?

If you have a foreign-function interface which can talk to C code, has extensive comments explaining its proper use.  You may also use segvan.c as a concise guide—both for secp256k1 library use for generating public keys, and for the quite simple procedures for generating different address types.  I am currently amidst a major refactor and reorganization of the code (much delayed by recent business in Meta, etc.—sorry).  I will try to keep in mind that others may wish to use segvan code and comments as documentation for how to do these things.  I am also happy to provide tips and answer questions for other intelligent implementers, insofar as I am able.  (There’s nothing secret to what I’m doing here—and the one who actually writes the best code should get the most users!)

I would not recommend trying to implement your own secp256k1 library, unless you have extensive knowledge of both cryptography and computer science.  That said, if you want to study how this works, Dr. Wuille’s code (currently maintained it seems mostly by him (sipa) and gmaxwell) is concise and clear for those good at reading C code.  The secp256k1_ec_grind() function made famous by this thread fills less than 4 screenfulls when reading it with less(1) on a standard terminal.  That should provide a very exact answer to your specific question.  N.b. that to my understanding, the endomorphism performance increase bits may allegeably raise software patent questions in some jurisdictions; they are marked “experimental” (remember that secp256k1 is a research library!), and should only be compiled in if you are doing research and/or you are not under the jurisdiction of whatever possible patents.  It is wise to protect users this way.

(Note:  This is one reason I like to write in C.  Most of the most awesome libraries have native C interfaces.  So it has been for decades, and so it will be for at least decades more.  Other languages come and go—so to speak.)

If I were to attempt to write a similar program in Rust, are there documents anywhere that outline how I could generate keypairs efficiently like this?

Nullius great project I wish you the best of luck

Just wanted to put this out there for window users looking to generate non-native segwit / native segwit vanity addresses
you can follow this guide "https://www.youtube.com/watch?time_continue=229&v=YiMU_gtRrBQ" unfortunately the speed is slow
but if your a noob and have 0 linux experience like me it honestly wasn't that hard. It took me about 8 hours to generate the pattern a 4 letter pattern

That, you did.  Too bad I could not deploy technical means to express as much, as I promptly attempted:


Thus instead, I’ve been trying to work out how best to refactor my code now to potentially support this feature and similar later.  (Also, I am trying to work out an adequate test system so I can freely add features without risk of burning Other People’s Money.)  Nothing is in the public repo, as of yet; it’s more of a “back to the design phase” thing, and I believe in trying to keep my scratch work in my own bitbucket rather than spreading it to everyone’s.  I want to be able to plug in one-at-a-time key generation search, sipa’s keygrinder, trustless client-server “vanity tweak” generation, this (which I’ll call it a trustless pool batch tweak generator), and any other key/tweak generation methods which may arise—without substantial code copypaste.

As for the rest, I’ll try to be brief (good luck), since I should code it instead of chatting about it:


Thus in code terms, clients do secp256k1_ec_pubkey_tweak_mul(ctx, P_i, T_i).  (Not looking for handholding here; I just want to confirm my understanding in terms which will compile.)

Question:  Can anybody cause problems of any kind by using nonrandom T_i and/or P_i with interesting properties?  I think not, but wish to confirm.


Side note:  I’ve been mulling a better regex system.  Something simple and fast, and also secure for use with expressions from untrusted sources.  I like sticking with POSIX , because I always try to minimize unnecessary dependencies.  But if trying to match expressions from multiple people, it would make sense to use a library which could compile multiple expressions into one match program without hackish text manipulation à la snprintf(... "(%s)|(%s)|(%s)" ...).

This problem is made worse by unpredictable behaviour in identifying submatches with nested parentheses.  Discussing backreferences, FreeBSD’s regex(3)’s BUGS section blames this on vagueness the POSIX standard; and the problem is confirmed by my experience.  Reliable identification of top-level submatches would be an absolutely necessity here, for obvious reasons.

Does there exist a secure, efficient library offering multi-expression composite compilation and reliable submatch numbering?

Quote from: gmaxwell on February 13, 2018, 11:23:45 PM

Then the server sums all the tweaked pubkeys and grinds on it comparing the output with the omnibus matcher.

secp256k1_ec_pubkey_combine() over array of all received keys, then secp256k1_ec_grind() with the result as “master” and server-generated random seeds.

Question:  If the server’s PRNG is broken (whether through malice or incompetence), does this affect user security?  IOW, do users need to trust the server for that?  I don’t think so, but I want to be sure.

Quote from: gmaxwell on February 13, 2018, 11:23:45 PM

When it gets a hit  it then demands all clients except the one with the match to tell them the private keys for their tweaked keys (this reveals nothing about the original private key, since it's been tweaked).    It then sums up the tweak it found and everyone elses private keys and gives that to the lucky user.

I don’t see any _privkey_combine() function.  Could the server iteratively loop secp256k1_ec_privkey_tweak_add() over all received private keys, plus the generated tweak?

The lucky user does the final secp256k1_ec_privkey_tweak_mul() on his original private key (since the result generated by the server is based on his T_i from the initial step).

Quote from: gmaxwell on February 13, 2018, 11:23:45 PM

You could even have the individual users perform their own grinding.  So if they all had computers of the same speed, they effectively get an N fold speedup in how fast they find solutions.

So, pure P2P.  I will try to remember not to bolt a DHT onto it unless I have some extreme form of Sybil resistance.

Quote from: gmaxwell on February 13, 2018, 11:23:45 PM

To discourage abuse you could require a new participant grind without submitting their own keys and patterns for a while... There found tweaks prove the work they did, once someone has done enough you can give them a token they can use to submit a pubkey and pattern(s) for matching, if that user fails to reveal, you ban it.  They can rejoin ... but they have to do free work to get a new code.

To protect the privacy of users who may wish to generate different vanity addresses for unlinked nyms, this could be handled with a blind signature token system.  However, a relatively modest project then grows a significant layer of complexity.

Good behaviour in submitting private keys when asked could be easily tracked anonymously with such a token:  Send a private key when asked, receive a sent_private_key token.  The problem with using that for tracking work in a P2P system is the same as with exchanging work generally:  How to prove that the work was done?  I am thinking that in exchange for tokens, users could provide lists of distinct matches they have found for e.g. the output public key’s Hash160 starting with n zeroes (for some medium-sized n).  For each submitted POW match, receive a POW token.

Submitting a search expression costs one sent_private_key token, plus a number of POW tokens.  Since I am far from implementing this particular feature, I’ll wave my hands over that number for now—and over the question of whether this could be done without a server, or at least a semi-trusted supernode, who could be trusted to not cheat the token system (but trusted with nothing else).

Quote from: gmaxwell on February 13, 2018, 11:23:45 PM

I haven't previously implemented it because the protocol minutia with tracking and banning and whatnot is a PITA and only the mathematical part is interesting to me.

I enjoy daemonology, and I am limited in the higher maths.  So, that works for me.  I don’t know how much time I’ll be able to sink into this, when I should be coding a commercial service (some productive hackery of TLS protocol minutia) I have on the backburner; but it seems I’ve inadvertently stumbled into what could become a very popular utility if done right.

---

General design note:  I would aim for the cleanest feasible separation between the key-handling code and the network exchange of data.  I do dislike how Bitcoin marries the wallet to the network node; it’s a smaller issue with well-written code (thank you gmaxwell for all your refactoring work), but I still prefer process isolation.  In addition to memory separation, this also permits application of OS-specific sandboxing features such as capabilities mode, where supported.

Thus, I will write new code with an eye toward eventually running a secrets-handling process with no network access; and that process can use various methods to exchange non-secret data with a network process which has no access even to the filesystem (let alone any secret keys).  The sandbox APIs are simple and easy on FreeBSD and OpenBSD.  I would accept well-written patches for Linux.  AFAIK, there is no such feature on Windows.  I don’t know anything about Mac.

---

Thanks again for the hardcore tech talk.  This is the forum I’ve said “I wish I could now experience”!  I know that a post is most valuable when it takes me all day to digest it, mull its potential implications, and formulate proper questions in response.

Allow me to knock your socks off:

Say you have N people who each want to find a vanity tweak of their pubkeys which will roughly take M million tries to find.

You can find all N of them with just ~M million tries, instead of the N*M million tries if they were to do them themselves alone.

Here is how.  Each person has a pubkey P_i,   they all come up with uniformly random tweaks T_i.  They tweak their keys, and send these resulting public keys to the hashing server. They keep the tweak and original pubkey private.   They also send the string(s) they want to match. They stay connected.

The sever takes all the strings and compiles them into a single match expression (which can be matched in log() operations at worst, probably better).

Then the server sums all the tweaked pubkeys and grinds on it comparing the output with the omnibus matcher.

When it gets a hit  it then demands all clients except the one with the match to tell them the private keys for their tweaked keys (this reveals nothing about the original private key, since it's been tweaked).    It then sums up the tweak it found and everyone elses private keys and gives that to the lucky user.

Everyone remaining sends new tweaked pubkeys  (probably in the same message they sent their prior private keys).  They get summed and the process continues with the new basepoint.

If someone fails to send their private key, you kick them off and ban them and you lose that result because you cannot reconstruct the tweaks without everyone elses keys.

Implemented correctly this is completely secure.

You could even have the individual users perform their own grinding.  So if they all had computers of the same speed, they effectively get an N fold speedup in how fast they find solutions.

To discourage abuse you could require a new participant grind without submitting their own keys and patterns for a while... There found tweaks prove the work they did, once someone has done enough you can give them a token they can use to submit a pubkey and pattern(s) for matching, if that user fails to reveal, you ban it.  They can rejoin ... but they have to do free work to get a new code.

I haven't previously implemented it because the protocol minutia with tracking and banning and whatnot is a PITA and only the mathematical part is interesting to me.

The short version:  An untested, experimental branch of my code now finds a speedup of 5x for difficult patterns using sipa’s keygrind:

https://github.com/nym-zone/segvan/tree/sipa_grind

My code needs some work to take full advantage of this.  It will be worth it.  I wish I’d had this when making the addresses in my signature—well, perhaps soon I may make better addresses for my signature!


I’ve also been seriously mulling ideas for an online service which finds “vanity tweaks” for a private key held by a user—essentially, convenient results from rented time on powerful CPUs in the “cloud” (much though I loathe that word).  I’m curious as to how popular such a service could be.  Anybody interested?

---

(What took so long?  After whipping together a quick implementation, I had hours drained by the bane of my existence, GNU autoconf.  A hint at a solution was eventually found in a comment (not the answer) to a Stackoverflow question.  Then, I had to fix one of my own dumb mistakes.  —Then, speed test and explore the performance characteristics of this code.)

After playing around a bit, I decided that the sanest way (easiest for auditors) is to do this with a public fork.  I merged sipa’s 201802_grind branch into the current bitcoin-core/secp256k1 master:

https://github.com/nym-zone/secp256k1/commits/sipa_201802_grind

The code you will soon see show up in segvan will match the code you find there.

Thanks to gmaxwell for the tip!

---

Edit 2018-02-13 08:58 UTC:  As of an hour or two ago, I finished an initial working implementation with sipa’s key-grinder.  It compiles fine on Linux in the same tree where I ran autogen.sh; but the resulting configure/Makefile hork up errors when transferred to another system for tests.  I will update OP and bump the thread when I have real news to report.