Bitcoin Forum
May 28, 2020, 04:16:57 AM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 [171] 172 173 174 175 176 177 178 179 180 181 182 183 184 185 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 1143644 times)
za3toor
Newbie
*
Offline Offline

Activity: 29
Merit: 0


View Profile
December 22, 2017, 08:50:49 PM
 #3401

Hello Guys...

This is a very interesting software. Would it be possible to add a feature that instead of looking to match the public key, can it match the RIPEMD-160 instead.

This will save a lot of computations and it will be far more efficient. Once it matches the RIPEMD-160, it will be very easy to calculate the public key from there. Of course the requirement that the user has to supply with the desired RIPEMD-160 key.

We can use this site to determine the RIPMED-160. http://gobittest.appspot.com/Address

With this approach, we will save a lot of computations for the double SHA-256  + BASE58 conversion for each trial.

Thanks,
Z
1590639417
Hero Member
*
Offline Offline

Posts: 1590639417

View Profile Personal Message (Offline)

Ignore
1590639417
Reply with quote  #2

1590639417
Report to moderator
FAST DICE GAME $500 DAILY CONTEST BEST AUTOBET MODE 30% RAKEBACK FOR VIPS PROVABLY FAIR Play Now Play Now
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
markasoftware
Full Member
***
Offline Offline

Activity: 166
Merit: 100


View Profile WWW
December 24, 2017, 04:48:44 AM
 #3402

Hello Guys...

This is a very interesting software. Would it be possible to add a feature that instead of looking to match the public key, can it match the RIPEMD-160 instead.

This will save a lot of computations and it will be far more efficient. Once it matches the RIPEMD-160, it will be very easy to calculate the public key from there. Of course the requirement that the user has to supply with the desired RIPEMD-160 key.

We can use this site to determine the RIPMED-160. http://gobittest.appspot.com/Address

With this approach, we will save a lot of computations for the double SHA-256  + BASE58 conversion for each trial.

Thanks,
Z

But, with just the RIPEMD hash, how do you know anything about the final address without generating it? What is the point of having a cool RIPEMD-160 hash? The whole point of vanitygen is to have cool addresses, not intermediate values.

Check out MarkaPool.
Also check out my open source projects.
nullius
Copper Member
Sr. Member
****
Offline Offline

Activity: 336
Merit: 1620


There is only one Bitcoin.


View Profile WWW
December 24, 2017, 11:02:54 AM
Last edit: February 12, 2018, 07:04:43 PM by nullius
Merited by dbshck (2), Chris! (2), LoyceV (1), jtipt (1)
 #3403

In reply to these, and likely others earlier in the thread:

Is there anyone working on vanitygen fork to generate vanity bech32 addresses? Seems like it might be easier to get longer firstbits that make sense because it's more limited in characters.

Dear samr7, we really need SegWit feature

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.  [Edit 2018-02-12:  segvan: Segwit vanity address & bulk address generator (Github).]

Some sample outputs from short patterns:

3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG  (^3NULL[0-9])

bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h (hahah; ^bc1qcash[0-9])

From earlier tests, WIF private key import was confirmed by me to work perfectly in Electrum:


Segwit addresses are sexy!
(Typo correction:  Of course, that should be “imported from WIF”.
I pray that the god of prepositions not smite me.)

The code is in C, Unix-only.  It’s fairly trivial; it essentially glues together Core’s secp256k1 library, luke-jr’s libbase58, and sipa’s reference Bech32 code.  It has almost no features; it won’t even try to tell you if the pattern you seek is impossible.  I’d intended to toss it out there somewhere for others to play with; but it devolved into a patchwork of #ifdefs with multiple different code paths, due to an build-time problem with dependencies.  It would require time and effort to clean up.

How great is the interest in this?

exander77
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
December 26, 2017, 12:05:53 AM
 #3404

Anyone here actually managed to get this to compile under Windows?

Seems every dependancy is outdatted and tons of warnings/errors.

