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

[wizkid057]

I've been thinking a bit on how to smoothen variance here.
One idea.

As pools' buffer is very unlikely to turn positive in the foreseeable future, intruduce the second buffer, which will be built from tx fees exclusively. Every lucky round it's increasing and can only be spent when the round is unlucky.
This way current miners will have some sort of buffer against future unluck, while currently during lucky rounds all credit goes to old miners.
Currently fees don't constitute much, but still can still smoothen medium-term earnings.

This should make no real difference, long term, compared to the current setup of paying fees to the share log during all rounds.

[RoadTrain]

I've been thinking a bit on how to smoothen variance here.
One idea.

As pools' buffer is very unlikely to turn positive in the foreseeable future, intruduce the second buffer, which will be built from tx fees exclusively. Every lucky round it's increasing and can only be spent when the round is unlucky.
This way current miners will have some sort of buffer against future unluck, while currently during lucky rounds all credit goes to old miners.
Currently fees don't constitute much, but still can still smoothen medium-term earnings.

This should make no real difference, long term, compared to the current setup of paying fees to the share log during all rounds.

Long term yes, but short term? Having buffer will allow more shares to be paid during unlucky times.
Expecially since there are sometimes block with significant fees.

I proposed it because back when Eligius planned abandoning SMPPS, you were discussing options on how to prevent SMPPS credit from being a burden on active miners.

[wizkid057]

I've been thinking a bit on how to smoothen variance here.
One idea.

As pools' buffer is very unlikely to turn positive in the foreseeable future, intruduce the second buffer, which will be built from tx fees exclusively. Every lucky round it's increasing and can only be spent when the round is unlucky.
This way current miners will have some sort of buffer against future unluck, while currently during lucky rounds all credit goes to old miners.
Currently fees don't constitute much, but still can still smoothen medium-term earnings.

This should make no real difference, long term, compared to the current setup of paying fees to the share log during all rounds.

Long term yes, but short term?
Expecially since there are sometimes block with significant fees.

I proposed it because back when Eligius planned abandoning SMPPS, you were discussing options on how to prevent SMPPS credit from being a burden on active miners.

The only thing this change will do is add more variance to how transaction fees are distributed by basically flipping a coin as to whether or not to distribute them or not each round (lucky or unlucky), which is undesirable.

[RoadTrain]

I've been thinking a bit on how to smoothen variance here.
One idea.

As pools' buffer is very unlikely to turn positive in the foreseeable future, intruduce the second buffer, which will be built from tx fees exclusively. Every lucky round it's increasing and can only be spent when the round is unlucky.
This way current miners will have some sort of buffer against future unluck, while currently during lucky rounds all credit goes to old miners.
Currently fees don't constitute much, but still can still smoothen medium-term earnings.

This should make no real difference, long term, compared to the current setup of paying fees to the share log during all rounds.

Long term yes, but short term?
Expecially since there are sometimes block with significant fees.

I proposed it because back when Eligius planned abandoning SMPPS, you were discussing options on how to prevent SMPPS credit from being a burden on active miners.

The only thing this change will do is add more variance to how transaction fees are distributed by basically flipping a coin as to whether or not to distribute them or not each round (lucky or unlucky), which is undesirable.

Yep, looks like you're right, it seems to only make the system more complicated.

[HellDiverUK]

Stats stuck?  Seem to have the same stats for the last few hours.

[wizkid057]

Stats stuck?  Seem to have the same stats for the last few hours.

Stats look fine...

[spooderman]

Is there a way to find out how far back in the sharelog we are at any given time? Like, 'the shares being paid out now are from 4 months ago' when we have great luck....

[wizkid057]

Is there a way to find out how far back in the sharelog we are at any given time? Like, 'the shares being paid out now are from 4 months ago' when we have great luck....

This has actually been asked a few times recently.  The short answer is no.

The long answer is here in this post and the followup posts shortly behind it.

In the future I plan on adding a sort of histogram to show users where in the share log their shares are.

-wk

[spooderman]

Is there a way to find out how far back in the sharelog we are at any given time? Like, 'the shares being paid out now are from 4 months ago' when we have great luck....

This has actually been asked a few times recently.  The short answer is no.

The long answer is here in this post and the followup posts shortly behind it.

In the future I plan on adding a sort of histogram to show users where in the share log their shares are.

-wk

awesome ty. The lack of this feature speaks to the pool's efficient principles. Still, in the future....

[ionstorm]

