Vanity Pool - vanity address generator pool

[gyverlb]

Sorry, I updated the url to just api/vanitypool-value after samr7's explanation yesterday. I forgot to set up a redirect for that one, and the old url just points to the old data (which is no longer being updated). Sorry about that!

Works with the new URL, thanks.

[1713574648]

1713574648

[1713574648]

1713574648

[1713574648]

1713574648

[fizzisist]

Please tell us when it's fixed. I've disabled vanitypool in my configurations: in the current state I lose money on it (0.16BTC for ~6GH/s worth of rigs in 24h...).

The fix is live. I hope it will work as intended.

How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

13 confirmations now... Looks like something went wrong with that fix.

Definitely something wrong, the work still isn't available.

[ThePiachu]

How many confirmations do you require before a new pattern is available? I submitted this one and the bounty payment has 8 confirmations, but the work is still "awaiting payment."

Hmm, I think I might've put in a strict inequality (<) in the work updating tool, while I should've used a non-strict inequality (<=). So for the time being paying exactly 0.1 can cause the work not to update.

I will change that today.

[...]I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

This probably would be a welcome feature for a lot of miners.

[gyverlb]

[...]
I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

I'm on your fork. Works great.

Switching from vanity to bitcoin mining and back is a good idea. I'm actually already doing it with a custom Ruby script which is monitoring your API and the Bitcoin difficulty. It's not reusable (it builds upon my own existing setup with a central monitoring server which already knows how to reconfigure each of my rigs which all use cgminer).

I don't see exactly how oclvanityminer simply sleeping when rewards are not high enough will allow dynamic switching. There needs to be a trigger when oclvanityminer detects a switch from Bitcoin to Vanity or vice versa is adequate that handles all the work needed to properly switch. Here are the things my script does on all rigs when it detects a change from Bitcoin to Vanity is appropriate:

• stop the GPU in cgminer and change the memory speed (vanity mining sweet spot is around 650MHz for my 5870 and 5970 GPUs) through its API and leave it running to manage the fan speeds
• launch oclvanityminer

in the other case (Vanity -> Bitcoin) oclvanityminer is killed and cgminer restarted to reapply optimized settings for Bitcoin mining.

[Red Emerald]

[...]
I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

I'm on your fork. Works great.

Switching from vanity to bitcoin mining and back is a good idea. I'm actually already doing it with a custom Ruby script which is monitoring your API and the Bitcoin difficulty. It's not reusable (it builds upon my own existing setup with a central monitoring server which already knows how to reconfigure each of my rigs which all use cgminer).

I don't see exactly how oclvanityminer simply sleeping when rewards are not high enough will allow dynamic switching. There needs to be a trigger when oclvanityminer detects a switch from Bitcoin to Vanity or vice versa is adequate that handles all the work needed to properly switch. Here are the things my script does on all rigs when it detects a change from Bitcoin to Vanity is appropriate:

• stop the GPU in cgminer and change the memory speed (vanity mining sweet spot is around 650MHz for my 5870 and 5970 GPUs) through its API and leave it running to manage the fan speeds
• launch oclvanityminer

in the other case (Vanity -> Bitcoin) oclvanityminer is killed and cgminer restarted to reapply optimized settings for Bitcoin mining.

I've started writing a python script to do something very similar.  Then I realized that with ASICs and the reward drop around the corner, my GPUs will likely only be good for vanity mining soon enough.

I didn't think about changing memory values to improve speeds.  I'll try it out with my 5970s.

[crazyates]

Then I realized that with ASICs and the reward drop around the corner, my GPUs will likely only be good for vanity mining soon enough.

+1

[ThePiachu]

The fix is live and it appears to be working. It also addresses a part of the issue with the lower case characters being used for public key making it harder to submit work. Now new works' public keys will be converted to upper case, as it is the same case used by oclvanityminer.

[slush]

I just calculated expected daily profitability for my card (HD 5870):
27 MKey/s * 3600 * 24 = 2332 GKey/day
Total value for current work: 0.000018 BTC/Gkey

So 2332*0.000018 = 0.04199 BTC / day in average. Is it really less worth than bitcoin mining or I have any mistake in my calc?

[cambda]

I just calculated expected daily profitability for my card (HD 5870):
27 MKey/s * 3600 * 24 = 2332 GKey/day
Total value for current work: 0.000018 BTC/Gkey

So 2332*0.000018 = 0.04199 BTC / day in average. Is it really less worth than bitcoin mining or I have any mistake in my calc?

Your calculation is correct, you can check

http://fizzisist.com/mining-value/

to get quick info if it is worth to turn vanity miner on

[fizzisist]

