Topic: Vanity Mining Pool - PPS vanity address mining - page 2. (Read 4215 times)

I've just deployed an update, it's now possible to add a worker ID by adding ".[workerid]" to the address in the pool URL.

The main improvement is that currently if you have multiple workers pointing at the same Bitcoin address URL, the share prefix will be shared and some of them will get "Already solved" errors. Now, you can specify worker IDs for the individual workers to ensure the hashrate and shares are properly counted.

That seems reasonable.

Need more miners!

Surely we will find the address in a few days.

Every 10 minutes, currently.

Oh ok I thought it chose the one with the best reward for the difficulty not  necessarily the easiest.  But I've never looked into it just assumed.

How often does your pool sync with vanitypool?

Yes, the plan is that once the mining part is working well, I'll work on and launch a bitcoin-apps specific pool (supporting case-insensitivity as an example potential feature).

Currently the work is the easiest address, selected by sorting the difficulty of each prefix. It uses the same difficulty calculation as oclvanityminer uses, specifically to work on the backlog

Consider being solely your own pool once you gain popularity as vanitypool takes 20% fee already  subtracted from reward shown(reward shown is actual payout on vanitypool, add 20% for total fee end user paid for address)

Take 2% from reward shown for payout on bitcoin-apps pool.

vanitypool seems to hold funds in a separate wallet for each address submitted

Is there anyway you can choose the easiest addresses first from vanitypool to make sure hashing power is going to good use vs going for the highest reward and we just clear out the backlog since you are in beta?

Also if you ever decide to shut down the pool I'd love it if you sent me your source and I'd gladly keep it going :-D

just throw 136.82 Mkey/s
let's see for the first payout 

Wow that was fast...

The changes are working GREAT!

One more typo, need to edit html tag here..


Tl;dr

I've updated the pool to add hashrate info (though it'll be a bit inaccurate until I iron out some of the problems with it).

After the above discussion, I went ahead and implemented the URL idea. The pool also now accepts a mining address of https://bitcoin-apps.appspot.com/miner/(your Bitcoin address), e.g.
The previous URL still works but I'll switch over to only accepting the new form in the next couple days or so.

Just a thought, although a new client is a great idea too, just lots of end users don't trust something new, don't know how to read code, and can't compile it themselves even if they could verify changes to code to be secure..  but if you get big and gain some trust and people see payouts maybe that will change.  Or maybe I am totally wrong.  Just my opinion.

But great project, and I'm looking forward to seeing it grow.  I'm throwing 1Mkey/s right now at it to just keep an eye on stats, then I'll send a little hashing power its way later on.  Seems to work great though so far!

Hmm, great thought. The adjusted URL would work. It could require the bitcoin address (e.g. /mining/1BTCADD[.optionalworkername]) and validate that when a share is submitted, complaining loudly if not set correctly. It wouldn't require client side changes and I don't think it's too hard to implement.

I forgot about the minimum payout, Haha, plans foiled!  Oh well you thought of everything...

I don't see any problems then, its actually working quite well now, minus a slow miner being rewarded the same as a fast miner.

Possible to generate a getWork specific to a workername?  like:

oclvanityminer -u https://bitcoin-apps.appspot.com/mining/worker1 -a BTCADD

maybe use btc payout address twice vs worker name so it will be unique

it avoids using ip addresses, and theres no reason for the getWork files to pile up, if you delete them every few hours they should regenerate as users come back to mine vanity