I crosscompile it for Windows on Linux (Ubuntu 17.10).
Thirdspace
Hero Member
*****
Offline Offline

Activity: 1232
Merit: 725


Mixing reinvented for your privacy | chipmixer.com


View Profile
December 26, 2017, 01:02:47 AM
 #3405

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.
Quote
How great is the interest in this?

interesting... I'm pretty sure there is big interest in them. did you fork samr's vanitygen or start from scratch?
though since bech32 addresses are not yet implemented by most wallet,
the interest in bech32 addresses would be somewhat lower than that for segwit 3xxx addresses
any stats on how many addresses/second your generator can do?

markasoftware
Full Member
***
Offline Offline

Activity: 166
Merit: 100


View Profile WWW
December 26, 2017, 02:26:06 AM
 #3406

In reply to these, and likely others earlier in the thread:

Is there anyone working on vanitygen fork to generate vanity bech32 addresses? Seems like it might be easier to get longer firstbits that make sense because it's more limited in characters.

Dear samr7, we really need SegWit feature

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.

Some sample outputs from short patterns:

3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG  (^3NULL[0-9])

bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h (hahah; ^bc1qcash[0-9])

From earlier tests, WIF private key import was confirmed by me to work perfectly in Electrum:


Segwit addresses are sexy!
(Typo correction:  Of course, that should be “imported from WIF”.
I pray that the god of prepositions not smite me.)

The code is in C, Unix-only.  It’s fairly trivial; it essentially glues together Core’s secp256k1 library, luke-jr’s libbase58, and sipa’s reference Bech32 code.  It has almost no features; it won’t even try to tell you if the pattern you seek is impossible.  I’d intended to toss it out there somewhere for others to play with; but it devolved into a patchwork of #ifdefs with multiple different code paths, due to an build-time problem with dependencies.  It would require time and effort to clean up.

How great is the interest in this?

May I ask why you wrote it from scratch? Why not just modify the code from vanitygen to change how it converts ECDSA keypair to address?

Check out MarkaPool.
Also check out my open source projects.
nullius
Copper Member
Sr. Member
****
Offline Offline

Activity: 336
Merit: 1620


There is only one Bitcoin.


View Profile WWW
December 26, 2017, 04:10:29 AM
 #3407

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.
Quote
How great is the interest in this?

interesting... I'm pretty sure there is big interest in them. did you fork samr's vanitygen or start from scratch?
though since bech32 addresses are not yet implemented by most wallet,
the interest in bech32 addresses would be somewhat lower than that for segwit 3xxx addresses
any stats on how many addresses/second your generator can do?

I am thrilled to see the interest in Bravo Charlie Addresses!  Spread the word, “Bravo Charlie One means money.”

I wrote it from “scratch”—well, not really.  At first, I simply glued together sipa’s reference bech32 code, Core’s secp256k1, luke-jr’s libbase58, and standard POSIX extended regular expressions.  Then due to build dependency problems on my airgap machine, I had to semi-rewrite it with OpenSSL secp256k1 and my own base58check encoder using OpenSSL bignums.  This was supposed to be what you might call an “little pastime project”, done on a whim.

To be absolutely clear, I do handle both Bech32 and P2SH-nested Segwit “3” addresses.  Right now, pattern-matching is done on either one or the other; that’s stupid.  I intend to change it to check the same trial key against different patterns for both, if the operator so desires.

The code is slow, partly because I do a real bruteforce search:  Read a new private key off /dev/urandom, try its corresponding public key, and throw it away if that doesn’t match.  I always somewhat distrusted vanity addresses; and this is the paranoid way to make them.  Partly also because I made no attempt to make it fast.  I will try to get you some useful benchmark numbers after I do some immediately planned improvements.  Moreover, although I paid careful attention to basic tests, I’ll want to test more and play with testnet coins before foisting my code on other people where a bug could lose Other People’s Money.

The precursor idea popped into my head when I observed that ChipMixer is still not using Segwit; thus, I had in the back of my mind to see how hard it would be to make bulk Segwit addresses on demand.  It’s trivial; and my code will churn out as many thousands of nested-P2SH or Bech32 addresses and matching private keys as you could want, lightning-fast.  (Of course, ordinary users should use an HD wallet!)  I was pushed to action when I hit a thread where somebody was criticizing the aesthetics of Bech32.  What better way to persuade that Bech32 is pretty, than to show off a sweet vanity address?  So, I whipped up my bulk address generator and tacked on a regex pattern loop function.

Note for Microsoft Windows users:  My vanity generator uses POSIX regular expressions and other standard Unix APIs; and I want to keep dependencies to a minimum, for my own usage.  Thus, I doubt there would ever be a version which could be compiled with MSVC.  But I think that mingw has regex support; so perhaps there may be hope.  I would not be able to test the resulting binaries myself; for I have no Windows in my home or office.  I may try to get this working, if I see signs of sufficient interest (viz., potential for tips).  I myself will build and test on FreeBSD and Linux, in that order.


May I ask why you wrote it from scratch? Why not just modify the code from vanitygen to change how it converts ECDSA keypair to address?

Sundry reasons:

  • I was scratching an itch.
  • I needed a bulk address generator anyway.
  • I wanted something small and light, with as few dependencies as practicable.
  • vanitygen is AGPL.  As an advocate of liberal licensing and best of all, the public domain, I will avoid contributing my time and effort to a project whose code I can’t borrow without virally infecting my own codebase; GPL is a one-way street, and worst of all is AGPL.
  • vanitygen appears to be abandonware, with accumulating pull requests and an otherwise-maintained fork which people don’t seem to be switching to.
  • I do not have the requisite cryptanalytic expertise for evaluating the safety of the EC trick which vanitygen uses for speedup.  This is not to criticize vanitygen specifically:  I have significant general misgivings about vanity addresses; and anything other than fully random key selection makes me uncomfortable.
  • I have no idea what it would take to make vanitygen use compressed public keys as mandatory for Segwit (one pull request is open since 2013, with a severe bug as noted in the comments), then add the other needed code for Segwit address generation.  (Aside:  Even if you were to desire to still use old-style addresses without the Segwit fee discount, use of uncompressed public keys is really throwing away your money on fees.)  Whereas I already know exactly how to create such an implementation myself—on a whim—which this was.
  • I have never used vanitygen.  I first looked at its codebase a few minutes ago, to inform myself for an intelligent reply to you.  I didn’t actively choose not to patch a program I’ve never used; I independently wanted something, so I wrote it, and that’s that.

arulbero
Legendary
*
Offline Offline

Activity: 1494
Merit: 1587


View Profile
December 26, 2017, 07:26:22 AM
Last edit: December 26, 2017, 07:59:07 AM by arulbero
 #3408


The code is slow, partly because I do a real bruteforce search:  Read a new private key off /dev/urandom, try its corresponding public key, and throw it away if that doesn’t match.  I always somewhat distrusted vanity addresses; and this is the paranoid way to make them.  Partly also because I made no attempt to make it fast.  I will try to get you some useful benchmark numbers after I do some immediately planned improvements.  Moreover, although I paid careful attention to basic tests, I’ll want to test more and play with testnet coins before foisting my code on other people where a bug could lose Other People’s Money.

....

  • I do not have the requisite cryptanalytic expertise for evaluating the safety of the EC trick which vanitygen uses for speedup.  This is not to criticize vanitygen specifically:  I have significant general misgivings about vanity addresses; and anything other than fully random key selection makes me uncomfortable.

....


To speed up the generation of the public keys from the private keys you need to use consecutive private keys. Moreover you should generate batches of public keys instead of generating only one key each time from /dev/urandom.

I developed a ecc library for the LBC collider project. Just to give you a benchmark, my program generates 16.77 consecutive MKeys in 1 second, but to generate 16.77 no consecutive Mkeys it takes 39 seconds (on a Xeon mobile Kabylake cpu, 1 core). If I don't use the batches neither (i.e. if I compute a field inverse for each key) it takes 98 seconds. Then: 1  -> 39 -> 98 seconds.

If an address generator is well optimized, the ecc part should take only the 7-8% of the time, sha256 + ripemd160 the 92% (on a cpu, on a gpu the things are different). On my cpu I can get 3 Maddresses/s with 1 core (using only compressed keys because compressed addresses are faster to generate).
kain134
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
December 30, 2017, 03:05:00 PM
 #3409

Why are certain patters so much harder to find then other patterns?

I was looking for somebodies name with the -i option so non case sensitive.

It found last name first name in under a minute (guess I got really lucky) with a difficulty of 778316249440 which with 15Mkey/s would take 10 hours for a 50% chance.

Now I searched for the exact name but with first name last name and that gave a difficulty of 23349487483220 which would take 13 days for a 50% chance.

Why is this?

Is there also a reason why people are only looking for patterns in the beginning of the adress?

I probably don't understand all the ins and outs yet but basically the program starts with some randomness to create usefull privatekeys and then just generates millions of keys just looking for some key to fly by that resolved to a public address that has the pattern we are looking for.

If that is true then why can't I search with oclvanitygen for patterns anywhere in the address, not just in the beginning.

Or am I missing something here?

raaaj100
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
December 30, 2017, 10:16:52 PM
 #3410

Currently, it is difficult to import the private key into bitcoin.  Sipa's showwallet branch has a new command called "importprivkey" that accepts the base-58 encoded private key.  Vanitygen has been tested to work with that version of bitcoin, although it had to be restarted to get the imported vanity address to show up on the list in the GUI.

I've just pushed a bugfix, and can't reproduce the problem now. Could you try again?

PS: yes, it's quite normal your code is a lot faster - the vanity patch just tried generating random keys until a match was found, requiring generating 256 random bits + an EC multiplication per attempt. Your code only needs an EC addition per attempt.
xhomerx10
Legendary
*
Offline Offline

Activity: 2394
Merit: 2968


Aceeasi Marie cu alta palarie


View Profile
December 30, 2017, 10:27:12 PM
 #3411

Why are certain patters so much harder to find then other patterns?

I was looking for somebodies name with the -i option so non case sensitive.

It found last name first name in under a minute (guess I got really lucky) with a difficulty of 778316249440 which with 15Mkey/s would take 10 hours for a 50% chance.

Now I searched for the exact name but with first name last name and that gave a difficulty of 23349487483220 which would take 13 days for a 50% chance.

Why is this?

Is there also a reason why people are only looking for patterns in the beginning of the adress?

I probably don't understand all the ins and outs yet but basically the program starts with some randomness to create usefull privatekeys and then just generates millions of keys just looking for some key to fly by that resolved to a public address that has the pattern we are looking for.

If that is true then why can't I search with oclvanitygen for patterns anywhere in the address, not just in the beginning.

Or am I missing something here?



 Use vanitygen with the -r (regex) option and you can search for patterns anywhere in the address.  Be aware that this is much slower than using oclvanitygen though.  Also, the program doesn't check for the validity of your search so you could be searching for something that doesn't exist as a Bitcoin address if you aren't careful.

