Is there a bech32 vanity address generator?

[jackg]

I've been looking into trying to find a bech32 vanity address generator and was wondering if there is already one?

If not, I might try building a simple one based on my own needs (so would just be a minimal version and probably quite slow unless I can work out the source code of vanitygen and try to edit it to encorporate the bc1 part into it).

Unless there's a way to convert a legacy address into a bech one though I assumed the private keys would be of a different type?

[1714042146]

1714042146

[1714042146]

1714042146

[1714042146]

1714042146

[RGBKey]

I haven't seen one, but if you want I'd try to contribute to one on GitHub or somewhere. I like the idea, even though I know vanity addresses pose some security problems and they're not incorporated into HD backups, I still think it'd be really cool. Maybe here would be a good place to start?

[jackg]

I haven't seen one, but if you want I'd try to contribute to one on GitHub or somewhere. I like the idea, even though I know vanity addresses pose some security problems and they're not incorporated into HD backups, I still think it'd be really cool. Maybe here would be a good place to start?

Thanks for the link. What languages would you use as I'd personally prefer either C# or Python (python is quite slow so I'd have to convert it to C# afterwards as that seems quite a bit faster).

Currently reading the data from the link and want to see if I can build any interim stuff from it just as a simple address generator (or some sort of validator).

[RGBKey]

I haven't seen one, but if you want I'd try to contribute to one on GitHub or somewhere. I like the idea, even though I know vanity addresses pose some security problems and they're not incorporated into HD backups, I still think it'd be really cool. Maybe here would be a good place to start?

Thanks for the link. What languages would you use as I'd personally prefer either C# or Python (python is quite slow so I'd have to convert it to C# afterwards as that seems quite a bit faster).

Currently reading the data from the link and want to see if I can build any interim stuff from it just as a simple address generator (or some sort of validator).

I don't know C#, but I know a little but of C. I'd be willing to try to learn though, I know Java and Node.js, and I've heard Java is very similar to C#

[jackg]

I haven't seen one, but if you want I'd try to contribute to one on GitHub or somewhere. I like the idea, even though I know vanity addresses pose some security problems and they're not incorporated into HD backups, I still think it'd be really cool. Maybe here would be a good place to start?

Thanks for the link. What languages would you use as I'd personally prefer either C# or Python (python is quite slow so I'd have to convert it to C# afterwards as that seems quite a bit faster).

Currently reading the data from the link and want to see if I can build any interim stuff from it just as a simple address generator (or some sort of validator).

I don't know C#, but I know a little but of C. I'd be willing to try to learn though, I know Java and Node.js, and I've heard Java is very similar to C#

I think C#, C and Java are all quite close together yes and if you use a program like Visual Studio, the program fills in some of the gaps for you so it's quite nice to work with.

Do you not know any Python? Normally people start with that as its a fairly forgiving language to start on. I did an android version of JAVA a few years ago also so might be able to regress my knowledge a little.

[RGBKey]

I know no Python, I started with javascript in webpages, worked with Node.js for a long time, and in the past 2 years I've started to work with Java, and I've started with C in the past 6 months.

[jackg]

I know no Python, I started with javascript in webpages, worked with Node.js for a long time, and in the past 2 years I've started to work with Java, and I've started with C in the past 6 months.

Can you suggest a good JAVA client to use for development then and I'll try to see how it goes. I think they have tutorials on w3 that I can check also so that might work a bit better?

Would you use visual studio or another development software that can connect to Github?

[nullius]

What platform are you on?  In late December, I wrote a Segwit “Bravo Charlie addresses” (Bech32) and also P2SH-nested (“3” addresses).  It can search for both at once, which is beneficial because key generation is expensive.  This was used to generate both the Bitcoin addresses you see in my signature:  The address starting with “3NULL”, and the address starting with “bc1qcash”.

It is written in C.  I’ve been intending to clean up the code, test-test-test, and put it on Github; but somehow, that keeps getting pushed down the TODO list.  It is UNIX/Linux only, though I’ve mulled trying to compile Windows binaries with mingw if there were demand.  (I do not have any Windows systems.)

My generator is not derived from Vanitygen or any other vanity address generator.  At present, and in any foreseeable initial release, it does not use the point addition trick which Vanitygen uses; for each key tried, it reads a new private key off /dev/urandom and creates a public key from that using Core’s secp256k1 library.  Thus, it is relatively slow.  On an ancient airgap laptop with a very slow CPU, it can try a maximum of about 10k keys per second per core.  I just leave it running with a pattern; it has been running for weeks, as of now (I should check on it!).  Based on comparisons of how long a FreeBSD buildworld takes, I guesstimate that a newer CPU might get close to 100k keys/second/core.  A major speedup was obtained by using Core’s library; it is 5x–7x faster with Core’s secp256k1 than with libcrypto (OpenSSL), so I ripped out the code for using the latter.

unless I can work out the source code of vanitygen and try to edit it to encorporate the bc1 part into it

Beware, Segwit requires that addresses be generated from compressed public keys.  Vanitygen does not support compressed keys; I saw a patch somewhere on Github for that, with ensuing discussion pointing out that the patch had a serious bug.  (Aside, this also means that Vanitygen users are paying even more unnecessary fees than they are for not using Segwit.)

All the Bitcoin software I write uses only compressed public keys.  Also, I pay careful attention to avoiding release of any money-losing bugs.  This is one reason I am sometimes slow with these things.  Testing can take longer than coding.

[jackg]

What platform are you on?  In late December, I wrote a Segwit “Bravo Charlie addresses” (Bech32) and also P2SH-nested (“3” addresses).  It can search for both at once, which is beneficial because key generation is expensive.  This was used to generate both the Bitcoin addresses you see in my signature:  The address starting with “3NULL”, and the address starting with “bc1qcash”.

It is written in C.  I’ve been intending to clean up the code, test-test-test, and put it on Github; but somehow, that keeps getting pushed down the TODO list.  It is UNIX/Linux only, though I’ve mulled trying to compile Windows binaries with mingw if there were demand.  (I do not have any Windows systems.)

My generator is not derived from Vanitygen or any other vanity address generator.  At present, and in any foreseeable initial release, it does not use the point addition trick which Vanitygen uses; for each key tried, it reads a new private key off /dev/urandom and creates a public key from that using Core’s secp256k1 library.  Thus, it is relatively slow.  On an ancient airgap laptop with a very slow CPU, it can try a maximum of about 10k keys per second per core.  I just leave it running with a pattern; it has been running for weeks, as of now (I should check on it!).  Based on comparisons of how long a FreeBSD buildworld takes, I guesstimate that a newer CPU might get close to 100k keys/second/core.  A major speedup was obtained by using Core’s library; it is 5x–7x faster with Core’s secp256k1 than with libcrypto (OpenSSL), so I ripped out the code for using the latter.

unless I can work out the source code of vanitygen and try to edit it to encorporate the bc1 part into it

Beware, Segwit requires that addresses be generated from compressed public keys.  Vanitygen does not support compressed keys; I saw a patch somewhere on Github for that, with ensuing discussion pointing out that the patch had a serious bug.  (Aside, this also means that Vanitygen users are paying even more unnecessary fees than they are for not using Segwit.)

All the Bitcoin software I write uses only compressed public keys.  Also, I pay careful attention to avoiding release of any money-losing bugs.  This is one reason I am sometimes slow with these things.  Testing can take longer than coding.

I think your project duffers from one I envisaged myself writing. And as you're using bitcoin core to produce the keys then I'm not sure that's particularly efficient (and most of my computers are extremely slow)!

Can you not just get a C CLI for Windows and run it on that if someone particularly wanted to also (only Linux system I have is a raspberry pi, I tried installing Ubuntu on my laptop but it's BIOS didn't recognise the ISO or the installation disk ).

[nullius]

I think your project duffers from one I envisaged myself writing. And as you're using bitcoin core to produce the keys then I'm not sure that's particularly efficient (and most of my computers are extremely slow)!

You misunderstood.  I am not using Bitcoin Core to generate the keys—what?  Through the JSON-RPC interface?  That would be absurdly slow, and quite stupid.  Rather, I am using Core’s “Optimized C library for EC operations on curve secp256k1”.  Speed-wise, it runs circles around OpenSSL for ECC key operations.  On the slow test machine, with OpenSSL, I could never get over about 1500 trials per second per CPU core.  With Core’s library, I can get up to around 10000 t/s/c; and the speed of my platform’s regex library seems to become a serious bottleneck.

The probability is negligible that any of your computers could be slower than mine are.

Can you not just get a C CLI for Windows and run it on that if someone particularly wanted to also

I have no Windows in my house.  The idea I’d floated is using mingw to create a Microsoft Windows binary from a non-Windows system.

Before publicly distributing such a thing with my name on it, I would need to work with tester(s) who have Windows systems available.  It’d be good to know if anybody would be interested in doing that (cough).

(only Linux system I have is a raspberry pi, I tried installing Ubuntu on my laptop but it's BIOS didn't recognise the ISO or the installation disk :( ).

Off-topic:  I smell a potential issue of EFI vs. MBR.  You said your computers are slow; therefore, I presume they are old.  I suspect you may have downloaded something which uses EFI, and does it in a manner wholly incompatible with older systems.  This question is way off-topic here; should you be interested in discussing it, feel free to PM or e-mail me.  PGP mail is most preferred.

[jackg]

I think your project duffers from one I envisaged myself writing. And as you're using bitcoin core to produce the keys then I'm not sure that's particularly efficient (and most of my computers are extremely slow)!

You misunderstood.  I am not using Bitcoin Core to generate the keys—what?  Through the JSON-RPC interface?  That would be absurdly slow, and quite stupid.  Rather, I am using Core’s “Optimized C library for EC operations on curve secp256k1”.  Speed-wise, it runs circles around OpenSSL for ECC key operations.  On the slow test machine, with OpenSSL, I could never get over about 1500 trials per second per CPU core.  With Core’s library, I can get up to around 10000 t/s/c; and the speed of my platform’s regex library seems to become a serious bottleneck.

The probability is negligible that any of your computers could be slower than mine are.

Can you not just get a C CLI for Windows and run it on that if someone particularly wanted to also

I have no Windows in my house.  The idea I’d floated is using mingw to create a Microsoft Windows binary from a non-Windows system.

Before publicly distributing such a thing with my name on it, I would need to work with tester(s) who have Windows systems available.  It’d be good to know if anybody would be interested in doing that (cough).

(only Linux system I have is a raspberry pi, I tried installing Ubuntu on my laptop but it's BIOS didn't recognise the ISO or the installation disk ).

Off-topic:  I smell a potential issue of EFI vs. MBR.  You said your computers are slow; therefore, I presume they are old.  I suspect you may have downloaded something which uses EFI, and does it in a manner wholly incompatible with older systems.  This question is way off-topic here; should you be interested in discussing it, feel free to PM or e-mail me.  PGP mail is most preferred.

1. Yes I did definitely misunderstand what you meant there at the start. I thought you tapped into a regular bitcoin core library which would most likely cause a bottleneck. On the regex, would if/else statements in plain text solve it or just make it much worse.
2. Please PM me. One of the laptops is only a year old it does have a lot of RAM intensive stuff that needs to run though. I ran a test on my 7 year old one and my 2 Cores, 12 threads at 200MHz were all active at 199Hz (I assume the 1MHz was due to undervolting). What's efi/MBR? I only know MBR as being a register on an OS.

Edit: oh is it to do with hard drives (I did a Google search).

[RGBKey]

I have no Windows in my house.  The idea I’d floated is using mingw to create a Microsoft Windows binary from a non-Windows system.

Before publicly distributing such a thing with my name on it, I would need to work with tester(s) who have Windows systems available.  It’d be good to know if anybody would be interested in doing that (cough).

I use Windows, I could compile/test if needed.

I think your project duffers from one I envisaged myself writing. And as you're using bitcoin core to produce the keys then I'm not sure that's particularly efficient (and most of my computers are extremely slow)!

You misunderstood.  I am not using Bitcoin Core to generate the keys—what?  Through the JSON-RPC interface?  That would be absurdly slow, and quite stupid.  Rather, I am using Core’s “Optimized C library for EC operations on curve secp256k1”.  Speed-wise, it runs circles around OpenSSL for ECC key operations.  On the slow test machine, with OpenSSL, I could never get over about 1500 trials per second per CPU core.  With Core’s library, I can get up to around 10000 t/s/c; and the speed of my platform’s regex library seems to become a serious bottleneck.

The original vanitygen runs much slower in regex mode, right? It would be better to first attempt to run in a "prefix mode" like vanitygen if possible that just checks the equality of the first characters, and doesn't evaluate a regular expression.

[Kakmakr]

Is there currently a generator that creates normal Bech32 {SegWit} paper wallets? The http://www.bitaddress.org/ is still creating old legacy Bitcoin addresses. By normal, < I meant to say not Vanity addresses >

If we want to move to SegWit / Bech32, then these tools must be readily available. A lot of people are forced to use dodgy online wallet providers to create these SegWit addresses. <Most of these cannot even be signed by the owner of the coins> 

[jackg]

Is there currently a generator that creates normal Bech32 {SegWit} paper wallets? The http://www.bitaddress.org/ is still creating old legacy Bitcoin addresses. By normal, < I meant to say not Vanity addresses >

If we want to move to SegWit / Bech32, then these tools must be readily available. A lot of people are forced to use dodgy online wallet providers to create these SegWit addresses. <Most of these cannot even be signed by the owner of the coins> 

There is. As you're in with the chipmixer campaign, darkstar posted one (maybe try checking that thread). I'm not sure what it is exactly, you could always PM him also.

[DarkStar_]

Is there currently a generator that creates normal Bech32 {SegWit} paper wallets? The http://www.bitaddress.org/ is still creating old legacy Bitcoin addresses. By normal, < I meant to say not Vanity addresses >

If we want to move to SegWit / Bech32, then these tools must be readily available. A lot of people are forced to use dodgy online wallet providers to create these SegWit addresses. <Most of these cannot even be signed by the owner of the coins> 

There is. As you're in with the chipmixer campaign, darkstar posted one (maybe try checking that thread). I'm not sure what it is exactly, you could always PM him also.

Disclaimer: I have personally never used SegwitAddress.org. Use at own risk, though it's open source and you can audit it.

[jackg]

Is there currently a generator that creates normal Bech32 {SegWit} paper wallets? The http://www.bitaddress.org/ is still creating old legacy Bitcoin addresses. By normal, < I meant to say not Vanity addresses >

If we want to move to SegWit / Bech32, then these tools must be readily available. A lot of people are forced to use dodgy online wallet providers to create these SegWit addresses. <Most of these cannot even be signed by the owner of the coins> 

There is. As you're in with the chipmixer campaign, darkstar posted one (maybe try checking that thread). I'm not sure what it is exactly, you could always PM him also.

Disclaimer: I have personally never used SegwitAddress.org. Use at own risk, though it's open source and you can audit it.

Ooh thanks darkstar_ might take a look at their encoder and see if I can learn anything from it to produce an algorithm. Might test them in a few days with a couple btc to see how reliable they are at producing addresses/private keys from their site.

[RGBKey]

I don't think programming a proof-of-concept vanity address generator in C would be that hard, if we use core's library to generate the keys. Optimization could come later, but implementing Bech32 in C would not be that difficult.

[nullius]

Apologies for the slow reply.  Catching up here a bit out of order:

Is there currently a generator that creates normal Bech32 {SegWit} paper wallets? The http://www.bitaddress.org/ is still creating old legacy Bitcoin addresses. By normal, < I meant to say not Vanity addresses >

If we want to move to SegWit / Bech32, then these tools must be readily available. A lot of people are forced to use dodgy online wallet providers to create these SegWit addresses. <Most of these cannot even be signed by the owner of the coins>  

I didn’t mention, my “vanity” generator sort of started as a bulk Segwit address generator which grew a regex loop.  It can rapidly output however many hundreds or thousands of addresses you may desire, “3” nested or Bech32, in a shell script friendly format with each line containing an address and the corresponding private key WIF.  It’s made for piping to something else, for specialized use cases only.  I didn’t mention this, because I strongly encourage users to use only HD wallets (other than for vanity addresses, of course).

See below re easyseed.

There is. As you're in with the chipmixer campaign, darkstar posted one (maybe try checking that thread). I'm not sure what it is exactly, you could always PM him also.

Mine probably does similarly to what I presume ChipMixer’s would do:  Fast bulk generation of pairs of addresses and WIFs.

I don't think programming a proof-of-concept vanity address generator in C would be that hard, if we use core's library to generate the keys. Optimization could come later, but implementing Bech32 in C would not be that difficult.

It’s not hard—at least, up to that point, it isn’t.  Mine started as an afternoon project.  There’s no need to implement Bech32 itself:  I just use sipa’s Bech32 reference code, the same as I used in my bech32 shell utility (Github).


Kakmakr, for safe paper wallet use:  I’ve considered adding BIP 32 derivation to easyseed (Github).  That would do what you want, in an HD wallet you could back up with a mnemonic phrase in your choice from eight languages.  easyseed’s creation was motivated by my own need for secure, simple code to use on an airgap machine—no saved webpage junk!  Much if not most of its development process has been testing; and in that process, I caught a bug in the BIP 39 French wordlist.  But as of now, the most it will give you is a BIP 39 mnemonic phrase and the corresponding BIP 32 master extended private key.

This is solid, working code.  If I were to add BIP 32 derivation so it could generate addresses, would that suit your needs for airgap/paper wallet use?

On the regex, would if/else statements in plain text solve it or just make it much worse.

The original vanitygen runs much slower in regex mode, right? It would be better to first attempt to run in a "prefix mode" like vanitygen if possible that just checks the equality of the first characters, and doesn't evaluate a regular expression.

I could add that; but first, I should work on getting code published.

Also, I think a higher priority is thread support.  Right now, I simply run one instance per CPU core; this is a probabilistic process, so there is no need for synchronization of state.  Threads should be simple here, but may have problems cross-platform—what do you think, RGBKey?

I use Windows, I could compile/test if needed.

Thanks.  I will initially put something Unix-only on Github, then work on making ready for some sort of Windows version.  What is your Windows development environment?  I think I need to try going the mingw route, due to use of POSIX getopt(), POSIX regex, etc.

What's efi/MBR? I only know MBR as being a register on an OS.

Edit: oh is it to do with hard drives (I did a Google search).

It doesn’t have to do with hard drives, so much as with how the computer finds the OS on boot media and hands off control to it (roughly speaking).  My favoured OS (FreeBSD) packages two different sets of install images; and if you use the new-stuff-only one with an older computer, it will behave much as you described.  That’s why I thought of it.  (Side note:  I spoke imprecisely:  It’s really MBR vs. GPT and BIOS vs. EFI; but all these issues are related.  Setting the record straight for other readers/searchers. </offtopic>)

I should probably spend less time on the forum and more time on code.

Edit:  Added a hyperlink to sipa’s reference C code.

[RGBKey]

I use Windows, I could compile/test if needed.

Thanks.  I will initially put something Unix-only on Github, then work on making ready for some sort of Windows version.  What is your Windows development environment?  I think I need to try going the mingw route, due to use of POSIX getopt(), POSIX regex, etc.

My very limited C knowledge involves writing code on a linux VM and compiling with gcc. I can adapt to whatever though. I have the ability to get free licenses for visual studio through work.

[Coding Enthusiast]

I haven't seen one, but if you want I'd try to contribute to one on GitHub or somewhere. I like the idea, even though I know vanity addresses pose some security problems and they're not incorporated into HD backups, I still think it'd be really cool. Maybe here would be a good place to start?

Thanks for the link. What languages would you use as I'd personally prefer either C# or Python (python is quite slow so I'd have to convert it to C# afterwards as that seems quite a bit faster).

Currently reading the data from the link and want to see if I can build any interim stuff from it just as a simple address generator (or some sort of validator).

If you want code to look at and see how it is done then check out sipa's implementation of Bech32. It has almost all the programming languages you want.
And here is a C♯ implementation of it in this PR