Author

Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 192. (Read 458480 times)

hero member
Activity: 504
Merit: 502
Im a bit curious bout the auto payment.

After autopayment gets initiated, whats the delay once cleared from the stats to actually sending the funds? Ive noticed about 12hrs delay now whereas all my other pool withdrawals reached me in <2hrs.



You're using MyBitcoin? It doesn't work with eligius.

The payout should show up in your client pretty fast (if you actually get a payout and it's not queued for later execution - but it'd still be in your eligius account then), and then take 120 confirmations to mature.

Huh, why doesnt it work with mybitcoin? Its still a wallet?

I dont see any reason why eligius cant work with mybitcoin, not to mention the fact that if thats the case(for god knows what reason) my coins just went into retardville which is quite unacceptable.
newbie
Activity: 46
Merit: 0
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.
that is already disproven, because eligius pays already more than many pools for example deepbit. deepbit has 4661 Gh/s and eligius only 450Gh/s, but eligius pays 10/9 per share in comparision to deepbit. if it's all about the money they should have switched a very long time ago...


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

yes, that's how it was for me before the update too. but not now anymore.
the graph on http://eligius.st/~artefact2/ works as it should, but not the individual ones like http://eligius.st/~artefact2/5/16ccjkuuQjQ64H9qssmXnj695DdBDR75wJ
member
Activity: 98
Merit: 10
Im a bit curious bout the auto payment.

After autopayment gets initiated, whats the delay once cleared from the stats to actually sending the funds? Ive noticed about 12hrs delay now whereas all my other pool withdrawals reached me in <2hrs.



You're using MyBitcoin? It doesn't work with eligius.

The payout should show up in your client pretty fast (if you actually get a payout and it's not queued for later execution - but it'd still be in your eligius account then), and then take 120 confirmations to mature.
hero member
Activity: 504
Merit: 502
Im a bit curious bout the auto payment.

After autopayment gets initiated, whats the delay once cleared from the stats to actually sending the funds? Ive noticed about 12hrs delay now whereas all my other pool withdrawals reached me in <2hrs.

sr. member
Activity: 252
Merit: 251
Anything that presumes an infinite amount of anything should be immediately thrown out as a crap statistic IMO.  It's like the monkeys and the typewriters, except that here in the real world we have neither infinite monkeys nor infinite time.
Sure Eligius will crash given infinite time, but the odds are excellent that it'll be something over a million years in the future.

The million monkeys writing Shakespeare's full productions theorem is infeasible, because there is a practically zero chance (3.4 ×10^183,946) of it happening from today until the heat death of the universe even if all the million monkeys could punch in 1,000 letters per second.
http://skylla.wz-berlin.de/pdf/2002/ii02-101.pdf

A SMPPS pool running 500 BTC negative is a very real chance (while -5000 or -50000 is a minuscule, very improbable event). That would be enough to drive away most dedicated miners.
full member
Activity: 210
Merit: 100
Anything that presumes an infinite amount of anything should be immediately thrown out as a crap statistic IMO.  It's like the monkeys and the typewriters, except that here in the real world we have neither infinite monkeys nor infinite time.
Sure Eligius will crash given infinite time, but the odds are excellent that it'll be something over a million years in the future.
donator
Activity: 1654
Merit: 1354
Creator of Litecoin. Cryptocurrency enthusiast.
That's why I proposed RSMMPS (http://forum.bitcoin.org/index.php?topic=27698.0).
If buffer goes into too much negative, it automatically becomes a proportional payout until the pool gets lucky again.
sr. member
Activity: 252
Merit: 251
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
newbie
Activity: 42
Merit: 0

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
legendary
Activity: 2576
Merit: 1186
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.
member
Activity: 98
Merit: 10
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.
sr. member
Activity: 252
Merit: 251
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.
sr. member
Activity: 252
Merit: 250
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.
newbie
Activity: 46
Merit: 0
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?
member
Activity: 112
Merit: 10
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.
newbie
Activity: 46
Merit: 0
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.
full member
Activity: 518
Merit: 100
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? Smiley

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.
newbie
Activity: 42
Merit: 0
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? Smiley

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.
member
Activity: 112
Merit: 10
Firstbits: 1yetiax
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? Smiley
sr. member
Activity: 252
Merit: 251
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.
Jump to: