Bitcoin Forum
December 05, 2016, 02:53:17 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 808580 times)
salfter
Hero Member
*****
Offline Offline

Activity: 550


My PGP Key: 92C7689C


View Profile WWW
October 02, 2012, 05:33:11 PM
 #741

Can't get the ocl version to work...

on 7970:
(seems it is finding matches, but disregarding due to mismatch?
Code:
CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891
GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6
Found delta: 94027 Start delta: 1

I had the same thing happen with my 7750.  IIRC, I got it working by passing the -S (safe mode) option to oclvanitygen.

My Bitgem Pool - PPLNS, Stratum | Gridseed Miners - $25 off your first order | BTG Explorer
Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR BTG gTipsVB9qmyYHuqMMKTuCYMHpfkUFBXKrZ | My Bitcoin Note Generator | Pyramining: 1 2 3 4 5
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480949597
Hero Member
*
Offline Offline

Posts: 1480949597

View Profile Personal Message (Offline)

Ignore
1480949597
Reply with quote  #2

1480949597
Report to moderator
1480949597
Hero Member
*
Offline Offline

Posts: 1480949597

View Profile Personal Message (Offline)

Ignore
1480949597
Reply with quote  #2

1480949597
Report to moderator
1480949597
Hero Member
*
Offline Offline

Posts: 1480949597

View Profile Personal Message (Offline)

Ignore
1480949597
Reply with quote  #2

1480949597
Report to moderator
Dabs
Staff
Legendary
*
Offline Offline

Activity: 1512


64blocks.com


View Profile WWW
October 03, 2012, 05:17:03 AM
 #742

Mr Vanitygen author, can you make a version that spits out compressed private keys, or the keys that begin with letters instead of 5?

64blocks.com Social Multiplayer Dice (Gambling) - Escrow Service (Services) - GPG ID: 32AD7565, OTC ID: Dabs
All messages concerning escrow or with bitcoin addresses are GPG signed. Please verify.
CompTIA A+, Microsoft Certified Professional, MCSA: Windows 10; Windows Server 2012, MCSE: Cloud Platform and Infrastructure; Productivity; Messaging
flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 03, 2012, 08:00:18 PM
 #743

Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?

(*) What about addresses associated with compressed keys?

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
BurtW
Legendary
*
Offline Offline

Activity: 1778

All paid signature campaigns should be banned.


View Profile WWW
October 03, 2012, 08:58:14 PM
 #744

Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?

(*) What about addresses associated with compressed keys?

What I understand it does:

1) Generate a random private key (or increment from the previous random private key)
2) Calculate the corresponding public key from the private key
3) Calculate the corresponding bitcoin address of the public key
4) Compare, if there is a match output else go back to step 1)

Does that help to answer your question or not?

Our family was terrorized by Homeland Security.  Read all about it here:  http://www.jmwagner.com/ and http://www.burtw.com/  Any donations to help us recover from the $300,000 in legal fees and forced donations to the Federal Asset Forfeiture slush fund are greatly appreciated!
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
October 04, 2012, 09:03:33 PM
 #745

Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?

(*) What about addresses associated with compressed keys?

The starting point of a phrase search is random, it gets a private key from the openssl rand ecdsa library and starts searching from there, simply incrementing the key. After searching many addresses for a phrase match, it will again get another random private key. The keys searched and returned with a found vanity phrase in the corresponding Bitcoin address can be from anywhere in the range of valid keys, but certainly it cannot "search the entire keyspace", as that would take somewhere just north of the age of the universe.

flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 04, 2012, 10:01:17 PM
 #746

Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?

(*) What about addresses associated with compressed keys?

The starting point of a phrase search is random, it gets a private key from the openssl rand ecdsa library and starts searching from there, simply incrementing the key. After searching many addresses for a phrase match, it will again get another random private key. The keys searched and returned with a found vanity phrase in the corresponding Bitcoin address can be from anywhere in the range of valid keys, but certainly it cannot "search the entire keyspace", as that would take somewhere just north of the age of the universe.

Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
October 04, 2012, 11:31:56 PM
 #747


Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

It picks random starting points within the 256 bit private key space and increments from there.  So yes it considers the entire 256 bit space.

You are in a maze of twisty little passages, all alike.
flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 05, 2012, 07:04:28 AM
 #748


Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

It picks random starting points within the 256 bit private key space and increments from there.  So yes it considers the entire 256 bit space.