I am finding that I am having inconsistent hash rates because I am either getting too low of pool difficulty or too high, for 24 hours I switched over to another pool that had manual difficulty setting, what I did was took ckolivas's advice by doing total Gh/s / 1.4 and was getting very consistent hash rates.  I see that the manual difficulty setting is not yet enabled, can the dev's update us on when this feature will be enabled so advanced miners may have a little more control over their hash rate fluctuations

[wizkid057]

I am finding that I am having inconsistent hash rates because I am either getting too low of pool difficulty or too high, for 24 hours I switched over to another pool that had manual difficulty setting, what I did was took ckolivas's advice by doing total Gh/s / 1.4 and was getting very consistent hash rates.  I see that the manual difficulty setting is not yet enabled, can the dev's update us on when this feature will be enabled so advanced miners may have a little more control over their hash rate fluctuations

With a higher difficulty you will get a much more inconsistent hash rate on the pool-side.  The current variable difficulty settings on Eligius are tried and tested and have proven to work perfectly.  There is no need to adjust the difficulty manually, ever.  Info to the contrary is simply incorrect.  The pool targets 32 shares per minute.  This ensures that a) You are never spinning your wheels, per se, working on too high of a difficulty work for your hash rate, b) ensures the pool gets sufficient shares from your miner to keep statistics variance low so that stats are still valid, c) makes it so you don't have to ever actually change anything since pool does it for you, and many other advantages over a static difficulty.

I will most likely be scrapping the manual difficulty setting option, since after much research and testing, it simply has no real purpose.

Basically, if you're setting a static difficulty on another pool and you're getting a better hash rate, either you've been fooled by variance or the pool is lying.

-wk

[fizzmine]

Is the 32 share per minute target per-worker or per-address?  Knowing that could help some configurations and allow the miner some flexibility in optimizing their configuration.

[rascal777]

So, are the bitcoin transaction fees (or a precentage of them) paid to the miners?  and if so,  how does this work in detail?

[ionstorm]

I am finding that I am having inconsistent hash rates because I am either getting too low of pool difficulty or too high, for 24 hours I switched over to another pool that had manual difficulty setting, what I did was took ckolivas's advice by doing total Gh/s / 1.4 and was getting very consistent hash rates.  I see that the manual difficulty setting is not yet enabled, can the dev's update us on when this feature will be enabled so advanced miners may have a little more control over their hash rate fluctuations

With a higher difficulty you will get a much more inconsistent hash rate on the pool-side.  The current variable difficulty settings on Eligius are tried and tested and have proven to work perfectly.  There is no need to adjust the difficulty manually, ever.  Info to the contrary is simply incorrect.  The pool targets 32 shares per minute.  This ensures that a) You are never spinning your wheels, per se, working on too high of a difficulty work for your hash rate, b) ensures the pool gets sufficient shares from your miner to keep statistics variance low so that stats are still valid, c) makes it so you don't have to ever actually change anything since pool does it for you, and many other advantages over a static difficulty.

I will most likely be scrapping the manual difficulty setting option, since after much research and testing, it simply has no real purpose.

Basically, if you're setting a static difficulty on another pool and you're getting a better hash rate, either you've been fooled by variance or the pool is lying.

-wk

thanks, well explained, happy to stay with Eligius!

[RoadTrain]

So, are the bitcoin transaction fees (or a precentage of them) paid to the miners?  and if so,  how does this work in detail?

Shares are paid from newest to oldest until block subsidy+fees is paid.

[Luke-Jr]

Is the 32 share per minute target per-worker or per-address?  Knowing that could help some configurations and allow the miner some flexibility in optimizing their configuration.

Per worker.

[t1000]

Why is the payout queue empty?

[wizkid057]

Why is the payout queue empty?

Because I want to keep all of the coins to myself today </troll>

Just kidding.  Just a fail-safe event from block 269074... for some reason the core database got a little lagged around that time and the CPPSRB code paused pending my doubling checking of everything.  I have it catching up now and the payout queue should be back to normal soon.  (Looks like about 90 minutes).

-wk

[robix]

Why is the payout queue empty?

Because I want to keep all of the coins to myself today </troll>

Just kidding.  Just a fail-safe event from block 269074... for some reason the core database got a little lagged around that time and the CPPSRB code paused pending my doubling checking of everything.  I have it catching up now and the payout queue should be back to normal soon.  (Looks like about 90 minutes).

-wk

[t1000]

  Thank you wizkid057.