I got it compiling finally, but I still can't figure out how to get it to print all address/privkey pairs it finds.
I've pretty much given up on the hope that I can enter any privkey and have it increment from there, as is appears the initial value for an ECPoint is a randomly generated BigNum in the openssl code which I'm not going to mess with. Also, it appears to generate a new random key to increment from either every 100,000,000 addresses it tries or if it finds a match, whichever comes first. I'd still like to be able to use the GPU to generate the 100 billion addresses, so if anyone really understands the code, any help would be appreciated.
MyCoin- I've got one word for you: IGNORE
Topic: bulk address creation (Read 807 times)
HOW ABOUT THIS ?
OCLvanitygen is fast because the addresses stay in the GPU (only a match is returned). It is also fast because a typical GPU has 1000 processing units. It would probably be even faster if you removed the final check to see if the generated address matches a pattern.
I imagine it wouldn't be much of a stretch after you get oclvanitygen compiling to remove the pattern-checking code in CL and return all addresses; how fast the C wrapper could deal with such a stream of data would then be the issue. The generated addresses would not be secure and random though; the private keys would be *VERY* related to each other - oclvanitygen just increments from an initial random value. To generate good addresses for actual use (not just some impossiburu hacking project), you need a true random source with a fast data stream - the ECDSA will not be the speed limiting factor.
I imagine it wouldn't be much of a stretch after you get oclvanitygen compiling to remove the pattern-checking code in CL and return all addresses; how fast the C wrapper could deal with such a stream of data would then be the issue. The generated addresses would not be secure and random though; the private keys would be *VERY* related to each other - oclvanitygen just increments from an initial random value. To generate good addresses for actual use (not just some impossiburu hacking project), you need a true random source with a fast data stream - the ECDSA will not be the speed limiting factor.
It took some doing, but after a couple days of messing with things, I wrote a CPU x64 C# version that can output sequential private keys and their addresses (compressed and uncompressed) starting at any given index at a rate of about 25K/core/min (on my i7 3930K). It obviously uses EC addition instead of multiplication. However, even though this might sound decent, I wanted to generate approx 1 billion addresses (no, not as a hacking attempt- a billion is 8.6E-67% of the keyspace so don't worry), and I need my CPU for my day job. Running one instance of this (which is all the CPU power I can spend on it) would take nearly a month (24/7) to generate the 1 billion addresses. My GPU is almost always free however, so if anyone knows how to edit the oclvanitygen code (I don't know much C++ and no opencl) such that:
- it can take any start index in the form of a hex private key
- it does not check against a pattern and instead spits out ALL of the addresses and private keys to file (or the screen and I'll redirect stdout) as it goes
- ensure that the incrementing of the private keys is 1, not some other number
I could use the tips (also how to compile for Win 7 x64). Thanks for all the helpful replies.
OCLvanitygen is fast because the addresses stay in the GPU (only a match is returned). It is also fast because a typical GPU has 1000 processing units. It would probably be even faster if you removed the final check to see if the generated address matches a pattern.
I imagine it wouldn't be much of a stretch after you get oclvanitygen compiling to remove the pattern-checking code in CL and return all addresses; how fast the C wrapper could deal with such a stream of data would then be the issue. The generated addresses would not be secure and random though; the private keys would be *VERY* related to each other - oclvanitygen just increments from an initial random value. To generate good addresses for actual use (not just some impossiburu hacking project), you need a true random source with a fast data stream - the ECDSA will not be the speed limiting factor.
I imagine it wouldn't be much of a stretch after you get oclvanitygen compiling to remove the pattern-checking code in CL and return all addresses; how fast the C wrapper could deal with such a stream of data would then be the issue. The generated addresses would not be secure and random though; the private keys would be *VERY* related to each other - oclvanitygen just increments from an initial random value. To generate good addresses for actual use (not just some impossiburu hacking project), you need a true random source with a fast data stream - the ECDSA will not be the speed limiting factor.
How fast do you need them? I used sx newkey and it generated 1000 random private keys in 46.9 seconds on one core. It looks like generating from a seed takes 148.5 seconds, almost 3x.
Pick a random number, privkey0. Multiply G by privkey0, result is pubkey0.
Now, pubkeyi=pubkeyi-1+G and privkeyi=privkey0+i.
So, just keep incrementing privkey and adding G to pubkey until you have as many pairs as you need.
Note that this is much less secure than actually pulling random privkeys. It is fine in vanitygen because most of the pairs are discarded.
Now, pubkeyi=pubkeyi-1+G and privkeyi=privkey0+i.
So, just keep incrementing privkey and adding G to pubkey until you have as many pairs as you need.
Note that this is much less secure than actually pulling random privkeys. It is fine in vanitygen because most of the pairs are discarded.
No one? I'd try to contact samr7 about vanitygen, but he hasn't been on this forum since Dec 2012.
If I search for say "1Random*" with oclvanitygen, my GTX 570 gets about 25MKey/s. I assume that it is actually generating 25 million private keys per second, running them through ECDSA and the hashes, and discarding them if the final address doesn't match, right? Then why when I request that it search for "1*" it only runs at 11MKey/s and find only a couple hundred per minute? The CPU can find thousands per minute. Is there any way to use the GPU to actually go faster than the CPU for generating random addresses?
I remember seeing on another thread that OCLvanitygen uses elliptic curve addition instead of multiplication and that's why it's faster in general. Could someone explain the difference? Could I use addition instead of multiplication with the C# Bouncycastle crypto suite (because that is SLOOOOW)?
This is my code for running the private key (plus network byte) through ECDSA
Is there any way to speed that up?
I remember seeing on another thread that OCLvanitygen uses elliptic curve addition instead of multiplication and that's why it's faster in general. Could someone explain the difference? Could I use addition instead of multiplication with the C# Bouncycastle crypto suite (because that is SLOOOOW)?
This is my code for running the private key (plus network byte) through ECDSA
Code:
var ps = Org.BouncyCastle.Asn1.Sec.SecNamedCurves.GetByName("secp256k1");
Org.BouncyCastle.Math.BigInteger Db = new Org.BouncyCastle.Math.BigInteger(privkeyNB);
ECPoint dd = ps.G.Multiply(Db);
byte[] pubkey = new byte[65];
byte[] Y = dd.Y.ToBigInteger().ToByteArray();
Array.Copy(Y, 0, pubkey, 64 - Y.Length + 1, Y.Length);
byte[] X = dd.X.ToBigInteger().ToByteArray();
Array.Copy(X, 0, pubkey, 32 - X.Length + 1, X.Length);
pubkey[0] = 0x04;
//hashes, etc...
Is there any way to speed that up?
Jump to: