Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 174. (Read 1061436 times)

Thanks a lot for this detailled explanation!

The 769 gh's is being paid more because of backpay for mining shares  of CPPSRB mining shares owed from slower rounds as you see it is under 100% you have a little over 5% in backpay shares owed to these miners so the pay will usually be higher depending on pool luck and what the pool can pay out as your other rig is running @100% paid shares and 100% is the max you can ever earn  and have no shares owed so they have  been paid the max earning of what paid shares are atm and not owed any backpay for mining shares of CPPSRB from slow rounds.When the pool doesn't find a block in allocated time the 100% will fall under to 99% 98% etc and mining shares that you could of gotten paid rollover and get paid out the next block so you earn the max pay per share  you will then get paid for the work of the past block that took longer but was beyond the pay thresh hold of the past blocks of past shares if owed depending on how slow previous rounds were if there were no slow rounds during mining then you are owed nothing and you remain at 100% with no back  pay as you earned full pay per share. If a round takes 3 hours to find a block and a block should be found in 2 hours? those extra  mining shares that it took to find the block then get logged too cppsrb shelved shares then if the next block is found in 5 minutes instead of getting paid for just 5 minutes of mining shares you did you get paid for the extra hour of shares from the previous block or blocks from shelved shares of the past the 100% drops to 99% 98% etc then get paid during the  next luckier rounds rounds if they fall below the 2 hour mark on luckier rounds and adds a extra .01 + from shelved shares or so depending on pool luck and what it can pay averaging out to max pay per share in the end.You wont ever get paid more than pay per share you did.

Maybe a dumb question, but I have two accounts with Eligius. One is a private one with 769.47 Gh/s. Below, you see a picture os some stats:



With this hashrate, I get an estimated change of 0.003 BTC.

Now a second account is hashing with an average of 1,377.44 Gh/s. It is a spondoolies hosted outside of my office.

As you see below, with about the double hashrate, the estimated change is 0.0001 BTC.



How comes? Shouldn't the estimated change be higher? It jumped to +0.001 once, which is still less than for the account with half the hashrate. Is this only a problem with the site or don't I understand the concept of how the estimated change is calculated (very likely...)

ugh wish he'd just stop...WK has better things to do then babysit this thread

Deleted another misinformation filled kano post.

kano, do not post in this thread again.  I hereby ban you from this self-moderated thread.

Edit: And deleted another (which was posted after this one....)

First, *I* deleted what was essentially a duplicate spammy post. (You quoted your own post in this post then immediately again with nearly the exact same response.  I left the first one, even though it doesn't belong here, but I figured you'd cry about it even more if I deleted both.

Anyway...



Jumping ahead, since you're blaming GBT here somehow (beating a dead horse much?)... while still not valid, I'll point this out:

The Eligius block you refer to was generated using the stratum protocol. This is actually embedded in the coinbase text of the block's generation transaction. see here.  The "ss33" near the end means "Server/Stratum #3, Instance #3."  GBT blocks start with "sg" and getwork just a single "s", both followed by a number.



Eligius actually immediately updates stratum work as soon as bitcoind returns a template.  Since Eligius actually generates some of the the largest blocks on the network, with thousands of txns at times, this actually can take a couple of seconds at times, but usually is pretty immediate. However, the mining hardware/software on the other end is free to continue working on the original work until it expires as per the stratum protocol.


If you want to argue this, there are many rebuttals.  However the most prominent is that txn fees account for less than half of a percent of miner rewards on avg, but time wasted not doing work while a new transaction list is pushed would result in a lot more losses I'm sure.

Anyway, I think the bulk of your argument is pretty much invalidated by the fact that you obviously don't know what you're talking about since you're blaming the protocol, then suggesting stratum, yet the block in question was generated using stratum...

If you continue on this topic pointlessly, remain clueless, and generally just spam this thread I will simply be deleting your posts.

I have mined almost exclusively at Eligius with my Avalon.

Under the current mining conditions, it takes more than a week for me to enter the payout queue.  I suspect a missed block could delay that payout by 1 block.  That seems insignificant, and otherwise it is not clear to me how an empty block is a bad thing for me.

I do see that an empty block was produced, and I can encourage a task to improve the transaction template processing, but I don't see any reason for urgency or scheduling this task before some others.

I haven't deleted anything here. Nor did I see any post of yours saying anything like I said, instead you appeared to be loudly claming that something was wrong with eligius, you went as far to imply that something was being hidden ("Makes me wonder why he won't explain it. As should anyone who uses this pool...")

You mean the protocol every pool uses? There is basically no GBT hashrate on eligius, as is my understanding— not that there is actually any latency difference.

I'm afraid you don't understand how block timestamps work. It's possible to find a block 100ms after the prior block and yet have a timestamp a minute later (or a minute before, for that matter), times are not synchronous between miners.

And yet you can look at the actual observed blocks and Eligius is underrepresented in empty blocks relative to hashrate.

What the fuck are you talking about here?  That kind of allegations demands some links.

I linked the actual blocks, so you can see exactly where empty blocks have been produced.

Of course it can. Shit, even getwork can do that.

This is the reasonable, well known, and expected behavior and not something to be concerned about.

Standard behavior for pool software is when a new block is accepted to immediately generate new work before the new transaction list is computed and then long poll again later to update. It can take bitcoind several hundred milliseconds to generate an actual block with content, especially if the mempool is large, and otherwise in that time you'd be twiddling your thumbs doing nothing or uselessly working on an old block. As a result, all miners will produce an empty block here and there, even when there is a backlog (E.g. for a 1 second dwell time it would be 0.16% of blocks).

In the last 1000 block there were 9 empty blocks, that rate suggests an aggregate dwell time of about 5 seconds. According to bc.i they were created by Discus Fish, Slush, Discus Fish, Discus Fish, Discus Fish, Eligius, KnC, Eligius, and Discus Fish.  Perhaps one pool's over-representation there suggests their long-polling behavior could use some tuning, but it isn't Eligius…

The obvious optimizations like precomputing the next block don't work, because someone else will usually have produced this one, and your 'next' will likely conflict with it... though it would be possible to do something like a 'fast tx list now!' that only guarantees validity, and perhaps makes idiotic choices wrt priority/fees.

Fortunately the timing of blocks are independent, e.g. that someone found a block 10 seconds after the last with nothing in it doesn't actually delay the finding of the next block with something in it.

Yes, but many miners don't update work that fast.

Thanks.  I'd still think 14 seconds is enough to pick up at least one transaction.

M

kano included the answer in his post, just obscured because he wanted to troll.
The previous block was only 14 seconds prior.

Looks pretty plain to see, it's indeed a block with no transactions that appears to have come from Eligius.  What does it mean?

M

Go away, clueless troll.

It's that new diff. Seems the pool wants nothing to do with, And I agree.

You win MrTeal, here's a cookie  

Now just make those Habaneros a decent price and we will all love you (except Cevidad maybe)

Oh and while I am here, wtf is up with the luck today? 

I labeled mine with the IP, and on Eligius they are Address_110, Address_111, etc. Not only do you know which physical one it is, but with a glance at Eligius you know where to log into if you want to change a setting.

Gotta love the KISS method

Stick some labels on them. You put the username in on the miner, so pick a naming convention change he username in cgminer and stick a label with the name on the outside.

If you are on /24 you can use the last octet of it's IP address. Then it is easy to identify and ssh in to one when it needs a reboot. I've actually gone and named them all a1, a2, a3, etc, created DNS entries on my local network, and then everything matches all the way through.