Vanity Pool - vanity address generator pool

[ThePiachu]

Well, I made the site look a bit more presentable. Also I'm testing some updates on the vanitypooltest.appspot.com website - mainly under the hood stuff. The tables should be neater, errors should be more informative and so forth.

For reference:

Database error, please try again later

types errors I found out mean that the Pool was not able to fetch the work info from the database. I guess some argument could be missing, as if the search just finds nothing, it displays a different error. I hope that's what it is...

Update to the main net version of the Pool should be up within a couple days. I just want to ask if you guys prefer the more compact view of the lists, or do you want all the info?

[fizzisist]

ThePiachu, can you add the pattern difficulty to the work list?

I could, although that feature might not be up for awhile. Currently working on my other projects. Some small sprucing up of the page might be coming soon though.

I understand. I do believe knowing this will be the key to get people to mine addresses using the pool. It is currently quite hard to figure out if mining addresses is more profitable than mining bitcoins. What's worse is that the profitability of each is changing all the time. Having the current value available would help make it easier to decide which to do.

Another effect this will have is to help a work submitter decide how much to pay. If they want their address to be generated first, they need to set a reward that makes the value of that address higher than the current highest value. If they can wait a bit, they can set the reward slightly lower, but higher than some of the other work available. Without this, you need to do a lot to figure out what reward to set. This will hopefully drive up the rewards over time as people compete for the computing power of the pool.

If all of this is done, I really could see vanity address mining a good replacement for bitcoin mining for all those non-ASIC devices that are pushed out when the difficulty rises. Without this, it's just a really cool toy.

[slush]

Is there any estimation how much workers and what MKey/s power is working for the pool? (btw I joined the pool few hours ago and just found the match, yay!)

[ThePiachu]

Is there any estimation how much workers and what MKey/s power is working for the pool? (btw I joined the pool few hours ago and just found the match, yay!)

Not really. I guess one could try estimating that through number of calls to the url displaying work and how much work gets submitted, but at the moment I don't really have a clue.

I'm glad you are having your first successes with the Pool.

[slush]

Actually displaying timestamp and prefix difficulty of solved matches on the web would help some estimation. It will be extremely inaccurate, but at least something....

[ThePiachu]

Actually displaying timestamp and prefix difficulty of solved matches on the web would help some estimation. It will be extremely inaccurate, but at least something....

I guess I could look into implementing that.


For now, some more smaller updates to the Pool - making it look less messy, as well as streamlining reward payout (as in, some changes on the server side of things).

vanitypool.appspot.com

[stevegee58]

Do I read right that this isn't really a "pool" like for BTC where miners directly connect to a mining address?  I've used oclvanitygen some already for my own use but I'm not sure how to go about this for the pool...

[ThePiachu]

Do I read right that this isn't really a "pool" like for BTC where miners directly connect to a mining address?  I've used oclvanitygen some already for my own use but I'm not sure how to go about this for the pool...

It's sort of like a traditional pool, only dedicated to mining for vanity addresses, rather than Bitcoin blocks. You need to use oclvanityminer application by samr7 (https://bitcointalk.org/index.php?topic=25804.0 - same package, different executable). You just specify my Pool and your reward address, and the program does all the mining:

$ ./oclvanityminer -u https://vanitypool.appspot.com/ -a 1samr7UZxtC6MEAFHqr1h3Kq453xJJbe4

This is all possible thanks to some properties of the cryptography behind ECDSA - generally you can outsource vanity address creation with zero risk to your coins. Only the person starting the bounty will know the private key.

[stevegee58]

I'm so dense sometimes.  I never noticed the oclvanityminer program (until now).

Interesting how profitable applications are popping up for GPUs now that BTC mining may become unprofitable.

[cambda]

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?

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)

[fizzisist]

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?

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.

[ThePiachu]

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?

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...

[fizzisist]

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?

[ThePiachu]

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?

[fizzisist]

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?

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).

[ThePiachu]

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

[fizzisist]

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!

[ThePiachu]

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.

[fizzisist]

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!

[stevegee58]

It's so refreshing to see something nice and useful taking shape!