Sorry to insist, but are you sure? How do compressed private keys (introduced in bitcoind/bitcoin-qt 0.6.0) fit in there? From what I've been able to read, vanitygen doesn't support them and they are actually separate from noncompressed keys (ie, can't be expressed as normal uncompressed base58 keys) - so what proportion of the 2^256 search range do they represent? Or am I totally misunderstanding compressed keys?

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
stevegee58
Hero Member
*****
Offline Offline

Activity: 783



View Profile
October 05, 2012, 10:18:57 AM
 #749

Well then I guess I have no idea.  I'm a C++ guy in my day job but I haven't looked into the fine details of the BTC algos.

OP hasn't posted for over a month so I'm not sure he's around anymore.

You are in a maze of twisty little passages, all alike.
flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 05, 2012, 10:59:36 AM
 #750

Nvm, it was actually just a misunderstanding on my part.

EDIT: wasn't easy, but I found the answer I was looking for here:
 http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
malevolent
can into space
Staff
Legendary
*
Offline Offline

Activity: 1624



View Profile
October 05, 2012, 02:43:57 PM
 #751

Well then I guess I have no idea.  I'm a C++ guy in my day job but I haven't looked into the fine details of the BTC algos.

OP hasn't posted for over a month so I'm not sure he's around anymore.

He didn't post from August 2011 till July 2012, he has a life I guess, but I'm sure he hasn't abandoned his useful project.
nibor
Sr. Member
****
Offline Offline

Activity: 348


View Profile
October 07, 2012, 10:45:22 AM
 #752

samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.

I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.

Hi BkkCoins,

Difficulty is the number of keys that have to be checked, on average, to find a match.

The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58.  For this, you'd have something like:

11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353

So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties.  This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.


The exact, but more complicated way to do this is to follow the formula:

Difficulty = (Total addresses) / (Matching addresses)

The tricky part is figuring out the number of matching addresses.  If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:

Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys

It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches.  If you're interested, I will post more about this.

samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
October 07, 2012, 10:53:44 AM
 #753

samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.

I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.

Hi BkkCoins,

Difficulty is the number of keys that have to be checked, on average, to find a match.

The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58.  For this, you'd have something like:

11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353

So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties.  This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.


The exact, but more complicated way to do this is to follow the formula:

Difficulty = (Total addresses) / (Matching addresses)

The tricky part is figuring out the number of matching addresses.  If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:

Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys

It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches.  If you're interested, I will post more about this.
How did you come up with this algorithm?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 08, 2012, 05:45:30 PM
 #754

@samr7:

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

Or am I just saying nonsense again?

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
October 10, 2012, 08:38:48 PM
 #755

Are you talking about the vanity miner or vanitygen?

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
October 12, 2012, 06:01:01 AM
 #756

Can't get the ocl version to work...

On nvidia:

Code:
vg_ocl_context_callback error: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_NDRANGE_KERNEL on GeForce GTX 285 (Device 0).

clWaitForEvents(NDRange,0): CL_MEM_OBJECT_ALLOCATION_FAILURE
Device: GeForce GTX 285
Vendor: NVIDIA Corporation (10de)
Driver: 285.62
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 30
Max workgroup size: 512
Global memory: 1073741824
Max allocation: 268435456

Hi tgbtc,

Try upgrading your NVIDIA driver.  That version looks kinda old.  Your GTX 285 card should work without question though.

Quote
on 7970:
(seems it is finding matches, but disregarding due to mismatch?
Code:
CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891
GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6
Found delta: 94027 Start delta: 1

When you get the CPU hash/GPU hash mismatch, it means the OpenCL device is producing incorrect results.  I have not had a chance to test it on an AMD 7XXX series GCN card yet, but others have reported that it works.  Try running it with -V on that card for a little while and see what you get.  Since it's producing incorrect results, the performance numbers may or may not mean anything.

Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

Hi flatfly,

Vanitygen won't systematically search the entire keyspace.  It picks a random spot, checks a few hundred million keys, and moves to another random spot.  I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.

It also uses a different random spot for each thread or OpenCL device that's being used to search.

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

I still have to read about compressed keys, but you're probably correct about this, yes!

BTW kudos on deep space vagabond!  I love it.
samr7
Full Member
***
Offline Offline

Activity: 140

Firstbits: 1samr7


View Profile
October 12, 2012, 06:20:39 AM
 #757

samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?

Hi nibor,

What are you trying to do?

To give a base-58 example of how to determine difficulty, let's say you want the prefix 1Boat.  The idea is that when you compute the address of a private key, it is almost completely random and unpredictable, and we consider it to have equal probability of being any possible address.  So, for the prefix 1Boat, any addresses in the following range would work:

1Boat11111111111111111111111111111 - 1Boatzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Not all of these are valid addresses due to the checksum part at the very end, but we'll gloss over that.

All you have to do is figure out how many addresses are in that range, call it (matching addresses), and then compute:

difficulty = (total addresses, 2^192) / (matching addresses)

That's the average number of addresses you'll have to test before finding a match.

It gets a little bit more complicated because above we're only considering 34 character addresses, and it's possible to have shorter addresses with the same prefix, addresses that are 33 characters or shorter.  In fact, to get a prefix beginning with 1R - 1z, it is only possible using a 33 character address, and this is why those prefixes are so difficult.
BkkCoins
Hero Member
*****
Offline Offline

Activity: 784


firstbits:1MinerQ


View Profile WWW
October 12, 2012, 06:48:13 AM
 #758

If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.

I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.

flatfly
Hero Member
*****
Offline Offline

Activity: 938


View Profile
October 14, 2012, 11:29:40 AM
 #759


Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

Hi flatfly,

Vanitygen won't systematically search the entire keyspace.  It picks a random spot, checks a few hundred million keys, and moves to another random spot.  I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.

It also uses a different random spot for each thread or OpenCL device that's being used to search.

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

I still have to read about compressed keys, but you're probably correct about this, yes!

BTW kudos on deep space vagabond!  I love it.

Thanks for your answers and glad you liked DSV Smiley

1111127SpvabYpoeDoiz5L7QPkfiSh2Q. Only donate if you have a reason to.
nibor
Sr. Member
****
Offline Offline

Activity: 348


View Profile
October 16, 2012, 10:31:26 PM
 #760


New site looking for beta testers:
https://bitcoinvanity.appspot.com

Allows the average non-technical user create free, secure (site does not know the private key) vanity addresses.
Currently in Beta, so might take a while to generate addresses but that should speed up soon.
Give it a go and PM me with any issues.

Please do not post replies on this thread - I will open a fresh one in services once out of Beta and with some more power behind it in terms of GPUs.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 ... 155 »
  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!