for example,
vanitygen -r 0f
(that's a zero by the way) will cause the program to search forever because zero is not a valid base58 character.




Forum legend Phinnaeus Gage has passed on. 
 His final wish was for financial assistance. 

/$$$$$$$                                         /$$              /$$$$$$$$ /$$                     /$$       /$$$$$$$$           /$$   /$$            /$$$$$$                                  
| $$__  $$                                        |$/             | $$_____/|__/                    | $$      | $$_____/          |__/  | $$           /$$__  $$                                 
| $$  \ $$  /$$$$$$  /$$   /$$ /$$$$$$$   /$$$$$$ _//$$$$$$$      | $$       /$$ /$$$$$$$   /$$$$$$ | $$      | $$       /$$   /$$ /$$ /$$$$$$        | $$  \__/  /$$$$$$$  /$$$$$$  /$$$$$$/$$$$
| $$$$$$$  /$$__  $$| $$  | $$| $$__  $$ /$$__  $$ /$$_____/      | $$$$$   | $$| $$__  $$ |____  $$| $$      | $$$$$   |  $$ /$$/| $$|_  $$_/        |  $$$$$$  /$$_____/ |____  $$| $$_  $$_  $$
| $$__  $$| $$  \__/| $$  | $$| $$  \ $$| $$  \ $$|  $$$$$$       | $$__/   | $$| $$  \ $$  /$$$$$$$| $$      | $$__/    \  $$$$/ | $$  | $$           \____  $$| $$        /$$$$$$$| $$ \ $$ \ $$
| $$  \ $$| $$      | $$  | $$| $$  | $$| $$  | $$ \____  $$      | $$      | $$| $$  | $$ /$$__  $$| $$      | $$        >$$  $$ | $$  | $$ /$$       /$$  \ $$| $$       /$$__  $$| $$ | $$ | $$
| $$$$$$$/| $$      |  $$$$$$/| $$  | $$|  $$$$$$/ /$$$$$$$/      | $$      | $$| $$  | $$|  $$$$$$$| $$      | $$$$$$$$ /$$/\  $$| $$  |  $$$$/      |  $$$$$$/|  $$$$$$$|  $$$$$$$| $$ | $$ | $$
|_______/ |__/       \______/ |__/  |__/ \______/ |_______/       |__/      |__/|__/  |__/ \_______/|__/      |________/|__/  \__/|__/   \___/         \______/  \_______/ \_______/|__/ |__/ |__/
                                                                                                                                                                                                 
                                                                                                                                                                                                 
                                                                                                                                                                                                 

  Donations of any amount are appreciated.
 <-Click on that to read Bruno's request.
charlie137
Full Member
***
Offline Offline

Activity: 980
Merit: 204


(ノಠ益ಠ)ノ


View Profile WWW
January 01, 2018, 11:54:21 AM
 #3412

AXE added Cool https://github.com/AXErunners/vanitygen-plus

/__      ___ (  /    
\\--`-'-|`---\\ |      AXErunners
 |' _/   ` __/ / 
 '._  W    ,--'     
    |_:_._/
Chris!
Legendary
*
Offline Offline

Activity: 1355
Merit: 1095



View Profile
January 01, 2018, 02:23:01 PM
 #3413

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.
Quote
How great is the interest in this?

interesting... I'm pretty sure there is big interest in them. did you fork samr's vanitygen or start from scratch?
though since bech32 addresses are not yet implemented by most wallet,
the interest in bech32 addresses would be somewhat lower than that for segwit 3xxx addresses
any stats on how many addresses/second your generator can do?

I am thrilled to see the interest in Bravo Charlie Addresses!  Spread the word, “Bravo Charlie One means money.”

I wrote it from “scratch”—well, not really.  At first, I simply glued together sipa’s reference bech32 code, Core’s secp256k1, luke-jr’s libbase58, and standard POSIX extended regular expressions.  Then due to build dependency problems on my airgap machine, I had to semi-rewrite it with OpenSSL secp256k1 and my own base58check encoder using OpenSSL bignums.  This was supposed to be what you might call an “little pastime project”, done on a whim.

To be absolutely clear, I do handle both Bech32 and P2SH-nested Segwit “3” addresses.  Right now, pattern-matching is done on either one or the other; that’s stupid.  I intend to change it to check the same trial key against different patterns for both, if the operator so desires.

The code is slow, partly because I do a real bruteforce search:  Read a new private key off /dev/urandom, try its corresponding public key, and throw it away if that doesn’t match.  I always somewhat distrusted vanity addresses; and this is the paranoid way to make them.  Partly also because I made no attempt to make it fast.  I will try to get you some useful benchmark numbers after I do some immediately planned improvements.  Moreover, although I paid careful attention to basic tests, I’ll want to test more and play with testnet coins before foisting my code on other people where a bug could lose Other People’s Money.

The precursor idea popped into my head when I observed that ChipMixer is still not using Segwit; thus, I had in the back of my mind to see how hard it would be to make bulk Segwit addresses on demand.  It’s trivial; and my code will churn out as many thousands of nested-P2SH or Bech32 addresses and matching private keys as you could want, lightning-fast.  (Of course, ordinary users should use an HD wallet!)  I was pushed to action when I hit a thread where somebody was criticizing the aesthetics of Bech32.  What better way to persuade that Bech32 is pretty, than to show off a sweet vanity address?  So, I whipped up my bulk address generator and tacked on a regex pattern loop function.

Note for Microsoft Windows users:  My vanity generator uses POSIX regular expressions and other standard Unix APIs; and I want to keep dependencies to a minimum, for my own usage.  Thus, I doubt there would ever be a version which could be compiled with MSVC.  But I think that mingw has regex support; so perhaps there may be hope.  I would not be able to test the resulting binaries myself; for I have no Windows in my home or office.  I may try to get this working, if I see signs of sufficient interest (viz., potential for tips).  I myself will build and test on FreeBSD and Linux, in that order.


May I ask why you wrote it from scratch? Why not just modify the code from vanitygen to change how it converts ECDSA keypair to address?

Sundry reasons:

  • I was scratching an itch.
  • I needed a bulk address generator anyway.
  • I wanted something small and light, with as few dependencies as practicable.
  • vanitygen is AGPL.  As an advocate of liberal licensing and best of all, the public domain, I will avoid contributing my time and effort to a project whose code I can’t borrow without virally infecting my own codebase; GPL is a one-way street, and worst of all is AGPL.
  • vanitygen appears to be abandonware, with accumulating pull requests and an otherwise-maintained fork which people don’t seem to be switching to.
  • I do not have the requisite cryptanalytic expertise for evaluating the safety of the EC trick which vanitygen uses for speedup.  This is not to criticize vanitygen specifically:  I have significant general misgivings about vanity addresses; and anything other than fully random key selection makes me uncomfortable.
  • I have no idea what it would take to make vanitygen use compressed public keys as mandatory for Segwit (one pull request is open since 2013, with a severe bug as noted in the comments), then add the other needed code for Segwit address generation.  (Aside:  Even if you were to desire to still use old-style addresses without the Segwit fee discount, use of uncompressed public keys is really throwing away your money on fees.)  Whereas I already know exactly how to create such an implementation myself—on a whim—which this was.
  • I have never used vanitygen.  I first looked at its codebase a few minutes ago, to inform myself for an intelligent reply to you.  I didn’t actively choose not to patch a program I’ve never used; I independently wanted something, so I wrote it, and that’s that.

I'm extremely interested but I'm sure this will be way over my head. I'm not a coder by any means but I've used Vanitygen to generate addresses in the past so I can get by if I know the basic commands to use. I'll be checking this out and using it if I'm able to!
timisis
Member
**
Offline Offline

Activity: 183
Merit: 10


View Profile
January 08, 2018, 11:40:51 PM
 #3414

Smart thinking!  A day or two ago, I whipped up a quickie Segwit address generator with a simple regex search.  It can produce both P2WPKH-nested-in-P2SH and Bech32 addresses.  It’s quite trivial; it lacks vanitygen’s features, and probably also falls short in performance.
Quote
How great is the interest in this?

me too!
sandaru
Member
**
Offline Offline

Activity: 266
Merit: 10


View Profile
January 09, 2018, 07:42:45 AM
 #3415

It is. I am running that bash script for a couple of days and.

Thanks a lot for this.At first I was unable to compile the source, but I found out which package to install for PCRE support

It's testing away now with 10,000 keypairs a second. Wow, this really could get me hooked on trying out OpenCL coding, if only I had the time...
exander77
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
January 11, 2018, 12:42:54 AM
 #3416

It is. I am running that bash script for a couple of days and.

Thanks a lot for this.At first I was unable to compile the source, but I found out which package to install for PCRE support

It's testing away now with 10,000 keypairs a second. Wow, this really could get me hooked on trying out OpenCL coding, if only I had the time...

10,000 per second?

On my Vega FE, I am generating 130,000,000 per second.
exander77
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
January 11, 2018, 12:59:35 AM
 #3417

I am experimenting with next generation vanity addresses (these are for DOGE):

Code:
DEH1PMK4H7F2V5TZ8ZP9AUMU96PS9HDpay
DNGF62J9CD2GNGTLATMVKTDSNLR9CXQcfg
DK76D5YAQXZJU4CT9KD1TVS7LF4HQF8rot
...

Basically I can generate address with constraints on the on other places than just prefix on GPU. I tried for example using only numbers and upper case letter in the front and then generate lowercase string like pay, cfg, rot above.

Anyone interested in address like that?

I can generate any symbol anywhere in the string fast, about 60,000,000 key pairs per second.

I can also implement various feature to vanitygen for a price if you need. I have been buried in the the sources for the last two months.

Donate:
BTC: 1F9sh84hdbmDd4M2xGL3cEhtgk2Aqhg5yf
LTC: LRnPtUYnkT9AdyvZyUEwCGC1uMnZeY3yyA
DOGE: DNWUygm2dqvzV2VjgHQ8igkLggD2WNQHEY
exander77
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
January 11, 2018, 01:19:31 AM
 #3418

Why are certain patters so much harder to find then other patterns?

I was looking for somebodies name with the -i option so non case sensitive.

It found last name first name in under a minute (guess I got really lucky) with a difficulty of 778316249440 which with 15Mkey/s would take 10 hours for a 50% chance.

Now I searched for the exact name but with first name last name and that gave a difficulty of 23349487483220 which would take 13 days for a 50% chance.

Why is this?

Is there also a reason why people are only looking for patterns in the beginning of the adress?

I probably don't understand all the ins and outs yet but basically the program starts with some randomness to create usefull privatekeys and then just generates millions of keys just looking for some key to fly by that resolved to a public address that has the pattern we are looking for.

If that is true then why can't I search with oclvanitygen for patterns anywhere in the address, not just in the beginning.

Or am I missing something here?



 Use vanitygen with the -r (regex) option and you can search for patterns anywhere in the address.  Be aware that this is much slower than using oclvanitygen though.  Also, the program doesn't check for the validity of your search so you could be searching for something that doesn't exist as a Bitcoin address if you aren't careful.

for example,
vanitygen -r 0f
(that's a zero by the way) will cause the program to search forever because zero is not a valid base58 character.

I am in a process of implementing arbitrary matching using GPU, it is not exactly a regexp (which I think is not good for this kind of problem), but I can define the pattern in the following way currently:

[position][exact|range|lower|upper|number|letter|lower&number|upper&number][value1][value2]...

Where position is from 0...n from the start of the address and -1, -2...-n from the end of the address.

I can also code arbitrary function for special cases.

The speed is probably the half of standard oclvanitygen (130Mh/s vs 60Mh/s), meaning much faster than on CPU.

Donate is appreciated.

Donate:
BTC: 1F9sh84hdbmDd4M2xGL3cEhtgk2Aqhg5yf
LTC: LRnPtUYnkT9AdyvZyUEwCGC1uMnZeY3yyA
DOGE: DNWUygm2dqvzV2VjgHQ8igkLggD2WNQHEY
Amiri
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
January 11, 2018, 11:34:25 AM
 #3419

hi all
I want to search for an address that I believe its in between 2 specific hex.
How can i search for this address with this conditions this program?
exander77
Newbie
*
Offline Offline

Activity: 32
Merit: 0


View Profile
January 11, 2018, 03:37:29 PM
 #3420

hi all
I want to search for an address that I believe its in between 2 specific hex.
How can i search for this address with this conditions this program?

Can you elaborate, address is Base 58, not hex. Do you mean raw RIPEMD160 result?
Pages: « 1 ... 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 [171] 172 173 174 175 176 177 178 179 180 181 182 183 184 185 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!