Topic: Re: Mining pools list - page 63. (Read 784 times)

Yes, the name "tx fee" is a bit confusing, because it can mean both:
- if the pool pays the transaction fee when paying out to the miner the BTC earned (mined) by his workers (else: the fee is substracted from the payout);
- if the pool passes to the miners not only pure reward of the block (50 BTC) but adds the fees from the transactions accumulated in this block (that's what Satoshi wanted to be).
I think the "tx fee" is better for the former, and "tx reward" could be for the latter.

Pays Tx == are Tx rewards from block passed to the miner?

Maybe there's a better way to phrase it.

What is the txfee column?  If it's what I think it is, then EMC pays the tx fee on outgoing, it's not passed along to the user.

sounds sensible

I might be able to fit them in if I get rid of "reward method" (since they're grouped that way) and "pay stales" since hardly anyone does. Anyone not ok with that?

Hi OrganoofCorti

could you add columns if the pool supports Diff other than 1 and if it supports x-roll-ntime?

Thanks for that. This weekend I'll update all PPS and *MPPS to "Pay orphans" since I think all of them do - but haven't had confirmation from all pool ops yet, and it's rarely listed on the thread front pages.

Are you Itzod's pool op? If so it would be very helpful if you could read the OP here: https://bitcointalksearch.org/topic/request-to-all-pool-ops-108326 and let me know if anything needs to be changed.

Itzod pays for orphans, actually.

The PPS pools I have looked at 50btc and HHTT pay based on when you find enough shares to be due a payout. So the size of the pool and whether it actually finds and blocks has no impact on the miners.

Mt Red was paying on a block solve, so it's possible that some pools might not pay shares submitted to orphaned blocks and no one mentions it specifically. I did ask pool ops to read the post and get back to me if there was anything wrong, and those that did I changed.

I can't be certain that all PPS and *MPPS pools do pay shares submitted to orphaned blocks if it's not specifically mentioned in their threads or if the pool ops don't mention it to me, but if everyone thinks I should just go ahead and assume they do, then I'll make the changes.

How are orphans relevant to PPS pools? Either you find a share or not? Whether the pool finds a block that is orphaned or not it totally irrelevant to you?

Love it!

You don't need to post "subscribe" anymore. Just use the "watch" hyperlink at the top of the page, and then check on it using the "Watchlist".

Hi doublec, thanks for the feedback. I'll fix the Bitparking info. I get the info I use from the first page of each thread - if the intro doesn't specifically say "We do such and such" then I record a "No". I also thought most PPS pools would pay orphans - maybe it's taken as understood? Or maybe I'm developing pool thread blindness

As for paying stales, I have no idea. I'm only guessing, but I'd be assuming it was only paying stales just after a block solve - that would be sensible, but I really am not sure.

Bitparking pays orphans, as I think most PPS pools do but most pools in the PPS list seem to have No there.

How does "Pay stales" work? For those with a "Yes" does that mean a miner can ignore longpolls, get a bunch of getworks in advance, and chug through those even though they may end up woefully out of date and stale? Or is there a limit? If a pool only pays stales for a short time after a block change does that count as "Pay stales"?

Pool list updated with suggestions from crazyates and ShadesOfMarble. I hope everyone finds the changes useful - if not let me know. Also, let me know if there are any mistakes.





The only way I see this possible is still improbable. It would need to use the following:
1. An application that would ping both websites and submit a getwork request to mining servers for all pools on the list, and record a "yes/no" for each pool.
2. The application would have to be widely distributed so local network conditions would have less effect.
3. The application would need to be able to communicate with other instances and vote on uptimes, and then record the result.

I think each pool would be a good place to run a local instance of the app, and keep the website url and minings server IPs up to date. These would also have to be updated to other peers.

So, in a perfect world this sort of data could be obtained as long as someone wants to develop a p2p app to do it, and the convince all the pools to run and update a copy. Unless I'm wrong and completely missing some point or other.

My thoughts:

1) Pool downtime should only be counted when the pool's mining servers aren't working. If you can still mine with them, the pool isn't down and website issues shouldn't be considered for actual pool downtime. If there's a problem with the internet between you and the pool, the pool isn't down. However, if there's a problem with the pool's connection/ISP, then the pool is down because nobody can reach them.

2) A good way to quantify it might be percentile based. 1 server out of 10 going down for an hour would be 10% of 1 hour for that day; 1 hour is 4.166% of the day, so 1 server out of 10 down for 1 hour would result in 10% of 4.166%, or .04166% daily downtime percentage. Of course, if that one server is then causing nobody to be able to mine with the pool, that would be a full pool outage for 1 hour, or a 4.166% daily outage, even if only the one server was technically down.
2a) Using a percentile system so that you can compare pools and know how likely you are to lose hashes in a day due to pool outages if you don't have a backup - possibly you could even then extrapolate that to say "They had 2Th/s, so a x% downtime was a result of x lost hashes". That could give a direct number comparison to pools of different sizes. A small pool that is down for part of a day may have actually resulted in less impact to the BTC economy as a whole than a large pool down for a half hour.

I'm still trying to think of any way to quantify downtime.  The real problem is how you define it.  Most big pools have multiple servers, and a separate website server as well.  Is one node going down for an hour equal to 1 hour of downtime if they have 10 servers?  Additionally, from where do you measure it?  Routing issues aren't rare between the US and EU, and sometimes you end up with high packet loss between the two for short bursts.  Similarly, some people with Comcast/AT&T might have a bad hop on the way there so a large number of people experience downtime due to a specific hop within their ISP's route to the pool, but not to another.

There really isn't any good way to measure it aside from anecdotal evidence or major outages (DDoS?).

I thought I might put this here rather than continue in the thread it started
agree with eleuthria - well said

Downtime is an interesting point, and how to quantify it
some pools seem to lose their www access but mining is fine
or
mining goes down but www stays up
and
some just lose it all

for Ozcoin we can drop a mining node and move dns to another - no effective downtime
if the www/db server goes offline or loses communication with a mining node the mining node(s) will cache shares for up to an hour, there is delay processing shares after these rare events.

so I guess
Critical:
1: Server Down (all www and mining offline)
Severe:
2: Mining Affected
3: Website affected
Minor:
4: Statistics delay

or something similar might work
then how to gather stats
during downtime most pool ops are stretched just to fix stuff and keep their miners up to date, reporting after the fact would be the easiest.

Interesting idea though

Ozcoin mining ports are
Merged Mining 80 and 8332
Bitcoin only 8331

I'll do it if it doesn't make the table too messy. It may take a while to collect all the data though - anyone volunteering?