My AMD 5770 crunches about 15.5 MKeys/s and, oh yeah, once I was lucky too on the vanity pool. It made me happy to see that something unusual happened that day. Always a nice surprise.

Unfortunately most work is way out of near reach and heavily underpaid for the amount of work needed to find a solution. Sure, with a tremendous amount of luck it might work out, but you can't rely on that.

When I'm in the right mood and bored of other mining, I'll point oclvanitymine @ the pool and hope for some lucky day.

The Vanity Address DAC mines blocks into existence by finding vanity names.Names are processed on a highest Bid basis and the entire hash power of the network is directed toward finding Vanity addresses for users.

Looks like there's some renewed interest in this - any chance a shared mining pool (which I thought of, but figured it was somewhere in this thread already - and it was) could make an appearance, or is the I/O cost still too high?

It's possible to make vanity address mining much like regular bitcoin mining, in the sense of tracking the total work completed by each participant, and possibly distributing rewards to all participants rather than just the finder. The idea would be, if somebody wants 1DanieLRH, post the bounty for 1Danie, and keep track of how many addresses each miner returns. Eventually, a matching address will come back, and all of the partial matches will make it possible to determine the division of compute resources.

I suppose the partial rewards would be possible, but could tax the pool a bit too much. It is running on Google App Engine which charges for each read/write operation. I guess if there is enough demand I can look into that.

Though the way I had thought of doing this was to be a bit more useful in the work generated - but then samr7 seems to have disappeared and several code changes would be needed, if even possible without breaking the whole 'zero trust' bit. But a possibly simpler solution dawned on me that should work without any changes on the miner side - but may be a headache in the making for accounting.

In addition to the long-prefix (Lx) work posted, you would have another set of work posted that has much simpler vanity prefixes (Sx) - be that short common words, repeating characters, or just inherently simpler prefixes (trying to recall why some characters were inherently more difficult than others.. might have been dreaming that); say prefixes that may average just a few per day (as opposed to the current '50% change of hitting a solution in N years')

A miner would run the oclvanityminer app twice*, with two different URLs for each (so that each gets a different list), supplying the same bitcoin address (this becomes the miner's 'ID'). When started 'as is', each will be mining at about the same hash rate (a 50/50 split), so the number of solutions sent out for Sx becomes indicative of how much work they're doing toward the solution of Lx.If the miner decides to give Sx a higher priority (assigning more threads, say), this inherently cuts into the hash rate for the Lx, making it less likely that they will hit the Lx within the same time frame as somebody who leaves it at 50/50. So while they may get a larger proportion of the bounty** once Lx has been found, it would - on average - take longer for it to be found, thus eating into electricity/maintenance costs and also allowing more shares by others to be submitted in that time.If they decide to do the opposite, giving Lx a higher priority than Sx, they may arrive at a solution of Lx more quickly, but because they have sent in fewer Sx, they'll get a smaller proportion of the bounty.* May need -g XxY tweaks as otherwise it may run out of resources (and crash the driver while at it - oops).** One option to discourage this behavior further is by giving the miner that actually finds the bounty a larger proportion by default - thus encouraging a miner to mine as fast as possible, 'beating' others to the solution, while letting them decide the shares vs actually-finding-it trade-off

The upsides to this approach are:

Can be done right now without any tweaks to the mining software.

The Sx results can be actually useful. Be that many 1Piachu prefixes for your own use, shorter prefixes as paid for by other customers (but with corresponding very small bounty), or generic prefixes ready to be sold off to a trusting party.

Would enable a shared pool, as proposed.

The downsides are many, too, though:

You'd have to set up the server to actually handle all this, and have to explain to everybody that you must run both instances or all work is done for nothing (as 'shares' are essentially not recorded). This may be forced by taking the original pool URL down (miner client will throw an error) and putting a notice up to explain what's going on. Alternatively, keep it up for those using the current format and add new sought-after Lx on a new URL.

You might not care for 'free' prefixes for your own use, convincing customers to post/add Sx entries and include bounties for those as well may be difficult, and while I can see the use for you selling packs of "1,000 1He11o addresses" for $n, most people would not be trusting you to have actually destroyed the private keys.

The 'discouragement' option modifies it from a fully shared pool to one where luck is factored back in (right now, it's almost completely luck whether you get the Lx before anybody else.). On second thought, maybe that's not really a down side. Just an aside.

As great as it would be to have those features implemented, at the moment I am working on too many projects to rework the Pool. I think what the Pool needs more of is exposure - if more people start using it, miners will be able to work on more addresses and get more regular profit.

As I understand it, those modifications aren't carried over to, or from, vanitygen. At least when I compare the numbers on the website to the ones I'm calculating based on the 'difficulty' figure from vanitygen, I get a bunch that are within the error of calculating from the scientific notiation used, but others that are ~0.39x smaller Lavishness, and yet others that are ~23x greater Lavishness. I figure it has to do with some of the things said in the stackexchange post, but I'm not actually seeing the relation as it is posted there (which actually agrees with vanitygen).

the address I received is : 1MrS3cu7boYn3JRb2mBPKgRygEs29N4ZFIt should have 1CACTUS

I used this recently - worked fine. Are you using Casascius' Bitcoin Address Utility or something else?

Try both combination types (Addition and Multiplication), and try both Compressed and Uncompressed. Note that the notification states Addition Uncompressed, so make sure you try that first.

If all else fails, try shooting me a PM with 1. Your PUBLIC key used in the challenge (should be the one in your post) and 2. the SOLUTION key received from the challenge. Note that this will not give me the resulting private key needed to spend funds. ( In theory you could send the PUBLIC key for both, if the method is indeed addition. )

Any updated miner repository? I am still using samr7's codebase, but thought maybe an updated version exists.

There's a fork, e.g. https://github.com/WyseNynja/vanitygen . Changes are relatively minor - most of the changes are in regular vanitygen to allow for vanity addresses for altcoins not supported in the samr7 codebase, and some small speedups with regard to regex-based vanity checks.

I don't think there's that much room for improvement in the actual mining process anyway. I think the selection criteria could use a tweak (right now it always goes after the one that has the largest 'lavishness', even if the 50% chance is several years into the future - versus lower lavishness but a payout sometime this week), and of course as I noted above it would be nice if this could be pooled.. but alas, low priority for the developer(s) Hopefully I can get around to doing a thread on these things at some point - still evaluating bits and pieces.

Any updated miner repository? I am still using samr7's codebase, but thought maybe an updated version exists.

There's a fork, e.g. https://github.com/WyseNynja/vanitygen . Changes are relatively minor - most of the changes are in regular vanitygen to allow for vanity addresses for altcoins not supported in the samr7 codebase, and some small speedups with regard to regex-based vanity checks.

I don't think there's that much room for improvement in the actual mining process anyway. I think the selection criteria could use a tweak (right now it always goes after the one that has the largest 'lavishness', even if the 50% chance is several years into the future - versus lower lavishness but a payout sometime this week), and of course as I noted above it would be nice if this could be pooled.. but alas, low priority for the developer(s) Hopefully I can get around to doing a thread on these things at some point - still evaluating bits and pieces.

Pooled mining should be possible and relatively easy. Why? Well because 1CACTUS has many variations, like 1CaCtUS or 1CACtUS and so on, but even if you get repeats like 1CACtUS, the rest of the character will be different plus the pool will verify the results.Now how will payout be calculated based on the submitted addresses, no idea.

If you don't want to wait for someone to find Aanton's address then you can always mine specific addresses from the work list by passing the public key to vanitygen and you could even write a little polling script to check the available work for new work that isn't so lavish it's years of hashing. Of course, statistically you'll earn more coin from hashing the most profitable address - which is aantonop at the moment.. which is why the pool is providing that address as the one to look for.

And what miners would be the best for mining vanity address, sha or script? Sorry for all the noob questions

Use the oclvanityminer that's part of vanitygen, or do it manually using oclvanitygen. SHA vs Scrypt comes into play if you want to generate vanity addresses for altcoins that use Scrypt - you'd have to check if there's a vanitygen build for the applicable altcoin.

And what miners would be the best for mining vanity address, sha or script? Sorry for all the noob questions

Use the oclvanityminer that's part of vanitygen, or do it manually using oclvanitygen. SHA vs Scrypt comes into play if you want to generate vanity addresses for altcoins that use Scrypt - you'd have to check if there's a vanitygen build for the applicable altcoin.