Author

Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 187. (Read 1153620 times)

sr. member
Activity: 288
Merit: 263
Firstbits.com/1davux
Can I make a feature request.
That it saves the info to a txt file when it finds a prefix but it keeps trying for other combination.

Or just output the keys on standard output like it already does, and keeps searching.

A kind of --forever or --continue flag, in a way.

(Personal note: while it may be useful, I won't miss such a feature if it's not implemented, because while and for loop are easy to write in a shell, and the behaviour would be exactly the same, since the program doesn't store already tried combinations.)
legendary
Activity: 882
Merit: 1001
Found my username Smiley
My computer said it would take 7 years to find your username? Would you be interested in finding a couple vanity addresses for me?
hero member
Activity: 714
Merit: 504
^SEM img of Si wafer edge, scanned 2012-3-12.
Just needs GPU support then it will be real useful.
Managed to add 1 address iv made to a wallet in virtual machine session.

So now to create 1bmgjet.............. which will take forever on cpu.
I'm working on a generator with GPU support.
hero member
Activity: 518
Merit: 500
Found my username Smiley
full member
Activity: 140
Merit: 100
BitVapes.com
Can I make a feature request.
That it saves the info to a txt file when it finds a prefix but it keeps trying for other combination.

nice idea.  if you can't wait, it shouldn't be too hard to accomplish this is a bash script
member
Activity: 98
Merit: 10
Can I make a feature request.
That it saves the info to a txt file when it finds a prefix but it keeps trying for other combination.
hero member
Activity: 695
Merit: 502
PGP: 6EBEBCE1E0507C38
made a new addy the other day and got this, with the mac gui bitcoin app.

1AnySU1zf9s468pa8oe1kGtyaC1Rfa56aU

I'll get a vanity name sometime.
sr. member
Activity: 252
Merit: 250
From your code, I think you pick a random number and an EC-product in each iteration.

I sure hope not!  Where are you seeing this in the code?  Any specific function/line?

Quote

Uhmm.... I think I saw it in the first versions in the first lines of the loop, when you wrote the program between "code" labels.

Going to "github" for re-reading the code.
full member
Activity: 140
Merit: 100
BitVapes.com
30 years for a 50% chance at finding a bitcoin address beginning with '1BitVapes'  Sad

less than 200 days for case-insensitive though, nice

what kind of percentage speed increase would doing this via GPU provide?  the best cpu's get about what, 30 mhash/sec on cpu bitcoin mining, and 800ish for the best gpu?  I guess it would be about the same increase for finding a vanity address.  So lets see, 30 years becomes roughly less than 1 year on a gpu?
member
Activity: 98
Merit: 10
Just needs GPU support then it will be real useful.
Managed to add 1 address iv made to a wallet in virtual machine session.

So now to create 1bmgjet.............. which will take forever on cpu.
hero member
Activity: 518
Merit: 500
I'm getting good at this bug finding. I'm impressed by how fast you respond.

I'm having fun making addresses. Can't wait until importing becomes easier and I can use them for spending, not just saving envelopes.
full member
Activity: 140
Merit: 430
Firstbits: 1samr7
When I search with a text file input with multiple prefixes, the next match difficulty after each match is found stays the same. I would have expected this to increase, as it is searching for fewer prefixes and it will generally find the easy ones first, thus increasing the difficulty as it proceeds.

Am I missing something or is this a bug?

Nope, it's definitely a bug!

New version 0.8 is up.
hero member
Activity: 518
Merit: 500
When I search with a text file input with multiple prefixes, the next match difficulty after each match is found stays the same. I would have expected this to increase, as it is searching for fewer prefixes and it will generally find the easy ones first, thus increasing the difficulty as it proceeds.

Am I missing something or is this a bug?
full member
Activity: 140
Merit: 430
Firstbits: 1samr7
From your code, I think you pick a random number and an EC-product in each iteration.

I sure hope not!  Where are you seeing this in the code?  Any specific function/line?

Quote
Anyway you can simply implement the option adding external entropy source. Say, "-E file" where "file" is some file the user provides. Then, the program reads up to, say, 64 bytes from file, concatenates these data to your local random data and hash it all together. If the option is not used, only local entropy is gathered and used.

User is responsible about what she provides as "file".

Alright, an external file source would be ridiculously easy to add.
sr. member
Activity: 252
Merit: 250
So, the biggest improve is, that heavy EC-product is computed only twice!!! New test address is taken from single EC-add operation which is relatively cheap in compute resources.

Indeed, performing one EC_POINT_add() instead of an EC_POINT_mul() per iteration saves a lot of time, and improves the search rate by about a factor of four.  It would be a lot more than four if there were a faster way to convert the public key to hashable form.  Anyway, this is exactly how vanitygen works now.

Really!?

From your code, I think you pick a random number and an EC-product in each iteration.

Network random number seeding is an extreme security feature.  I'm not against adding it, but it wouldn't be trivial to implement, and I question whether any actual user will care enough to turn it on.  So prove me wrong.

You mean: if a guy in random.org knows what and why I'm picking, then he can clone my random data and reproduce the process to take my private key. Yes, you are right. This is why I propose TWO different network sources, and one of these is made through secure server. So, if someone snuffs the modem, she won't able to deal with the data. Moreover, local entropy is added in my proposal.

Anyway you can simply implement the option adding external entropy source. Say, "-E file" where "file" is some file the user provides. Then, the program reads up to, say, 64 bytes from file, concatenates these data to your local random data and hash it all together. If the option is not used, only local entropy is gathered and used.

User is responsible about what she provides as "file".

Shouldn't that be

Code:
s = SHA256(E1 ^ E2 ^ E3) mod p

where ^ is bitwise xor?

I think Shevek was using the cryptographer's |, which means concatenation.  Not the C/C++ |.

Sure!  Grin
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better
Shouldn't that be

Code:
s = SHA256(E1 ^ E2 ^ E3) mod p

where ^ is bitwise xor?

I think Shevek was using the cryptographer's |, which means concatenation.  Not the C/C++ |.

Oh!  Makes sense, that.  Thanks!

Cheers,
full member
Activity: 140
Merit: 430
Firstbits: 1samr7
So, the biggest improve is, that heavy EC-product is computed only twice!!! New test address is taken from single EC-add operation which is relatively cheap in compute resources.

Indeed, performing one EC_POINT_add() instead of an EC_POINT_mul() per iteration saves a lot of time, and improves the search rate by about a factor of four.  It would be a lot more than four if there were a faster way to convert the public key to hashable form.  Anyway, this is exactly how vanitygen works now.

Network random number seeding is an extreme security feature.  I'm not against adding it, but it wouldn't be trivial to implement, and I question whether any actual user will care enough to turn it on.  So prove me wrong.

Shouldn't that be

Code:
s = SHA256(E1 ^ E2 ^ E3) mod p

where ^ is bitwise xor?

I think Shevek was using the cryptographer's |, which means concatenation.  Not the C/C++ |.
hero member
Activity: 566
Merit: 500
Unselfish actions pay back better

Finally, obtain the seed number, "s":
Code:
s = SHA256(E1 | E2 | E3) mod p

Shouldn't that be

Code:
s = SHA256(E1 ^ E2 ^ E3) mod p

where ^ is bitwise xor?

Cheers,
hero member
Activity: 518
Merit: 500
Thanks. Working away on my address now.
sr. member
Activity: 252
Merit: 250
samr7, please read the following. I have a honest proposal for pulling your code with more security and... speed!

First, I suppose you are familiar with openssl-API. I'm not (otherwise, I'd rewrite the code myself), but after some revision of your program I've found points of improvement. On the other hand, elliptic curve mathematics are familiar to me ;-) So, this is my proposal.

1) Get a good 256-bit random number. It will act as a seed. You can obtain it from three sources.

E1 = 32 bytes from random.org. Here it is a sample code that dumps the result in a file; I suppose you can adapt it:

Code:
wget "http://www.random.org/cgi-bin/randbyte?nbytes=32&format=file" -O - > E1

E2 = 32 random bytes from hotbis. Sample code:

Code:
wget "https://www.fourmilab.ch/cgi-bin/Hotbits?nbytes=32&fmt=%20bin" -O E2

E3 = 32 random bytes from local sources. For example, /dev/urandom, but you can use other not so quality sources.

Finally, obtain the seed number, "s":
Code:
s = SHA256(E1 | E2 | E3) mod p

where "p" is the prime order of the curve (I suppose you can take it, and perform this operation, from openssl-API)

2) Get the first public address

The public key is calculated with EC-product:

Code:
 PubKey = s*Q 

where "Q" is the fixed point in the curve. Now address is:

Code:
PubAdd = base58(RIPEMD160(SHA256(PubKey))+checksum)

or similar, isn't it?

3) Start the loop

Code:
Loop start:
    If pattern matchs "PubAdd", then go end
    Else do:
        PubKey <- PubKey + Q (EC-Add operation)
        s <- (s + 1) mod p
        PubAdd = base58(RIPEMD160(SHA256(R))+checksum)
    Endif
 Loop end
 P' = s*Q (EC-product)
 if (P' == PubKey)
     PrivKey = base58(s+checksum)
     print PubAdd, PubKey, PrivKey
 else
     something went bad
 endif
 

So, the biggest improve is, that heavy EC-product is computed only twice!!! New test address is taken from single EC-add operation which is relatively cheap in compute resources.

But you must be sure that 256 initial seed is really random.

What's your opinion?
   
Jump to: