[1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration!

[Inaba]

Definitely switch to US2.  US1 is just overloaded.

I will likely be rolling out a US3 shortly as well.  I want to make sure US2 is working properly before I add the code for the third server.

[1714292645]

1714292645

[1714292645]

1714292645

[1714292645]

1714292645

[1714292645]

1714292645

[1714292645]

1714292645

[NetworkerZ]

OK, switched all workers to US2. THX for the info.

Greetz
NetworkerZ

[kano]

I don't care one way or the other how the pool calculates the average, whatever is easier is fine, I was just curious as to how it was done.  Regarding the less pay, maybe I read that in Meni's thread, but I thought it was in this one, because it seems like it possibly wasn't necessarily part of double-geometric, but was part of the previous method (and I didn't read THAT threa [presumably also of Meni's]).  Doesn't really matter.  Maybe I misintrepreted a comment and the idea is that the score from the invlaid block is still paid, but at a lower amount since it is paid on later blocks and has decayed.  As far as invalid blocks go, they are part of it, an optional donation of 3% to get paid on invalids would  be optional and therefore of free will, but probably require more coding.  A 3% fee and paying on invalids might make some people happy and could theoretically earn (or perhaps cost) you more in the long run, but then you wouldn't be able to call the pool 0% (per your argument on the ABCPool thread).

You remember correctly, and I think this is implemented right in EMC even if Inaba isn't completely aware of why it's right (and even if I once erroneously commented on a PM that there's a problem in need of fixing).

The previous method which was the geometric method, is a special case of double geometric, so the same issue with invalid blocks applied to it (and more strongly). But I haven't yet examined invalid blocks thoroughly at that point, so what you're probably remembering are my comments in this thread about the current method.

The thing is this - DGM features block decay, which means that whenever a block is found, every worker loses a portion of his score. So the question is whether to decay for invalid blocks as if they were normal blocks, or refrain from decaying as if there was never a block at all.

Intuitively you might think that the block needs to be ignored. But a closer examination reveals that this would cause unfair losses to the operator (so on a 0-fee pool he would actually lose on average for running the pool). On the other hand, if blocks cause decay as if they were valid, the loss is shared equally between all parties. So if for example 1% of blocks are invalid, every miner will gain on average 1% less than he would have if all blocks were valid, and the pool op's profits, if the pool has fees, will also be reduced by 1% of the profit. This I think is the fair solution.

It just so happens that the correct solution is also easier technically, so it is what we have by default. It should also be noted that with the parameters used in EMC, block decay is very weak so the issue has little consequence one way or the other.

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.

Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.

[The00Dustin]

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
<snip>
Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.

That's one way to look at it, but if you do look at it that way, you could also argue that every time a new block is found on the network all old shares/scores should be discarded since they aren't for the current block (the algorithm does count shares, not blocks; blocks only trigger activity, and the invalid one didn't).  I think BTCGuild even counted shares from invalid blocks toward the next valid block when they were proportional, and it was all pooled work trying to acquire a reward that wasn't acquired until the next valid found block.  Regardless, I'm not sure arguing about which valid shares should count toward a block really has much merit.

EDIT: More importantly, if the algorithm didn't count shares from invalid blocks, pool hoppers would have something to gain, all the work they didn't do later in the invalid block.

[btc_artist]

Watching.

[stoppots]

Is there a way to withdrawal just the confirmed BTC

[BinaryMage]

Is there a way to withdrawal just the confirmed BTC

Under the "Pay Me" menu on the right of the "My Account" page, click "BTC" under "My BTC as".

[Meni Rosenfeld]

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.

What earlier discussion?

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.

Do you have a reference for that? This isn't possible as far as I know.

Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.

Like I said, that's the correct way to do it. Do the math if you don't believe me. When I have the time I'll add the relevant math to the DGM post and AoBPMRS.

[kano]

Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.

What earlier discussion?

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.

Do you have a reference for that? This isn't possible as far as I know.

...

It's not an 'impossible' issue (as I said the word 'orphan' isn't actually correct) but it's very simple:
If you calculate a share that's also a block but it's rejected coz it's late: an LP occurred while you were calculating it.
Like ANY normal rejected share except in this case it's also a block level difficulty.

I will also point out something to any people using cgminer that may have someone in tears if they find one:
If you log all of the output of cgminer, search the logs for a line that contains both "Rejected" and "BLOCK"
That's what I'm referring to (but they should be rare)

That's the same as an orphaned block except it's 1 or a few seconds later (so the pool doesn't advertise it to the network)
That of course has no effect on anything - yet your saying an orphaned block does with your algorithm simply because it was advertised to the network - but the network rejected it.

Of course you know, but I'll state it again: an orphaned block is simply a block that was either calculated just a fraction later than someone else on the network did (but was sent out coz the pool didn't know about the other block yet), or the other 'pool' got their block known by more nodes than your pool at about the same time (which usually also means your block was later than the winning block unless the losing pool has crappy network connections or a lower connection count than the wining pool)

[Meni Rosenfeld]

...

There is also another type of 'orphan' block that most don't know about due to them being rare
(and I don't know if the other miners show it, but cgminer does ... I wrote that code - also 'orphan' is not the correct word but anyway)
A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout.

Do you have a reference for that? This isn't possible as far as I know.
...

It's not an 'impossible' issue (as I said the word 'orphan' isn't actually correct) but it's very simple:
If you calculate a share that's also a block but it's rejected coz it's late: an LP occurred while you were calculating it.
Like ANY normal rejected share except in this case it's also a block level difficulty.

I misunderstood what you meant, now I get it.


For reference, by default the correct way to deal with rejected shares in the scoring method - shares which the pool knows are invalid the moment it receives them - is to ignore them completely, for purposes of both payout and decay, even if they happen to satisfy the full difficulty requirement. Decaying for invalid blocks is only if the pool thought at first this is going to be an accepted block but it happened to be beat by a different block. (Of course, the pool could offer payouts for rejected shares as a feature, but this would cause a loss unless the op takes a fee to compensate).

[Inaba]

us3.eclipsemc.com is open for testing.  Port 8337.

Let me know if anyone encounters any problems. 

[cyberlync]

It seems whenever we find a block I get quite long miner idles, I set the timer to go to the back up pool if I get 15secs of idle time (up from 6 secs), and both on us2 and us3 I seem to be getting this problem. Just watched it happen...

[Inaba]

Hmm, I don't see that on my miners.  I know US1 has a bit of time due to all the long poll responses streaming in, but that shouldn't be on US2 or US3. 

What miner are you using?

[cyberlync]

Using Phoenix 1.7.4 on both machines. I get higher hashrates with it than with cgminer.

[Inaba]

Heh, just solved a block and I happened to be watching one of my dual GPU miners, it had 3 Rejects just after the LP/block solve and continued on mining without a delay from what I could tell.

Have you tried poclbm?  When there are miner problems, it always seem to be traced back to something in the way Phoenix is handling thing, it seems to be notorious for that. 

[cyberlync]

Haven't tried it, will look into the whole thing tomorrow, gotta replace stock cooler on my 5870 anyway. Perhaps I will end up using cgminer, it's not that big of a difference to Phoenix.

edit: Which server is the closest to Europe by the way? Or are they all located at the same place?

[The00Dustin]

edit: Which server is the closest to Europe by the way? Or are they all located at the same place?

My guess?  eu.eclipsemc.com  I could be wrong, though.  

[Math Man]

us3.eclipsemc.com is open for testing.  Port 8337.

Let me know if anyone encounters any problems. 

I just switched to US3.  There aren't any immediate problems.  I'll report back late tonight or tomorrow morning. 

[cyberlync]

edit: Which server is the closest to Europe by the way? Or are they all located at the same place?

My guess?  eu.eclipsemc.com  I could be wrong, though.  

As far as I recall the eu server was cancelled due to the hosting prices, the ip is the same as us3.

[Inaba]

Yeah, eu is directed at US3 at the moment, until I can find a reasonably priced host in the EU.  Everyone wants so much for a basic server, which is all I'd need for the getwork server, it's pretty crazy.