Vanity Mining Pool - PPS vanity address mining

[cparsley]

Is there a MAC version of this?

[ExploitAgency]

Excellent work, testing now.

How long until hash rate shows up for workers?

I get " Not enough data yet. "

Its been close to 30 minutes if not longer.

[ExploitAgency]

Is there a MAC version of this?

http://www.stanley-adams.co.uk/2013/12/custom-vanity-bitcoin-address/


Also try using
https://github.com/exploitagency/vanitygen-plus
https://github.com/exploitagency/vanitygen-plus.git

Someone, I believe N4M3Z, sent a pull request to fix the makefile for homebrew compilation on Sierra OS X.  So maybe this will be helpful in your quest.

[adaseb]

Shouldn't the worker update be more like every 10 seconds or 30 seconds or so. Because someone can easily run some script where they mine this every 10 minutes for 10 seconds and then delay for 600 seconds while mining something else.

I understand this isn't easy to program but this way is very unfair to the honest miners.

Because pretty soon somebody will rent 10000 Amazon EC2 and each has a different IP and different BTC address and they will cheat.

[ExploitAgency]

Shouldn't the worker update be more like every 10 seconds or 30 seconds or so. Because someone can easily run some script where they mine this every 10 minutes for 10 seconds and then delay for 600 seconds while mining something else.

I understand this isn't easy to program but this way is very unfair to the honest miners.

Because pretty soon somebody will rent 10000 Amazon EC2 and each has a different IP and different BTC address and they will cheat.

We were talking about when does it pull the latest Vanity Address to be mined from the mother pool "vanitypool".  That is if your referring to the 10 minutes spoken about earlier in this thread.  As in how often does it check to see if there is a "new block" so we don't waste our time on a "solved block".

It pays by shares.  Two things happen I believe. The person trying to cheat would be losing money from not getting the shares while they are mining at the other pool.  Then the other people still mining on the vanitypool would continue earning shares while the attempted cheater is away at another pool, thus making the profit per share drop which also causes the attempted cheater to lose money.  Plus there is a minimum payout too(I already thought of similar exploits and forgot about this fact here).  So I figured this issue doesn't apply.  But I may be wrong, I'm not an expert on these matters.

[adaseb]

How will this pool work with "block withholding"? The miner finds the "block" and send it himself to Vanitypool and claims entire reward?

[ExploitAgency]

bitcoin-apps I sent you a pm...

[estemaire]

Yes, worker share update is limited to 1 share every ~15 seconds. The synchronization with the upstream pool (vanitypool) happens once every 10 minutes, allowing for new work and synchronization of solved shares upstream.

For block withholding, this doesn't work for the same reason miners can't spend from the addresses they mine for customers themselves. The split key concept is just applied at another level, with the pool also having a generated keypair for each prefix and adding that keypair's public key to the upstream pool's exposed public key and handing it to miners. If you look at the getwork for vanitypool compared to the getwork for bitcoin-apps, you'll notice the public keys differ. That's protecting both the pool and, its miners.

When a solution comes in, the oclvanityminer private key is added to the pool's generated private key for that prefix and a final sanity check is performed to make sure the prefix matches. If it does, the solution is submitted upstream to vanitypool, and the result checked to verify the solution is indeed accepted.

With respect to automation, the only manual step for solutions is marking the reward as confirmed rather than pending, as a sanity check.

[ExploitAgency]

Did we find that prefix finally?  I saw someone did but our shares our are only in 250 range for new prefix I dont know how fast the we found the prefix bit refreshes.  Hope we did!  PS my shares all time disappeared, so in case we did find prefix I hope they come back.

[estemaire]

No, unfortunately for the pool, that was an external solve.

I've fixed the all time shares issue for future submitted shares.

[ExploitAgency]

Im unsure of the fix.  I submitted about 20,000 shares and my stats say 800 all time...

[estemaire]

Sorry, I was unclear. I meant, it hasn't been resolved retroactively, but it is now solved and new shares after the fix are being properly recorded. Payments are not derived from the "all time" shares but rather from the shares towards each work, so this shouldn't impact future payouts but will impact your personal stats page.

The pool's total shares count was not affected.