The big gpu farm is definitely a problem. That said, the upstream pools are still publicly available (e.g. https://vanitypool.appspot.com/) - if there's a big GPU farm the rewards can come from just mining that directly instead of using this intermediate pool. Well, if the goal is the btc rewards rather than playing the system . Either way, it's a risk, but it's a risk that everyone accepts when they start trying to solve a publicly requested vanity address for a customer

But, yes, I plan to do some work on this.

Well, there is the little problem of the minimum payout amount, which is partially due to fees and partially to disincentivize that kind of behavior but yes, if one has the resources this is of course possible.

Of course I developed this in a vacuum pretty much, it's good to have it out there and see what things I didn't think of and see how my assumptions hold.

Yes, that specific "share already solved" logic is pretty trivial to adjust as a quickfix. The caveat that makes it a little more than a quickfix is that it would have to only accept solutions with a different private key than any already submitted by the miner for the share, as otherwise you can solve one share and then abuse the fact that you know the solution to that share already to basically "print" shares . Still, should be possible to do while the longer-term solution gets built.

The discussion has helped me formulate some interesting ideas about how to do tracking without needing to mess with the client software, but mods might be handy down the road for better accuracy

Scratch 100x 1Mkey/s miners.

Use one big gpu farm then,

One could likely write a script that generates a thousand or however many Bitcoin addresses saving private keys of course.

Then point the farm to miner on your pool with each address until each one finds a share.

Then the reward keeps going down and down per share, but really that one gpu farm has all the shares...

Boom! even if it was just 10% of the pools hash rate it could take all the profits.  Because that other big hash rate gpu farm doesn't get but 1 share per 30 minutes because they are playing fair.

Then its pointless to mine if profit was really ever there...

I'm sure sweeping the coins from generated share stealing address would be a breeze too, easier than stopping miners after one share.

But I'm not being critical in a negative sense, its an awesome idea and I wish I did it first.  :-D

Good job so far!

PS: A server side only solution would be the best option of perhaps resetting the variable for "share already solved" to zero after adding a share to stats.  Don't know the server side code, is this possible?  Sounds too easy...  Anyways, pretty exciting stuff.  Only problem with a custom oclvanitygen is windows users struggle compiling it from source and the trust factor for new precompiled forks is low.  I would certainly add your mods to my fork though, but would need an additional flag for setting options for your pool as not to mess up compatibility with any other pools that may exist.

A bunch of 1Mkey/s miners with different payout addresses, but yes -- it would probably be more profitable in the current implementation.

I was hesitant to implement IP-based miner identification but have been thinking about this and it may not be too big a deal. My main concern was miners behind NATs (whether local to them, or carrier) which would basically all receive shares at the rate of the fastest miner sharing the public address. This is probably not actually that big a deal (or that common a problem) yet and so I might fix this up to add the miner identification.

It mostly becomes moot once the miner client is patched to present more info in /getWork but there'll still need to be a fallback for unpatched clients.

Thanks for trying it out and making me think

EDIT: on second thoughts, rather than editing the /getWork request to add params/headers, this could also be solved by just accepting cookies in the libcurl options (for both server_context_getwork and server_context_submit_solution) which might be a less complicated solution.

So if I have a miner doing 1Mkey/s it will pay the same as one doing 100Mkey/s?  Because you can only have one share per 30 minutes no matter how many times you solve that share?

No matter how many times you solve the share it only reports it as one share?

Thats how it is looking for me.

I didn't even see your response and thought stats just started working so I edited my post above, then I saw you had replied.  Thats a fast response, good work!

But anyways so am I correct on my assumption with shares that its more profitable to have a bunch of 1Mkey/s miners than one giant?

Thanks for trying it out.

I fixed the main page typos (ouch).

The 500 Internal Server error should be fixed as well. Sorry about that :|

With respect to the shares, the original oclvanityminer doesn't submit any additional information with its /getWork requests (e.g. a header or GET param containing the payout address), so the other option available for miner-specific shares (EDIT: and miner identification) is the miner's IP address. Instead of that, I chose to have shares generate pool-wide every 30 minutes, and they get added to the /getWork page so the miners complete them. They look like garbage prefixes, but they're randomized to achieve the desired complexity.

That also means faster machines still only get accepted shares once every 30 minutes. You can reduce the noise with option which will only get new work every 30 minutes.

An update to the /getWork request from the miner is captured in my "Ideas yet to be completed" in the original post:

I haven't gotten to it, yet, though. Once the miner client can provide more information, I can either generate new shares for that miner as they continue mining (to solve a new share every few minutes, like you say), or I can generate more complex shares to try and find that miner's ideal complexity for one-share-per-30-minutes. The former rewards faster hardware, the latter rewards loyalty and pays evenly for time spent. I lean slightly towards equally rewarding loyalty rather than raw hashrate as loyalty keeps keys being hashed while hashrate can come and go. Either way, whatever gets attempted isn't set in stone

Pool and individual hashrate is definitely something I'm interested in as well, and I should be able to make an initial version of it work now by seeing how frequently newly- and/or already-solved shares come in for an individual miner. Knowing a hashrate would also help the pool's UI report time to 50%/75%/90%/100% "probability" which is currently not visible.

Take this in a positive light but your pool has all the problems of a new pool, see below, perhaps the issue is its not updated in real time?:

There is a pretty massive typo...?

Problem: Fix:
Has this pool not yet launched?

Also theres a minor typo here(source html is wrong)

Also when looking up address statistics...

And more things, I keep getting these addresses...  are they there for testing or is it a bug.(Edit: I now see its shares, but they aren't counted as shares)
https://bitcoin-apps.appspot.com/getWork

Its on the getWork list but says already solved as did these when I started.

Total value for current work: 0.000001 BTC/Gkey
Pattern: 19Z8Cx                                                                
Address: 19Z8CxRWQWFRwVQBiZwo6eZ6tHqQyE5nJt
PrivkeyPart: 5JajFv34Hnup1GrkMM36jADChJcJZSaWGSGxJdUCPtzmREiCUuR
[52.04 Mkey/s][total 8886681600][Prob 21.5%][50% in 2.2s][Found 1]             share rejected, already solved


Total value for current work: 0.000001 BTC/Gkey
Pattern: 19TVqs                                                                
Address: 19TVqsYhEfjG9TvAd8uYnsZiA77hPQB2kf
PrivkeyPart: 5K9DRvcoG2iHLynDPnqXj8PL4GMPTrioXMXEKbw1qpUzMqt5Bx3
share rejected, already solved

Total value for current work: 0.000001 BTC/Gkey
Pattern: 12C6sz                                                                
Address: 12C6szsTwFmk9SYMFGjPHLDCvqLjFTP6bD
PrivkeyPart: 5KW9gu2v51kmPxzvuwoPZSXnCyqRxrHhJZ1prGaXwYmYGFpVukD
[54.84 Mkey/s][total 16326328320][Prob 21.2%][50% in 2.2s][Found 1]           share rejected, already solved
Searching for pattern: "1EvanAhrn" Reward: 0.034997 Value: 0.000001 BTC/Gkey
Difficulty: 50656515217834


I'm also not seeing the shares increase.  With your calculations of 1Mkeys getting 2 shares and hour, I should be getting a few shares every minute.  Although I can not view my specific stats because of an error 500, I don't see the shares for the pools stats increasing either.

Really cool project though, I am going to check out the other non piachu pool linked as well.

EDIT:

AHA I was wondering how you calculated shares! But the shares still don't increase as I solve them and stats don't work.

EDIT Now stats show up but shares still aren't right.

It seems only the first solve of the share is counted as a share?  Which in that case how can you calculate hashing power, might as well mine with 1mhkey/s and get paid the same as someone whos mining with 100mhkey/s

This is a neat service, I tried to launch a similar service at:
https://bitcointalksearch.org/topic/bitcoin-vanity-address-generation-service-free-promotion-1748422

However got no work pretty much.

To try and make vanity mining the tiniest bit more attractive again, and mostly because I needed a project, I've created a pretty basic (and very BETA) mining pool for vanity addresses that currently works as an intermediate between ThePiachu's vanity pool and miners.

The pool collects work from the upstream pool and distributes the lowest-difficulty (per oclvanityminer's measurement of difficulty) prefix to miners, who mine that as well as semi-regular shares. Then, if/when a vanity address is successfully mined, all miners who contributed shares end up with the reward. Payouts currently take place on balances with 0.01 BTC or more to avoid miners losing most of their rewards to fees, but as this is still very much a BETA product that might loosen up later on.

Things worth noting:

• This is really, really not profitable. It's somewhat more of a service to the people wanting vanity addresses rather than a way to get rich. But that's the case of most vanity pools now anyway
• Tested on Testnet, but not with an actual bounty from a vanity pool on the main network yet
• Could be buggy, no matter how much I've tested

Ideas yet to be completed:

• Patched version of oclvanityminer that submits more information in getWork requests, so the pool can avoid making too much noise with useless share prefixes for fast miners
• Smaller payout options (<0.01 BTC)
• Accepting vanity requests (including case-insensitive prefixes) as well as being an intermediate to other pools
• Pulling data from other pools
• Adjusting work selection algorithm to be less naive than just "lowest difficulty"

To avoid withholding, the pool generates an extra keypair and provides miners with the adjusted public key. This is the same as the split-key generation used for vanity pools, just with one more private key in the mix. Shares are currently randomized with a difficulty that is expected to take about 30 minutes on average on a machine that can generate 1Mkey/sec. A miner working 24/7 with >= 1Mkey/sec brings in 48 shares. <= 1Mkey/sec might see a lower share count over the same time period. These details are discussed in much further detail at https://bitcoin-apps.appspot.com/about.

My core assumption behind building the pool is that N miners working solo may never see a payout from some prefixes with significant time to reach "50% probability", but increase their chances of seeing a little income by working together and sharing the reward. That is the core premise of Vanity Mining Pool.

If you're interested and don't mind burning resources to never see a ROI, you can find the pool at https://bitcoin-apps.appspot.com/. You can find ThePiachu's pool at https://vanitypool.appspot.com/.

EDIT: also, I forgot to mention - the pool currently takes a 2% cut of rewards to help keep it running. When paying out sendmany is used and the transaction fees are spread across all miners being paid, but this is something I'm still not 100% happy with and so I may yet switch this to just having the pool absorb the TX fees.