[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[twmz]

However, on long rounds Eligius sends out all the other rewards from its reserve in a sendmany(?) tx.

No it doesn't. 

[1714830436]

1714830436

[1714830436]

1714830436

[1714830436]

1714830436

[1714830436]

1714830436

[1714830436]

1714830436

[nmat]

When do users get paid? What is the threshold? I was thinking about splitting workers (one address each) to get more detailed stats, but if the threshold is high I probably won't...

I think I saw the answer to this question somewhere, but I can't find it right now. I'm a little lost in the website 

[Luke-Jr]

When do users get paid? What is the threshold? I was thinking about splitting workers (one address each) to get more detailed stats, but if the threshold is high I probably won't...

To qualify for a payout, your balance must be at least 0.33554432 BTC. When the pool is calculating payouts (currently just 50 BTC at a time, due to limitations of generated transactions), it prioritizes addresses which have had unpaid coins for the longest first.

This is being given as an explanation of how payouts currently work, and is not a guarantee that the minimum payout or sorting algorithm will remain the same in the future.

[nmat]

Thank you! I will think about it.

[neptop]

I intended to join your pool, but somehow I can't connect to it. Using DiabloMiner for example it says:
ERROR: Cannot connect to mining.eligius.st: connect timed out

Similar messages appear when using cgminer.

[Xephan]

I was trying out non-big 3 pools with my secondary card and now I'm even thinking of switching my primary over from the bigger pool

[DiabloD3]

I intended to join your pool, but somehow I can't connect to it. Using DiabloMiner for example it says:
ERROR: Cannot connect to mining.eligius.st: connect timed out

Similar messages appear when using cgminer.

I suspect user error. I use eligius fine.

[Jack of Diamonds]

I intended to join your pool, but somehow I can't connect to it. Using DiabloMiner for example it says:
ERROR: Cannot connect to mining.eligius.st: connect timed out

Similar messages appear when using cgminer.

Try us.mining.eligius.st, it should be working fine. I've had zero downtime for days.

ps. If you want to check your stats & whether miners are active just write http://eligius.st/~artefact2/5/[btc address] in a browser.

[Yeti]

To qualify for a payout, your balance must be at least 0.33554432 BTC. When the pool is calculating payouts (currently just 50 BTC at a time, due to limitations of generated transactions), it prioritizes addresses which have had unpaid coins for the longest first.

This is being given as an explanation of how payouts currently work, and is not a guarantee that the minimum payout or sorting algorithm will remain the same in the future.

So... how are the other BTCs in "Paid in this block" transferred? Are they queued for future blocks, where the payout is less than 50 BTC? I'm not quite getting the grasp of this, nonetheless all of my payouts seem to work just fine.

To make it even clearer: Are the "Paid in this block" BTC really paid in "this" block and if so, how? And if not, how then and why?

[Xephan]

So... how are the other BTCs in "Paid in this block" transferred? Are they queued for future blocks, where the payout is less than 50 BTC? I'm not quite getting the grasp of this, nonetheless all of my payouts seem to work just fine.

To make it even clearer: Are the "Paid in this block" BTC really paid in "this" block and if so, how? And if not, how then and why?

The chart here should make it clear I think.
http://eligius.st/~artefact2/blocks/

Every share has a fixed value, currently at 0.00003198 BT.
So in a long run, the total shares contributed x 3198 uBTC will exceed 50BTC, in short runs, be less. The excess goes into the pool fund, currently at 358+ BTC
"Paid in this block" should be more accurately named "Paid for this block", the amount will be credited under the address used, then depending on the payment backlog as well as minimum of 0.33554432, may be transferred to the address some time later.

[anodyne]

To make it even clearer: Are the "Paid in this block" BTC really paid in "this" block and if so, how? And if not, how then and why?

I think "rewarded in this block" would be more accurate, since the part that exceeds 50BTC may not be paid out in the same block even if the user is over the threshold. But they are guaranteed rewards, and will be paid out later.

It seems that when the pool has funds it pays out the whole 50BTC income to miners in later blocks, and instead adjusts the "server funds" by internally moving bitcoins from the "outstanding rewards" pile. In short blocks, that would mean that miners still get paid the whole block income even if the table says "paid in this block: 10BTC". So, "rewarded" would work better there as well.

[shamathana]

are the graphs still not working?
if i active script content, one of the

"You must enable Javascript to see the graph.
You must enable Javascript to see the graph."
notifications disappears, but the graphs won't show up as they normally did.

[Stupidpal]

are the graphs still not working?
if i active script content, one of the

"You must enable Javascript to see the graph.
You must enable Javascript to see the graph."
notifications disappears, but the graphs won't show up as they normally did.

They're showing up fine here.

[shamathana]

are the graphs still not working?
if i active script content, one of the

"You must enable Javascript to see the graph.
You must enable Javascript to see the graph."
notifications disappears, but the graphs won't show up as they normally did.

They're showing up fine here.

so what do i have to allow in ghostery requestpolicy noscript abp or cookies that it works?

[Shevek]

In the last 2 days the server funds reached a steady state over 300 BTC.

Time to increase the reward per share? I have a proposal:

 * If after a solved block funds are over 250 BTC, reward increases 5% for the next block
 * If after a solved block funds are below 100 BTC, reward decreases 5% for the next block

It's a way to smoothly impact the luck of the pool onto the miners.

[Jack of Diamonds]

In the last 2 days the server funds reached a steady state over 300 BTC.

Time to increase the reward per share? I have a proposal:

 * If after a solved block funds are over 250 BTC, reward increases 5% for the next block
 * If after a solved block funds are below 100 BTC, reward decreases 5% for the next block

It's a way to smoothly impact the luck of the pool onto the miners.

300BTC is not really that big of a buffer. It will be easily depleted within a few very unlucky rounds at current hash rate.

If it grows large enough (say 1000+ or whatever LukeJR is comfortable with), some of it could be redistributed back to users.
This has a problem though, it will encourage pool hoppers to jump on Eligius during good luck streaks (because they know the next few blocks will distribute extra earnings),
unless the extra buffer is only distributed to people who have consistently submitted shares to the pool in the last week etc.

Also, according to Meni Rosenfeld's theory, the risk/probability of catastrophic failure in SMPPS payment schemes reaches 1 (or 100%) given an indefinite amount of time. Which means the pool would revert to proportional, and nobody wants that.

[gentakin]

Time to increase the reward per share? I have a proposal:

I think this is dangerous. It means a 100% guaranteed "better than average" luck to anyone who mines on eligius. If everyone was 100% rational (and not pool hopping), they'd stop mining at their current pool and jump to eligius instantly as soon as payouts are increased. Until, at some point in the future, eligius has 100BTC funds and reduces payouts. Chances are the situation won't improve and payouts are lowered even more after the next block. Now everyone should go to a score-based pool or ArsBitcoin with SMPPS.

I'm not mining at eligius, but I'd say: Keep the buffer as high as possible, until it's pretty sure (because of difficulty changes) that the buffer will be sufficient even with pretty bad luck. Then distribute some of the buffer, but distribute based on past mining work, not on the future. Look at ArsBitcoin, the buffer is at almost 600BTC there, while only 1000BTC have been paid out (1600 earned, 1000 paid). It's a good state for a SMPPS pool, because the miners can be sure to get the PPS payout for at least a few days.

[Luke-Jr]

Let's not forget that Eligius-De (aka EU) had two week-long rounds with a comparable hashrate/difficulty ratio as we have now. These things can and do happen, and we want to be prepared for it.

While SMPPS does have some real flaws if it were to get too far into "extra credit mode", be assured that myself and others have been brainstorming a solution should we ever get to that point. However, I disagree that probability of catastrophic failure is 100% given an indefinite amount of time. It seems to me that it is a coin-flip between 100% failure or 100% straight-PPS-success.

[Xephan]

so what do i have to allow in ghostery requestpolicy noscript abp or cookies that it works?

I use noscript and abp, and all that was needed to let the charts work was to allow Javascript on eligius.st

[Jack of Diamonds]

While SMPPS does have some real flaws if it were to get too far into "extra credit mode", be assured that myself and others have been brainstorming a solution should we ever get to that point. However, I disagree that probability of catastrophic failure is 100% given an indefinite amount of time. It seems to me that it is a coin-flip between 100% failure or 100% straight-PPS-success.

I can't find Rosenfeld's post right now, but is it not true that the statistical possibility of a negative and positive buffer balance is equal?

(I.e. we could just as well be -300BTC in the red right now, and in the worst case, many thousands of BTC negative, because the buffer would stabilize to around +-0BTC only over a very large sample)

In the best case Eligius would have a buffer of thousands of bitcoins, and in the worst case during continuous bad luck, the buffer would run negative into the thousands which would make very many miners impatient & abandon the pool -> It would die from a lack of miners.

Obviously, it's very unlikely the buffer will run into thousands of BTC (negative or positive). I'm definitely not counting on it and neither should anyone else
But the possibility always exists which makes SMPPS flawed in the super-long term (years), unless you autorevert to proportional payout every time it goes too much into negative balance