Topic: Vanity Pool - vanity address generator pool - page 20. (Read 148044 times)

Also when the private keys are tested at https://www.bitaddress.org (Wallet details, enter private key in any format) & it says: ' The text you entered is not a valid Private Key! '

Nope, I've never used WIF, I just made the WIF now & that doesn't work either, blockchain.info wallets accept the straight private keys as summed but for for these 2 vanities the private keys given seem to be invalid.

As for /PrivateKey , I see a lot of errors originating around "generateFromWIF" function. Are you sure you weren't putting the private key in as WIF? The private key -> WIF conversion is in the middle of the page, under bold "Private key to wallet import format".

http://gobittest.appspot.com/VanitySum gave me the sum of private keys that is being reported as invalid

& http://gobittest.appspot.com/PrivateKey gives:    Invalid Base58 encoding

but http://gobittest.appspot.com/Address gives the correct address as derived from the private key: 1Knicks1bujdxrXTaZbf8YLzU8rh8Pbq5G

Well, you can always try http://gobittest.appspot.com/

All the other ones have imported fine np, also I checked the private keys somewhere where you can generate the matching address & it also said that they were invalid keys.

Edit: It was at https://www.bitaddress.org (Wallet details, enter private key in any format) & it says: ' The text you entered is not a valid Private Key! '

Hmm, maybe the blockchain.info uses WIF, rather than just plain copying and pasting of private keys?

I'm assuming that when ASICs are prevalent & difficulty goes through the roof that will make vanity mining a much more attractive alternative & so clear up a lot of the old requests, btw a couple of mine were solved a while back but recently when I came to import the private keys in to my blockchain.info wallet I had 'error importing private key - unknown key format' this was for addresses:

11976WATj2ujAvg7booAr4STNH5DUBFRZ - 2012/11/13

1Knicks1bujdxrXTaZbf8YLzU8rh8Pbq5G - 2012/10/29

The vanity sum correctly generated the addresses but seems to give an incorrect sum of private keys, unless it's a wallet error but I think that I checked them somewhere else & got the same error message. I've checked that my copy & paste of it was exact & no spaces before or after, it's not already in the wallet either.

From how I understand it, you can easily mine several addresses at once, think merged mining, when the "task" was created from the same private key.
If I ask for 10 vanity addresses, and create those 10 tasks so that they all are made from the same seed, someone can work at all 10 at once.
If 10 people each want one address they surely won't create the tasks from the same seed/key. So a vanity miner will have to mine an hour for the first guy, then an hour for the next, and can only find an address/solution for the current task.

That 2.78 assumes that you mine at *all* tasks available at once, which is unrealistic at least, and suggestive/dishonest at worst.

So, currently, I think, there are several miner out there which check periodically on the available work. Once a task or combination of tasks appear which is more profitable than regular mining, they point their miners there. Which means a lot of the current tasks may stay there waiting for a long time..

Lets see if a marketrate with more realistic prices establishes!

Ente

That ratio is a bit idealised and assumes you are mining all the addresses at the same time (additive rather than multiplicative address generation). From what I understand, samr7's miner just uses a few of the most profitable addresses and that's it.

Good point, then just pay each miner bounty * (their_shares / total_shares).


How is this?  The pool gives a mining ratio that is supposed to represent how many more times profitable it is to mine vanity addresses than bitcoins, and it's currently 2.78.  I can see how the variability of this would be higher than a PPS or geometric method pool, but over long periods it should still pay better, right?


No problem, and thanks for what you have done.

Definitely possible!
Yes, just how you say - almost the same as regular mining pools.
However, people don't "work toward" solving a block or finding an address, it is strictly random. It's getting more probable to find a solution the longer you or the pool works on it, but only because more tries were done. Every single hash-generation has the same chance to find the jackpot, no matter if it is the third try or a try after a billion.
So, in short: don't pay out until the address was actually found. And then you know exactly how many shares everyone submitted.

Also, vanitymining rarely pays in the range of direct bitcoin mining. Until that is "solved", there isn't much going on here.. ;-)
Still, I am fascinated by all this.

Ente

Well, it's all possible, but with the project being so small I just can't bring myself to commit too much time to it at the moment.

I've been kicking around the idea of applying shares to this pool.  One thing that comes to mind is how with standard pooled mining, a share is the same type of proof of work but of lesser difficulty.  Maybe a "share" for vanity mining would be an address whose first N bytes match the desired prefix (the value of N might vary depending on the difficulty of the vanity address.)  These could be submitted as proof of doing work, and by seeing how fast they're coming from clients an estimation of hashing speed could be made.  This seems like it might be useful to clients wondering if they're going to get their money's worth out of the pool, or if they'd be better off generating it themselves.

You might even be able to pay-per-share, too.  I don't know how the math would work but it seems like you should be able to divide the vanity reward up among shares so that there's a high probability that by the time the reward has been completely paid out, a matching address has been found.  Maybe be extra-conservative with the share payments and the person who finds the address gets the remainder of the reward as a bonus.  I suppose the share value could get very small, perhaps too small to be worth tracking.

Obviously the pool and clients get more complex, especially with PPS, and the PPS could be risky, but I'm curious what people think.

Yeah I figured, but I didn't need the 9 (I forgot to save it but I got my address anyway)

http://gobittest.appspot.com/Address

Go here, click random a few times, save number 0, 1 and 9.

I think I got it at last. My new address is 1gaLaxy9csuBTvNLJYoUy6sengQbh1TpV

Looks like it wasn't included in the last few sets of binaries. If you replace the 0.22 with 0.20 it's in there. https://github.com/downloads/samr7/vanitygen/vanitygen-0.20-win.zip

Do I have to compile that myself? It isn't included in the binaries

You can use the keyconv utility that's packaged with vanitygen to create the public key.