seems to be broken atm, I've received notification of another 2 solved but they don't work to retrieve the solution??
Hmm, so you have received confirmation emails, but the solutions are not present on the pool?
Topic: Vanity Pool - vanity address generator pool - page 25. (Read 148044 times)
Hmm, so you have received confirmation emails, but the solutions are not present on the pool?
seems to be broken atm, I've received notification of another 2 solved but they don't work to retrieve the solution??
Also note that the sign was in fact wrong on one of those solutions that I posted the other day, I updated the post to have another correct example so they should be safe to check against.
Hmm, sounds promising. Can you point me to some specification of that format, so I can try implementing it?
https://en.bitcoin.it/wiki/Protocol_specification#Signatures gives the public key format.
https://www.bitaddress.org/ will give both uncompressed and compressed addresses on the wallet details tab (that's what I've been using to double-check my results)
It's not base58, it's the compressed address format that the bitcoin client started using in v0.6. Been working on improving vanitygen performance and added compressed support to vanitypool.thruhere.net for testing but promptly solved all the remaining work there. Seems you can improve the hash rate by 80-90% pretty easily by checking the compressed addresses as well but it effectively cuts all the bounties here in half if half the solutions get rejected.
Hmm, sounds promising. Can you point me to some specification of that format, so I can try implementing it?
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=1SToctX%3A04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39EF152257A8407A2965F92F075379D311D5786D9421795B82D01C&privateKey=7E1D24DC0117902661A37AC9E57E054D7FE76B5421894F6FA73EE080568A2EDE&bitcoinAddress=15y2xFg4eBNSrrKZmsgnXzet8TZSzCgsr4 most recently. The math checks out doing it manually so I'm guessing it doesn't like the compressed solutions.
Yeah, the Pool accepts hex encoded solutions, not base58. I might add that feature in the next version.
It's not base58, it's the compressed address format that the bitcoin client started using in v0.6. Been working on improving vanitygen performance and added compressed support to vanitypool.thruhere.net for testing but promptly solved all the remaining work there. Seems you can improve the hash rate by 80-90% pretty easily by checking the compressed addresses as well but it effectively cuts all the bounties here in half if half the solutions get rejected.
ThePiachu, do you have any connection to the following website: http://www.haagediss.com
If not, I would like to let you know that someone is misusing your name.
If not, I would like to let you know that someone is misusing your name.
Thanks for your concern. I have been developing various solutions for this person over the course of a couple months. The server side of this website was one of those. The frontend was done by him, as was the idea.
ThePiachu, do you have any connection to the following website: http://www.haagediss.com
If not, I would like to let you know that someone is misusing your name.
If not, I would like to let you know that someone is misusing your name.
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=1SToctX%3A04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39EF152257A8407A2965F92F075379D311D5786D9421795B82D01C&privateKey=7E1D24DC0117902661A37AC9E57E054D7FE76B5421894F6FA73EE080568A2EDE&bitcoinAddress=15y2xFg4eBNSrrKZmsgnXzet8TZSzCgsr4 most recently. The math checks out doing it manually so I'm guessing it doesn't like the compressed solutions.
Yeah, the Pool accepts hex encoded solutions, not base58. I might add that feature in the next version.
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
F152257A8407A2965F92F075379D311D5786D9421795B82D01C">https://vanitypool.appspot.com/checkSolved?key=1PepsiCo:04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C
Any help appreciated
F152257A8407A2965F92F075379D311D5786D9421795B82D01C">https://vanitypool.appspot.com/checkSolved?key=1PepsiCo:04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C
The website appears to be working for me. However, my gobit test suite appears to be having some problems, as the private key
4876652DE4D45277999C7C02C5E8EB0CEF7A512CB4AE7EF51A85ED2D1996A629
encodes into
049322AA20CA83131F635C7ACBB05484E3FEDEAC699DF6FF34AEFDFEFEF4EEFFAEC10A698CC2DF6 DD9A9B95175C7C4416132F03771C21EC9DFF824FA5F7630B5
which appears to be one byte short for some odd reason...
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
F152257A8407A2965F92F075379D311D5786D9421795B82D01C">https://vanitypool.appspot.com/checkSolved?key=1PepsiCo:04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C
Any help appreciated
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.
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 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.
feedback:
I put a generation request (MoLeCuLaR) with a much too low bounty.
...
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).
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.
Quote
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. I believe that providing bounties a bit higher than equivalent in bitcoin mining will attach much more attention to all this stuff...
feedback:
I put a generation request (MoLeCuLaR) with a much too low bounty.
...
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.
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...
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).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?
http://pastebin.com/Ci2azd7h
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:
possible? makes sense?
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?
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?
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.
[...]
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.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
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
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?
Jump to: