Well, I think I managed to implement the basic Lavishness display on the Test Pool:
https://vanitypooltest.appspot.com/availableWork
Now I need to make some sort of calculator page, some more metrics and yeah, checking vanity profitability should be a breeze.
And yeah, as per some old feature request - I will be also looking into some sane bounty levels for different pattern lengths. Generally, the Lavishness will need to be high enough, meaning it will vary based on the pattern complexity/difficulty and bounty.
Topic: Vanity Pool - vanity address generator pool - page 29. (Read 148044 times)
What's the algorithm which selects the work? Currently my miner (HD5870) is calculating job with 50% probability in one day. Personally I'd like to prefer easier jobs even with lower income, just to have sane variance...
I think you would need to ask samr7 about it. As far as I know, the algorithm selects the most profitable job clusters (grouped by public key).
Btw. I don't see expected income for this job anywhere, is there any chance to obtain it?
I'm working on that metric.
Yeah, oclvanityminer doesn't actually display it. The algorithm it uses is essentially the following (this is the code I used to produce the above value (BTC/Gkey):
Code:
url = 'https://vanitypool.appspot.com/getWork'
try:
urlfh = urllib.urlopen(url)
except:
return 0
pubkeys = {}
for work in urlfh:
work = work.strip().strip(';')
pattern, pubkey, networkbyte, reward = work.split(':')
try:
difficulty = vanitycalc.getdiff([pattern], 0)
except:
return 0
if pubkey in pubkeys:
pubkeys[pubkey] += 1000000000.0 * float(reward) / float(difficulty)
else:
pubkeys[pubkey] = 1000000000.0 * float(reward) / float(difficulty)
max_value = 0
for pubkey, value in pubkeys.iteritems():
if value > max_value:
max_value = value
return max_value
This means it calculates the reward/difficulty for each piece of work. If a single public key has more than one job associated with it, it sums the values (reward/difficulty) for all of those jobs. It then picks the group of work (sharing a common public key) with the highest sum.
You can calculate the expected earnings for your hardware by multiplying the number obtained from that calculation by the key rate for your hardware. Currently, the max_value is: 0.0000585876 BTC/Gkey. My 5870 does about 29 Mkey/s (or 104.4 Gkey/hr), so my expected earnings are:
0.0000585876 BTC/Gkey * 104.4 Gkey/hr = 0.0061165 BTC/hr = 0.1468 BTC/day
What's the algorithm which selects the work? Currently my miner (HD5870) is calculating job with 50% probability in one day. Personally I'd like to prefer easier jobs even with lower income, just to have sane variance...
I think you would need to ask samr7 about it. As far as I know, the algorithm selects the most profitable job clusters (grouped by public key).
Btw. I don't see expected income for this job anywhere, is there any chance to obtain it?
I'm working on that metric.
What's the algorithm which selects the work? Currently my miner (HD5870) is calculating job with 50% probability in one day. Personally I'd like to prefer easier jobs even with lower income, just to have sane variance...
Btw. I don't see expected income for this job anywhere, is there any chance to obtain it?
Btw. I don't see expected income for this job anywhere, is there any chance to obtain it?
Vanity Wallet tab now on bitaddress.org
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html
Thanks! Are you also aiming to support Multiplicative Split Key Vanity Addresses?
http://gobittest.appspot.com/VanityMult
Vanity Wallet tab now on bitaddress.org
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html
ThePiachu, if you'd like to display the current max_value on your page (or lavishness as you call it), I made a simple API for you to grab this. Anyone else is welcome to as well. The value here is shown in BTC/Gkey, assuming mutliplicative mining (greatest sum of values for work available for each pubkey).
http://fizzisist.com/api/vanitypool-value-mult
Multiply this by your key generation rate in, for example, Gkey/hr and you get BTC/hr.
http://fizzisist.com/api/vanitypool-value-mult
Multiply this by your key generation rate in, for example, Gkey/hr and you get BTC/hr.
I am currently working on implementing this and a couple other things as well. I hope to get it done and running by tomorrow, but results may vary
.
ThePiachu, if you'd like to display the current max_value on your page (or lavishness as you call it), I made a simple API for you to grab this. Anyone else is welcome to as well. The value here is shown in BTC/Gkey, assuming mutliplicative mining (greatest sum of values for work available for each pubkey).
http://fizzisist.com/mining-value/api/vanitypool-value-mult
Multiply this by your key generation rate in, for example, Gkey/hr and you get BTC/hr.
EDIT: Updated API URL.
http://fizzisist.com/mining-value/api/vanitypool-value-mult
Multiply this by your key generation rate in, for example, Gkey/hr and you get BTC/hr.
EDIT: Updated API URL.
It's so refreshing to see something nice and useful taking shape!
How many useless things have been taking shape recently?
It's so refreshing to see something nice and useful taking shape!
What is the difference in performance is on average? We should probably be calculating both of these options, with another ratio factor. The client should decide which method to use. This could become important when scaling up, if there is a lot of available work from different pubkeys.
I have no idea what the difference in performance is, as I don't think anyone has implemented the other method yet. However, I'm afraid it might be dependant on the amount of keys to check. I will add the columns in.
Cool. I added mine to the table. If anyone has data for their hardware and doesn't feel like editing the wiki, please at least post here!
What is the difference in performance is on average? We should probably be calculating both of these options, with another ratio factor. The client should decide which method to use. This could become important when scaling up, if there is a lot of available work from different pubkeys.
I have no idea what the difference in performance is, as I don't think anyone has implemented the other method yet. However, I'm afraid it might be dependant on the amount of keys to check. I will add the columns in.
For multiplicative mining - one would take the biggest Lavishness sum of patterns sharing a single public key, and for additive mining - add all the Lavishnesses of all patterns (but also keep in mind different key generation rate for this method).
What is the difference in performance is on average? We should probably be calculating both of these options, with another ratio factor. The client should decide which method to use. This could become important when scaling up, if there is a lot of available work from different pubkeys.
Add these numbers to the new wiki page, too!
If you'd like to help this effort, please post your performance figures for your hardware (GPU model and hash/s and key/s).
This problem needs a wiki page
:https://en.bitcoin.it/wiki/Vanity_mining_hardware_comparison
I'm currently working on some metrics for calculating how profitable the pool is for the miners. My initial ideas are:
Variables:
Bitcoin Difficulty d
Miner Mining Speed m
Block Reward r
Miner Key Generation Rate k
Vanity Address Bounty b
Vanity Address Complexity (aka "difficulty", but I don't want to confuse the two) c
Expected Block Reward: (m*r)/(d*2^32)
Expected Vanity Reward: (k*b)/c
Compare the two and see which is higher.
However, if I want to present this more neatly in one equation, it would probably be like this:
Ratio: (b*2^32)/c * d/r * k/m
The right part is constant for a given miner, the left part is constant for a given pattern, and the middle part is just a simple ratio of difficulty and block reward. This equation is for a single address. If the ratio is higher than 1, you ought to mine for addresses, otherwise - mine for blocks.
I think I will call the left part of this equation Lavishness. To determine if mining at the Pool is more profitable than mining, one would all various Lavishnesses and put them in together into the equation. For multiplicative mining - one would take the biggest Lavishness sum of patterns sharing a single public key, and for additive mining - add all the Lavishnesses of all patterns (but also keep in mind different key generation rate for this method).
So what do you think, is this a good metric?
Variables:
Bitcoin Difficulty d
Miner Mining Speed m
Block Reward r
Miner Key Generation Rate k
Vanity Address Bounty b
Vanity Address Complexity (aka "difficulty", but I don't want to confuse the two) c
Expected Block Reward: (m*r)/(d*2^32)
Expected Vanity Reward: (k*b)/c
Compare the two and see which is higher.
However, if I want to present this more neatly in one equation, it would probably be like this:
Ratio: (b*2^32)/c * d/r * k/m
The right part is constant for a given miner, the left part is constant for a given pattern, and the middle part is just a simple ratio of difficulty and block reward. This equation is for a single address. If the ratio is higher than 1, you ought to mine for addresses, otherwise - mine for blocks.
I think I will call the left part of this equation Lavishness. To determine if mining at the Pool is more profitable than mining, one would all various Lavishnesses and put them in together into the equation. For multiplicative mining - one would take the biggest Lavishness sum of patterns sharing a single public key, and for additive mining - add all the Lavishnesses of all patterns (but also keep in mind different key generation rate for this method).
So what do you think, is this a good metric?
Yes, this is exactly what I've been lobbying for.
In fact, I went ahead and did this yesterday (how I got the numbers in the post above).In fact, I plugged these formulas into a script that grabs the relevant quantities from blockchain.info and parses your available work list to calculate them at any time. Then, it feeds the results into munin so that I can see a graph over time, so I can see some historical data on this:
As you can see, the "value" of address mining has decreased a little bit since the graph started because some work was solved. When the bitcoin difficulty or block reward changes, the green line will change, too.
Using your variable definitions, My graph is made with a ratio for m/k = 400/30 (which is true for my 5870). Could we collect a bunch of m/k values for a lot of different hardware and average them? If that ratio is pretty much constant for most GPUs, this value would be meaningful for most users (right now, it is only meaningful for a 5870).
If you'd like to help this effort, please post your performance figures for your hardware (GPU model and hash/s and key/s).
I'm currently working on some metrics for calculating how profitable the pool is for the miners. My initial ideas are:
Variables:
Bitcoin Difficulty d
Miner Mining Speed m
Block Reward r
Miner Key Generation Rate k
Vanity Address Bounty b
Vanity Address Complexity (aka "difficulty", but I don't want to confuse the two) c
Expected Block Reward: (m*r)/(d*2^32)
Expected Vanity Reward: (k*b)/c
Compare the two and see which is higher.
However, if I want to present this more neatly in one equation, it would probably be like this:
Ratio: (b*2^32)/c * d/r * k/m
The right part is constant for a given miner, the left part is constant for a given pattern, and the middle part is just a simple ratio of difficulty and block reward. This equation is for a single address. If the ratio is higher than 1, you ought to mine for addresses, otherwise - mine for blocks.
I think I will call the left part of this equation Lavishness. To determine if mining at the Pool is more profitable than mining, one would all various Lavishnesses and put them in together into the equation. For multiplicative mining - one would take the biggest Lavishness sum of patterns sharing a single public key, and for additive mining - add all the Lavishnesses of all patterns (but also keep in mind different key generation rate for this method).
So what do you think, is this a good metric?
Variables:
Bitcoin Difficulty d
Miner Mining Speed m
Block Reward r
Miner Key Generation Rate k
Vanity Address Bounty b
Vanity Address Complexity (aka "difficulty", but I don't want to confuse the two) c
Expected Block Reward: (m*r)/(d*2^32)
Expected Vanity Reward: (k*b)/c
Compare the two and see which is higher.
However, if I want to present this more neatly in one equation, it would probably be like this:
Ratio: (b*2^32)/c * d/r * k/m
The right part is constant for a given miner, the left part is constant for a given pattern, and the middle part is just a simple ratio of difficulty and block reward. This equation is for a single address. If the ratio is higher than 1, you ought to mine for addresses, otherwise - mine for blocks.
I think I will call the left part of this equation Lavishness. To determine if mining at the Pool is more profitable than mining, one would all various Lavishnesses and put them in together into the equation. For multiplicative mining - one would take the biggest Lavishness sum of patterns sharing a single public key, and for additive mining - add all the Lavishnesses of all patterns (but also keep in mind different key generation rate for this method).
So what do you think, is this a good metric?
I went ahead and wrote a short script to parse the available work list and calculate the maximum value (expected BTC/Gkey earnings when working on the pool). I end up with the result that for my 5870 I will earn more BTC mining addresses than it would mining bitcoins directly! A 5870 does about 400 MH/s and thus can earn about 0.131 BTC/day mining bitcoins. Generating vanity addresses it does about 30 MKey/s. The current max value calculated by my script is 0.00007114 BTC/GKey, so this card could earn about 0.184 BTC/day mining on this pool.
Of course, I don't use my GPU for mining bitcoins or addresses, since my power costs will exceed the earnings either way...
Can someone confirm these results? Is this what everyone on here already knew? Did I screw something up in my math?
Of course, I don't use my GPU for mining bitcoins or addresses, since my power costs will exceed the earnings either way...
Can someone confirm these results? Is this what everyone on here already knew? Did I screw something up in my math?
Interesting how profitable applications are popping up for GPUs now that BTC mining may become unprofitable.
Well, this idea was around for awhile before ASICs were becoming a thing.
I'm missing the point of joining your pool. Since it's not share-based or anything like that, why exactly should someone
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
Well, you don't really join the Pool per se. The Pool allows anyone to easily post bounties for their private keys and let the server handle everything. The miners just check the latest list of work every now and then, and submit their results when needed. This process is also automated through the use of oclvanityminer. If you want to get the work by hand, run the miner offline and then copy the result in and submit the work that way, it is possible, but an automated program can be faster. You can also set up your own pool with similar tools (someone has done that quite quickly actually), but then you would have to find people that would be willing to put bounties up there.
All in all, you don't need to join the Pool or use it at all, but it's a tool waiting out there if you find it useful.
For this reason, if vanity address mining picks up quite a bit, there will probably need to be some improvements to the protocol to help it scale up. For instance, a sort of long-polling would help to make sure you aren't working on expired work after it has been solved by someone else. If there are a lot of workers, this should be happening all the time.
I guess I should hope that will be a problem one day;). On the other hand, apparently Google App Engine does not like longpolling too much...
I'm missing the point of joining your pool. Since it's not share-based or anything like that, why exactly should someone
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
because it is automated - it is checking every few minutes if the work your miner is working on is with highest profitability (for example if new pattern with very high reward is added, your miner will start work on it within few mins, or if the pattern your working on is solved your miner does not need to work on this pattern anymore)
Yes, this is correct. Actually, this isn't a pool in the sense that a bitcoin mining pool splits up work and distributes the reward based on the proportion of work done, since there is no concept of a "share" in this pool. You are essentially solo mining, and the vanity pool provides a marketplace to exchange work and solutions. The reason this is fine for now is that most of the available work can be found in a few hours instead of the incredibly long time it would take to solo mine a bitcoin block. As cambda said, the miner is simply checking for new, more profitable work every few minutes. This isn't much different than the way solo mining for bitcoins works.
For this reason, if vanity address mining picks up quite a bit, there will probably need to be some improvements to the protocol to help it scale up. For instance, a sort of long-polling would help to make sure you aren't working on expired work after it has been solved by someone else. If there are a lot of workers, this should be happening all the time.
I'm missing the point of joining your pool. Since it's not share-based or anything like that, why exactly should someone
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
join pool when he can go solo (that means offline mode too) and than just pick rewards by submitting correct results?
because it is automated - it is checking every few minutes if the work your miner is working on is with highest profitability (for example if new pattern with very high reward is added, your miner will start work on it within few mins, or if the pattern your working on is solved your miner does not need to work on this pattern anymore)
Jump to: