Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 148. (Read 499709 times)

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).

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)

What earlier discussion?

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

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.

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

Is there a way to withdrawal just the confirmed BTC

Watching.

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.

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.

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

Greetz
NetworkerZ

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.

Me too. Miner says connecting, then it mines for a few seconds and lose connection again. Also on us1 port 8337

Greetz
NetworkerZ

I am currently watching cgminer showing "Pool 0 communication failure, caching submissions" and after a second, sometimes up to 6-7 secs later, it gets back and submits the shares. Pool 0 is us.eclipsemc.com:8337

edit: switched to us2 and now it all seems to work fine.

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 hadn'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.

Payout difference was about 1% per user between the invalid and next block, which would account of decay time if you did not factor in the invalid block.

I will consider how best to handle (if at all) an invalid block insurance plan.

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).

Well, I can institute something like an "invalid block insurance" at 3% "fee"... I hesitate to call it a donation, though, since a donation implies of someones free will.  But like a couple pools have done in the past, they insure against invalid blocks with a forced donation of x amount.  I'm certainly open to this if there's enough demand.


Nope, there's no less than normal pay on invalid blocks, unless you mean 0 pay?  As much as I'd like to pay out on invalid blocks, I can't afford to pay 50 BTC out of my pocket.  I'm not really making money on running the pool and my Ferrari is sadly still on layaway.  Actually, I'll settle for an Lotus Exige or Ariel Atom at this point. 

I'm not sure I understand your question with regards to the block chart being wrong?

As far as the averages, there's a few different ways you can look at an invalid block and each are equally valid but produce very different results.  The convention, perhaps set by Deepbit and Slush et al in the beginning is to acknowledge invalid blocks as being a separate legitimate entity.  From a purely continuity standpoint, this should not be so and invalid blocks should never be acknowledged as existing in the first place as far as pools go - thus they should just be passed over and the current block continues as normal.

Convention and technical limitations make this more difficult in so far as it takes time for a block to be realized as invalid, so unless the pool delays the stats, an invalid block shows up in the chart until it's invalidated by the network. 

So, as far as luck goes for both the invalid and current block, since it's acknowledged as a separate entity from the current block, it takes with it it's luck.  It's ultimately a semantics game, and through convention and technical limitations, you get what you see.  If people would prefer another method/display/semantic convention, I am happy to oblige, I just chose the current method because that's what people are already familiar with and I am definitely not trying to hide anything.

I would like to point out, with this latest invalid, we are right under the "average" as far as invalids go, since the start of the pool (400 blocks * 1.5% = 6 invalids).

I saw that invalid block and it made me wonder two things:

1) Didn't I read something about the scoring system leading to some (much less than normal) pay on invalid blocks?  Was that the previous scoring system, is the block chart wrong, or is the calculation wrong?

2) How do the averages work with invalid blocks?  Technically, doesn't "44% luck" on an invalid block equate to no luck, and shouldn't the average luck percentage (if not the next block luck percentage) include the time wasted on the invalid block but not the luck from it (avg divide by 49 instead of 50 or something)?

I hate "Invalid Blocks".

What we need to do for EclipseMC pay us for invalid blocks?!

Looks great now (0.6%):

I'm not going to touch the servers again tonight, so reset your miners if it's not too much of a hassle and see how the stale count tracks.  If I do happen to have to restart the server(s) or if there is a problem with them, I will post here when the problem/reset occurred.