[ExploitAgency]

Note that you can be mining both of these right now unless the client has a 2 address maximum.

https://vanitypool.appspot.com/getWork

1AMBASSADE:04244E10924AB48D416FF2EC28E344B841347D0F27F21ED4AD06AAF299F245969E921F37E07D1E8 0603687800B9016FAE2C331F8EC2B743FA9513E65598CF0F701:0:0.008000;
 
1KEYSTAMP:04244E10924AB48D416FF2EC28E344B841347D0F27F21ED4AD06AAF299F245969E921F37E07D1E8 0603687800B9016FAE2C331F8EC2B743FA9513E65598CF0F701:0:0.008000;

Compared to

https://bitcoin-apps.appspot.com/getWork

Theres several other addresses on the vanitypool with shared public keys.  Maybe it would be a good idea to search the list and find the most matches of prefixes with the same public keys and mine all of those even if they are harder because it may increase the odds of finding a match if there are a lot more addresses.

Like this public key
04C13D9CF2B0E382A4AF29C5E2B97F85C6DD9445F7DCE82CD7207E6FC4716511981B0012C10B39E F152257A8407A2965F92F075379D311D5786D9421795B82D01C
Has 8 addresses associated with it but perhaps it is because the addresses are extremely challenging, although I am not sure how the probability goes up when searching for all of them.

[estemaire]

Yep, I'm refactoring some things to make it possible to mine multiple prefixes and still correctly allocate shares and rewards.

In a search for multiple prefixes, we don't care about the order they are found - just that they are found. So my understanding is that the probability of finding any individual prefix should be P(any) = P(prefix0) + ... + P(prefixN).

P(any) could still lower than P(easierPrefix), even with 8 prefixes, but it's still something that the pool should consider when selecting work for miners once support for mining multiple prefixes is completed.

[powrslave]

Get work request failed: Problem with the SSL CA cert (path? access rights?)

[estemaire]

Your client may not trust the cert's CA. You can also specify http:// instead of https:// in the miner URL when running oclvanityminer, which should fix that up.

EDIT: just deployed multi-prefix support. The pool will now ensure miners mine all prefixes that can be mined concurrently for a particular customer. Now we just have to actually find a solution

[ExploitAgency]

Seems to be working well with fetching multi-prefixes.

Now heres a real tough one...

What if you pull the ENTIRE getWork list from vanitypool and someone uses my modified client to manually search for an address thats not the easiest on the list by means of a custom often self hosted getWork list while maintaining the same submit url, maybe they are the only one working on it, but maybe someone else chooses to do the same thing.  Is this scenario taking things too far?  You would have to keep track of all addresses, don't know if its worth it but its the only thing missing, I can't see the pool getting many more major changes besides dumping parent vanitypool.

Modified oclvanityminer linux binary.
https://github.com/exploitagency/vanitygen-plus/tree/master/linux-binary

something like

Code:

cd /var/www/html
echo "getWork PASTE HERE">getWork
service apache2 start

cd to your vanitygen dir and...

Code:

wget https://github.com/exploitagency/vanitygen-plus/raw/master/linux-binary/oclvanityminer

Code:

./oclvanityminer -u https://bitcoin-apps.appspot.com/miner/[your Bitcoin address] -a [your Bitcoin address] -x http://127.0.0.1/getWork

[estemaire]

If miners work on different addresses, the pooling doesn't help increase the probability anymore. But it's an interesting idea.

I'm working on supporting requesting prefixes directly, which is going well. Case-insensitive addresses will be supported, which may be quite a bit more beneficial for miners and customers alike to get their vanity addresses faster and cheaper. The other thing I'm working on is making it as easy as possible to understand how to request a vanity address, as it can be quite confusing with the split key security measure.

[weedoge]

Nobody is mining here anymore? How long has the pool been dead? Wonder if we could get some attention on this again

[slavikus]

Nobody is mining here anymore? How long has the pool been dead? Wonder if we could get some attention on this again

Trying my luck on the "mother" pool, so I am currently supplying a few Mkeys of hashing power to outstanding work orders. Unfortunately, all of the pending items have a great deal of difficulty, so I don't think a solution for them is going to happen any time soon