In order to prevent 0 from being the answer, you have to first subtract 1 from result before modding, then mod, and then add 1. Then your range will be from 1 to N, rather than from 0 to N-1.

The multiplication method is quite easy - instead of using the base point G (04 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8), you just use the public key provided by the other person. Then you generate the address like normal (without any adding). To obtain the proper private key to be used with Bitcoin, one needs to multiply the two private keys. This method is also available in my testing suite.

As for StackExchange, you just need an OpenID and you can log in without any problem.

Thx. I used your test page to verify my method and it works the same. But what I found after plugging results into bitaddress.org and comparing with keyconv is that I do not add a 00h byte after the sum and before converting to WIF. This seems to cause a problem as the base 58 conversion goes awry producing a bad key.

[edit:]Solved! The "getExportedPrivateKey" member of the ECKey class in the BitcoinJS library has a bug. It does not check and pad the byte array to 32 bytes before adding 0x80 and checksum. Incidentally bitaddress.org is using a different version of BitcoinJS that has a "getBitcoinPrivateKeyByteArray" member instead that is fixed. My version of BitcoinJS was pulled from github just a few days ago.

Not yet. We would need some special programming done for them, and I'm guessing that would be a lot more work than creating split-key vanity generator from Vanitygen. You ought to ask the people that created your normal mining software if they could look into creating one for vanity mining.

I was going to try this with a new address that I created on bitcoin-qt. I obtained the address by using validateaddress, which gives a public key.This public key is compressed, and the web page rejects it.I asked in #bitcoin-dev how to get a non-compressed address, and they said:

Code:

[19:10] <ProfMac> can I get the public key of a new address locally, using bitcoin-qt[19:11] <@gmaxwell> ProfMac: open the console, run validateaddress on it.[19:19] <ProfMac> gmaxwell: thanks, that worked.[19:40] <ProfMac> I submitted the public key to https://vanitypool.appspot.com/newWork and it complains that it is compressed.[19:42] <@gmaxwell> ProfMac: tell the vanitypool people to fix their crap. Generating vanity addresses w/ compressed keys is _faster_ than uncompressed.[19:43] <ProfMac> lol. I will.

The compressed public key in question is:0208c65179b9375c1cffee6f6c0e865a814ef1cb736dcc464ef3c54e6d9991d92f

I was going to try this with a new address that I created on bitcoin-qt. I obtained the address by using validateaddress, which gives a public key.This public key is compressed, and the web page rejects it.I asked in #bitcoin-dev how to get a non-compressed address, and they said:

Code:

[19:10] <ProfMac> can I get the public key of a new address locally, using bitcoin-qt[19:11] <@gmaxwell> ProfMac: open the console, run validateaddress on it.[19:19] <ProfMac> gmaxwell: thanks, that worked.[19:40] <ProfMac> I submitted the public key to https://vanitypool.appspot.com/newWork and it complains that it is compressed.[19:42] <@gmaxwell> ProfMac: tell the vanitypool people to fix their crap. Generating vanity addresses w/ compressed keys is _faster_ than uncompressed.[19:43] <ProfMac> lol. I will.

The compressed public key in question is:0208c65179b9375c1cffee6f6c0e865a814ef1cb736dcc464ef3c54e6d9991d92f

I was going to try this with a new address that I created on bitcoin-qt. I obtained the address by using validateaddress, which gives a public key.This public key is compressed, and the web page rejects it.I asked in #bitcoin-dev how to get a non-compressed address, and they said:

Code:

[19:10] <ProfMac> can I get the public key of a new address locally, using bitcoin-qt[19:11] <@gmaxwell> ProfMac: open the console, run validateaddress on it.[19:19] <ProfMac> gmaxwell: thanks, that worked.[19:40] <ProfMac> I submitted the public key to https://vanitypool.appspot.com/newWork and it complains that it is compressed.[19:42] <@gmaxwell> ProfMac: tell the vanitypool people to fix their crap. Generating vanity addresses w/ compressed keys is _faster_ than uncompressed.[19:43] <ProfMac> lol. I will.

The compressed public key in question is:0208c65179b9375c1cffee6f6c0e865a814ef1cb736dcc464ef3c54e6d9991d92f

At the moment almost everyone in the Bitcoin world uses uncompressed keys - they are default for importing into blockchain.info as far as I remember for example. I am not sure whether it is possible to mine for vanity addresses using compressed keys (probably is but I would need to make sure with samr7). Also, I don't know of any vanity address calculator that uses compressed keys. I would advise you to generate a new public-private keypair using www.bitaddress.org or gobittest.appspot.com and use that, as you would probably need to use one of those sites to combine the keys anywhere.

Hi, so I just started doing the vanity mining. The program started up find and pulled available work and displayed:"Searching for pattern: "1Aurareus" Reward: 0.096000 Value: 0.000002 BTC/GkeyDifficulty: 50656515217834

Total value for current work: 0.000002 BTC/Gkey"

So is it only checking the generated keys against the one pattern "1Aurareus", or is it checking for all available patterns. Assumingily, it would be more profitable to check all the available patterns to see if you randomly get it. Is that possible or is the splitkey thing not allowing it. Or am I way off here?

Hi, so I just started doing the vanity mining. The program started up find and pulled available work and displayed:"Searching for pattern: "1Aurareus" Reward: 0.096000 Value: 0.000002 BTC/GkeyDifficulty: 50656515217834

Total value for current work: 0.000002 BTC/Gkey"

So is it only checking the generated keys against the one pattern "1Aurareus", or is it checking for all available patterns. Assumingily, it would be more profitable to check all the available patterns to see if you randomly get it. Is that possible or is the splitkey thing not allowing it. Or am I way off here?

Thanks!

As far as I know the software checks for a certain amount of keys at a time to optimise performance. You should ask samr7, he is the programmer behind it.

Hi, so I just started doing the vanity mining. The program started up find and pulled available work and displayed:"Searching for pattern: "1Aurareus" Reward: 0.096000 Value: 0.000002 BTC/GkeyDifficulty: 50656515217834

Total value for current work: 0.000002 BTC/Gkey"

So is it only checking the generated keys against the one pattern "1Aurareus", or is it checking for all available patterns. Assumingily, it would be more profitable to check all the available patterns to see if you randomly get it. Is that possible or is the splitkey thing not allowing it. Or am I way off here?

Thanks!

This is from the script's help page (italics are mine):

Quote

Contacts the specified bounty pool server, downloads a list of active bounties, and attempts to generate the address with the best difficulty to reward ratio.

So unless there are two addresses for which this ratio is exactly the same you might be right; it would be better to check simultaneously then. If not it is better to focus on the most rewarding pattern.

The remaining in the queue are some of the more difficult addresses to find. I really wish we could get this site some more publicity so we can start to fill up the list with something that is more attainable.