[...]
I'm hoping to be watching near the moment the work switches over to "available" because I'm testing out a new feature for oclvanityminer that allows you to set a minimum value to mine for, otherwise put oclvanityminer in a sleeping state. This could make it possible to automatically switch to mining vanity addresses whenever it is more valuable than bitcoin mining (right now it isn't)...

If anyone wants to try it out, feel free to try my fork: https://github.com/fizzisist/vanitygen

I'm on your fork. Works great.

Switching from vanity to bitcoin mining and back is a good idea. I'm actually already doing it with a custom Ruby script which is monitoring your API and the Bitcoin difficulty. It's not reusable (it builds upon my own existing setup with a central monitoring server which already knows how to reconfigure each of my rigs which all use cgminer).

I don't see exactly how oclvanityminer simply sleeping when rewards are not high enough will allow dynamic switching. There needs to be a trigger when oclvanityminer detects a switch from Bitcoin to Vanity or vice versa is adequate that handles all the work needed to properly switch. Here are the things my script does on all rigs when it detects a change from Bitcoin to Vanity is appropriate:

• stop the GPU in cgminer and change the memory speed (vanity mining sweet spot is around 650MHz for my 5870 and 5970 GPUs) through its API and leave it running to manage the fan speeds
• launch oclvanityminer

in the other case (Vanity -> Bitcoin) oclvanityminer is killed and cgminer restarted to reapply optimized settings for Bitcoin mining.

You're right that this feature does nothing when you have a more sophisticated system like yours. Still, it can provide a very simple mechanism when the user is only interested in mining address or doing nothing. If they set the minimum value to roughly their cost of power, it will only switch on whenever they can make any profit. Since it only adds an additional command line option, it doesn't really do any harm to add it, so I feel like it would be a worthwhile addition (although of limited use).

Glad to hear that you got a system working for you, and that I could help! That is exactly what I had envisioned when I started out my little project. Are you interested in sharing your script?

[fizzisist]

I just calculated expected daily profitability for my card (HD 5870):
27 MKey/s * 3600 * 24 = 2332 GKey/day
Total value for current work: 0.000018 BTC/Gkey

So 2332*0.000018 = 0.04199 BTC / day in average. Is it really less worth than bitcoin mining or I have any mistake in my calc?

Your calculation is correct, you can check

http://fizzisist.com/mining-value/

to get quick info if it is worth to turn vanity miner on

Yep, vanity address mining on the pool is seriously under valued right now. Now would be a good time to submit a very difficult pattern with a low bounty, as long as the bounty is high enough.

Also, I just added the ability to look at older data in the graphs by clicking on any of them.

[molecular]

feedback:

I mined for a bit in the pool but determined it was not profitable at the moment BTC (I guess there are some low-hanging fruit popping up from time to time but they are of course snatched quickly, right?).

I put a generation request (MoLeCuLaR) with a much too low bounty.

I think maybe both these problems could be taken care of by informing the user about the results of some educated guess as to how high the bounty should be on the page where people enter the requests? Maybe a little table based on the given "difficulty" like this:

you pay | expected time to delivery
----------------------
BTC 0.1 | 2 years
BTC 1.0 | 3 months
BTC 5.0 | 2 weeks

possible? makes sense?

[gyverlb]

You're right that this feature does nothing when you have a more sophisticated system like yours.

Just realized that I didn't elaborate on my trigger idea. To make it easier to integrate with other things, simply passing a script for both start/stop event which would be called with a fork/exec would help.

Still, it can provide a very simple mechanism when the user is only interested in mining address or doing nothing. If they set the minimum value to roughly their cost of power, it will only switch on whenever they can make any profit. Since it only adds an additional command line option, it doesn't really do any harm to add it, so I feel like it would be a worthwhile addition (although of limited use).

Glad to hear that you got a system working for you, and that I could help! That is exactly what I had envisioned when I started out my little project. Are you interested in sharing your script?

It's raw, needs external scripts to work and I think I have a bug when your API isn't reachable that makes it exit in error (probably trivial to fix).
http://pastebin.com/Ci2azd7h

[slush]

I think maybe both these problems could be taken care of by informing the user about the results of some educated guess as to how high the bounty should be on the page where people enter the requests? Maybe a little table based on the given "difficulty" like this:

That would be great. Unfortunately it requires pool to know pool hashrate, which is not possible yet. And it might fluctuate a lot, depends on the highest bounty in the pool.

However another "educated quest" may be provided for users. Pool can calculate "recommended bounty", which will make mining for this solution a bit more profitable than bitcoin mining. AFAIK there's some simple approximation between (vanity's) GKey and (bitcoin's) MHash, at least for some kind of hardware as ATI HD xxxx. Fizzists's calculator is useful, although it don't take bitcoin profitability in account.

I believe that providing bounties a bit higher than equivalent in bitcoin mining will attach much more attention to all this stuff...

[Otoh]

feedback:

I put a generation request (MoLeCuLaR) with a much too low bounty.
...

I'm sure you know that you can send additional bounty to the same bounty address if you wish to make it more attractive/realistic.

[Red Emerald]

I think maybe both these problems could be taken care of by informing the user about the results of some educated guess as to how high the bounty should be on the page where people enter the requests? Maybe a little table based on the given "difficulty" like this:

That would be great. Unfortunately it requires pool to know pool hashrate, which is not possible yet. And it might fluctuate a lot, depends on the highest bounty in the pool.

How about just saying an estimate for how many GKeyHours will be required for 50% probability?  You could also provide how many GKey are currently on the pool.  Is reporting like that currently in oclvanityminer?

However another "educated quest" may be provided for users. Pool can calculate "recommended bounty", which will make mining for this solution a bit more profitable than bitcoin mining. AFAIK there's some simple approximation between (vanity's) GKey and (bitcoin's) MHash, at least for some kind of hardware as ATI HD xxxx. Fizzists's calculator is useful, although it don't take bitcoin profitability in account.

I believe that providing bounties a bit higher than equivalent in bitcoin mining will attach much more attention to all this stuff...

Soon most GPUs will be useless for bitcoin mining, so I don't know if providing bounties "a bit higher" will last very long, but I agree that is a good idea for now.

[fizzisist]

feedback:

I put a generation request (MoLeCuLaR) with a much too low bounty.
...

I'm sure you know that you can send additional bounty to the same bounty address if you wish to make it more attractive/realistic.

Even better, request another pattern with the same public key with a reasonable bounty and both will be worked on. You can pop in the pattern and your pubkey to my calculator and it will suggest one.

True, it doesn't make sure that this value will be higher than for bitcoin mining. The reason is that I'm still waiting for more data to figure out a reasonable hashrate/keyrate ratio that is valid for most GPUs.

As for estimating the total key/s for the pool, this will probably need some change to the protocol to allow the miner to occasionally report keys generated in the last N seconds. Then, the pool would be able to display this and make some estimates. Of course, this number should vary widely as more valuable work appears. For now, the best we can do is set a bounty that is higher than the rest.

Another option to get a crude estimate: on the completed work page, show timestamps of when the work and solutions were submitted! Also, make the solved work available in an API (JSON please).

[FLHippy]

However another "educated quest" may be provided for users. Pool can calculate "recommended bounty", which will make mining for this solution a bit more profitable than bitcoin mining. AFAIK there's some simple approximation between (vanity's) GKey and (bitcoin's) MHash, at least for some kind of hardware as ATI HD xxxx. Fizzists's calculator is useful, although it don't take bitcoin profitability in account.

I believe that providing bounties a bit higher than equivalent in bitcoin mining will attach much more attention to all this stuff...

I complete agree with this except I would like to suggest that the bounty forced to a value that will be GPU profitable allowing them to offer more than the minimum profitable bounty to get a higher priority.

Vanity address generation isn't like mining in the sence that some miners may be doing it at a loss simply because they believe strongly in the bitcoin idea and want to help secure the network. This incentive does not exist for vanity address generation so the bounty should be forced to a value that is profitable.

Calculations are a little difficult with highly variable energy costs but I think we could take a global average and use that. Also take an average of efficiency of the top 10 GPUs and use that in the calculations.

Even after GPU mining is not profitable, there is till going to be thousands of gamer enthusiasts which will mine for vanity addresses when they're not gaming. The end of GPU mining certainly does not mean the end of GPUs. I think I read that mining represents only 1% of AMD's sales.

I'm not sure how I can help but I would like to. I have some free time these days.

[mskwik]

I see I've gotten a collection of rejections this morning, https://vanitypool.appspot.com/solveWork?key=1stDECx%3A04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39EF152257A8407A2965F92F075379D311D5786D9421795B82D01C&privateKey=47F54EE114C935B1920EE833CFE90AD12A86D0C0A40A046C561C6517AA656893&bitcoinAddress=1PkdeXKsdPe5vEA3oTSv8HgCncfJxPqFab and https://vanitypool.appspot.com/solveWork?key=1QuanYin%3A04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39EF152257A8407A2965F92F075379D311D5786D9421795B82D01C&privateKey=07B710E1E5485749B0AA2A4DFF88701BDC1C5EB1D8F4E3FD06611F8CE6C0144A&bitcoinAddress=1CLZJF7GcjPa2HkVWHTiLAefoSLb4eKPaF most recently.  The math checks out doing it manually so I'm guessing it doesn't like the compressed solutions.

[Otoh]

Many of my bounties solved today, many thanks, just one that is reported solved but when I try to sum it to get the address & private key nothing happens - the page just goes blank??

F152257A8407A2965F92F075379D311D5786D9421795B82D01C">https://vanitypool.appspot.com/checkSolved?key=1PepsiCo:04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C

Any help appreciated