Topic: Vanity Pool - vanity address generator pool - page 19. (Read 147800 times)

Well, then I am currently puzzled as to why it doesn't work. It should be importable, as it is just a number really.

Prices are just what people are willing to pay for the vanity address, so is as realistic as it gets, by definition. The only problem is that bitcoin mining is more valuable right now. That is bound to change when more ASICs hit.

As for the "ratio" calculation, it's certainly misleading. I prefer my calculations on http://fizzisist.com/mining-value/. These should correspond to exactly what you see in vanitygen.

I checked both the van generated ones & they're negative so within the range & I know that my original one is also as I've used it on dozens of successful van gens & also just imported it to my wallet now with np.

Well, to check whether your private key is bigger than the number, simply substract that number from it.

For example, if your private key was
E343AF66D9394E3FFE3ED63C263A17F737917CAA35636B9FCA919A113368AB7F

You would calculate
0xE343AF66D9394E3FFE3ED63C263A17F737917CAA35636B9FCA919A113368AB7F-0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

or just use Wolfram:

http://www.wolframalpha.com/input/?i=0xE343AF66D9394E3FFE3ED63C263A17F737917CAA35636B9FCA919A113368AB7F-0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

If the number is negative, means that your private key is in the range.

Check both your original private key and the derived one to see if they are okay.

I don't know how to tell if they within that range, one starts with D217... & the other with C61F... I used the same pri/pub key for all my requests, also I don't know how to modulo the number but can try if you point me to where, thanks for looking in to this, luckily I'd only sent a token amount to each address in order to get the FirstBits address - which incidentally seems to be down the last few days.

Edit: I guess that they are within the correct range as they start with a letter before F in the alphabet. There're both 62 chars long.

Hmm, strange. I guess there is no option but for me to refund you. As you probably used the same private/public key to request for that address as the others, then you shouldn't reveal it to protect your other purchases.

Then again, a private key is just a number between 1 and
FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

Is your key bigger than the latter number? If so, try doing modulo that number and see if the result would work.

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.