This is all too confusing :-)
I'm a miner with around 900Mh and I constantly mine on Eligius on same fixed address all the time without any interruption and have been for many months.
Given this, does it matter at all which way I vote here?
Will
Topic: Eligius POLL: Reward system changes, and new ASIC-ready Eligius-Hu pool - page 3. (Read 9655 times)
August 13, 2012, 06:41:33 PM
August 13, 2012, 05:38:42 PM
twmz's page includes "estimated" earnings for the next block, so it's not too useful here.
Whatever is "unpaid balance" is yours and guaranteed to be paid out eventually, no later than a month after the pool closes (but probably sooner), regardless of amount.
Whatever is "unpaid balance" is yours and guaranteed to be paid out eventually, no later than a month after the pool closes (but probably sooner), regardless of amount.
August 13, 2012, 04:03:19 PM
http://eligius.st/~twmz/
Currently, at the time of my posting this, 7 blocks worth of "paid" payouts which are owed, but haven't yet gone out in coinbase of the generated blocks... Then we have the artefact2 stats for all the pool miners (various "green" amounts, not the "pink" extra credit area)
For anything which is paid / unpaid (anything green-ish color that is below the 0.67 threshold) I'm wondering how will the current payout queue (as listed in twmz) be paid, as well as green "unpaid" area...
... as well as any miners stuck in inactive limbo. If there is already a 7 block backlog, is 8 blocks worth of shares going to be sufficient window to pay the various pool obligations? When the mining switches over, who gets paid what first, and what happens if the pool can't meet obligations within 8 blocks?
Which pay amounts will be "oops, lost forever" (shares which are 8 blocks or more old)?
... maybe I'm just not understanding the transition from current balances owed (non-pink / non-EC) to the new "only shares in the last 8 blocks" will be implemented.
Or maybe an easier question (one I can articulate better) If someone is mining less than 0.67 BTC in any 8 block window, what happens to their shares?
Currently, at the time of my posting this, 7 blocks worth of "paid" payouts which are owed, but haven't yet gone out in coinbase of the generated blocks... Then we have the artefact2 stats for all the pool miners (various "green" amounts, not the "pink" extra credit area)
For anything which is paid / unpaid (anything green-ish color that is below the 0.67 threshold) I'm wondering how will the current payout queue (as listed in twmz) be paid, as well as green "unpaid" area...
... as well as any miners stuck in inactive limbo. If there is already a 7 block backlog, is 8 blocks worth of shares going to be sufficient window to pay the various pool obligations? When the mining switches over, who gets paid what first, and what happens if the pool can't meet obligations within 8 blocks?
Which pay amounts will be "oops, lost forever" (shares which are 8 blocks or more old)?
... maybe I'm just not understanding the transition from current balances owed (non-pink / non-EC) to the new "only shares in the last 8 blocks" will be implemented.
Or maybe an easier question (one I can articulate better) If someone is mining less than 0.67 BTC in any 8 block window, what happens to their shares?
August 13, 2012, 02:38:36 PM
BTW, speaking of ASICs and gmp, can someone (Luke-Jr perhaps?) give estimates of bandwidth usage for getwork and using gmp-proxy on a per GH/s basis? Here is an old stack exchange article). Are there any plans for difficulty 10, 100, N, shares a la p2pool? How does bandwidth compare to p2pool?
I haven't done any bandwidth measurement at all. My plan at this time is to send new work every 2 minutes via BIP22, and dynamically adjust the target based on each miners' hashrate to aim for 1 or 2 shares per minute on average. August 13, 2012, 02:19:48 PM
BTW, speaking of ASICs and gmp, can someone (Luke-Jr perhaps?) give estimates of bandwidth usage for getwork and using gmp-proxy on a per GH/s basis? Here is an old stack exchange article). Are there any plans for difficulty 10, 100, N, shares a la p2pool? How does bandwidth compare to p2pool?
I haven't done any bandwidth measurement at all. My plan at this time is to send new work every 2 minutes via BIP22, and dynamically adjust the target based on each miners' hashrate to aim for 1 or 2 shares per minute on average. 
August 13, 2012, 02:17:11 PM
Yes, I forgot about the important ones - generated payouts and getmemorypool that streblo pointed out.
August 13, 2012, 02:15:23 PM
Wow, a lot of hate for PPLNS? Why?
Might be something to do with your x8 implementation sounding somewhat novel and untested? It sounds to me like an interesting concept though.At this point, Eligius is no longer the only pool that allows a miner to mine anonymously with just a bitcoin address - other than the stats graphs, I'm not sure what is unique about it now that may have been previously.
Well, there are other pools with almost all Eligius's features by now, yes, but I don't think any that have all of them. The closest is p2pool, and that has all the problems p2p entails and a very high variance. With Eligius-Hu, we will also be the first ASIC ready pool.- Zero fee
- Zero setup
- Low variance
- ASIC ready
- Generated payouts
- Decentralized block creation
- Hopper friendly
- Open development
- ... probably others I forget off the top of my head
August 13, 2012, 02:12:44 PM
Wow, a lot of hate for PPLNS? Why?
Might be something to do with your x8 implementation sounding somewhat novel and untested? It sounds to me like an interesting concept though.At this point, Eligius is no longer the only pool that allows a miner to mine anonymously with just a bitcoin address - other than the stats graphs, I'm not sure what is unique about it now that may have been previously.
Do many other anonymous pools support getmemorypool, namely gmp-proxy.py? That may be another unique feature of Eligius (right now the biggest 'feature' is the EC drain
)BTW, speaking of ASICs and gmp, can someone (Luke-Jr perhaps?) give estimates of bandwidth usage for getwork and using gmp-proxy on a per GH/s basis? Here is an old stack exchange article). Are there any plans for difficulty 10, 100, N, shares a la p2pool? How does bandwidth compare to p2pool?
August 13, 2012, 01:59:47 PM
Wow, a lot of hate for PPLNS? Why?
Might be something to do with your x8 implementation sounding somewhat novel and untested? It sounds to me like an interesting concept though.At this point, Eligius is no longer the only pool that allows a miner to mine anonymously with just a bitcoin address - other than the stats graphs, I'm not sure what is unique about it now that may have been previously.
August 13, 2012, 01:52:09 PM
Wow, a lot of hate for PPLNS? Why?
August 13, 2012, 01:39:28 PM
Edit: Note that with the Active Miners rule enabled, ex-miners who have unpaid balances under 0.67 BTC will finally reach the 1 week inactivity and get their payout. Also note that when Eligius-Ra finally closes, all unpaid balances (not EC!) will be paid out regardless of the amount.
August 13, 2012, 10:38:46 AM
Is there an 'end date' for this poll? If any/all of these proposals are adopted, what are the timelines like?
Unknown right now. Depends on my free time.The elimination of this database means the current Artefact2 stats will not work with this new pool unless someone steps up to update it.
That is a real bummer. The Eligius statistics graphs are an awesome, awesome tool for debugging miner software, especially performance problems that appear and disappear intermittently. I really hope the graphs stay.
Somebody may want to update the link in the announcement at the top of the stats page.
Good idea, done!Eligius-Su? Wasn't that deactivated 6 months ago? The stats show the current server as Eligius-Ra.
Ouch, now I feel stupid. Fixed. August 13, 2012, 10:02:07 AM
Eligius-Su? Wasn't that deactivated 6 months ago? The stats show the current server as Eligius-Ra.
August 13, 2012, 09:49:08 AM
Somebody may want to update the link in the announcement at the top of the stats page.
August 13, 2012, 04:42:59 AM
This sounds like a good strategy. I understand the desire to engineer the ultimate-in-fairness payout algorithm, but at some point it becomes too difficult for miners to figure out what 1 BTC of EC is worth (0.99BTC in my wallet? 0.97BTC? 0.0BTC if the pool goes away?) and that uncertainty itself is a cost. Ensuring that any uncertainty is resolved after at most Dx8 shares is a big positive.
That is a real bummer. The Eligius statistics graphs are an awesome, awesome tool for debugging miner software, especially performance problems that appear and disappear intermittently. I really hope the graphs stay.
The elimination of this database means the current Artefact2 stats will not work with this new pool unless someone steps up to update it.
That is a real bummer. The Eligius statistics graphs are an awesome, awesome tool for debugging miner software, especially performance problems that appear and disappear intermittently. I really hope the graphs stay.
August 13, 2012, 12:57:52 AM
Is there an 'end date' for this poll? If any/all of these proposals are adopted, what are the timelines like?
August 12, 2012, 10:02:42 PM
Note that the poll accepts votes for multiple items, and you can change your votes at any time (Edit: not anymore, thanks to this forum being buggy...). Please only vote if you meet the criteria for the options! Feel free to ask any questions in the thread...
After much discussion, I am leaning toward this two-part plan (or something like it)...
1. Setup new Eligius-Hu pool
This will have the PPLNS×8 reward system: when a block is found, its reward is divided equally* across the last times 8 shares. The number of shares has been chosen to be times 8 so that there is a 99.9% chance of any given share being paid; on average, each share will be paid 8 times.
That means that at the current difficulty 2,190,865, a block found today would reward 0.0000028527545056404662 BTC for each of the 17,526,920 shares preceding it, regardless of what "round" those shares were found in. After 8 blocks, assuming they are all within those 17,526,920 shares since the share was submitted, that share will have been paid a total of 0.00002282203604512373 BTC (equivalent to 100% PPS). If the pool gets lucky or unlucky, we might find more or less blocks within that window, all of which the share is paid for. This does potentially increase variance a bit, but an 8 block window should be enough to minimize it.
This summary is slightly inaccurate, as the shares will be of dynamic difficulty depending on your hashrate, and the value of each share will depend on your share-difficulty and the current block difficulty at the time the share is submitted, to avoid being hoppable during difficulty changes, and gracefully scale to ASICs as they are available.
There will also be a few under-the-hood changes to handle ASICs on Eligius-Hu: (new) BIP22 mining protocol support, and elimination of the permanent eternally-growing share database. The elimination of this database means the current Artefact2 stats will not work with this new pool unless someone steps up to update it. wizkid057 plans to write an updated stats interface.
You can express your support for this new pool only if you plan to use it by voting for the first poll option ("new Eligius-Hu"). If you are a current Eligius-Ra miner, and plan to leave the pool because you don't like Eligius-Hu, vote "dislike Hu" (option 5).
The default pool for the mining.eligius.st hostname will be changed to Eligius-Hu about a week after it goes live (miners can specify an explicit pool to use with the ra.mining.eligius.st or hu.mining.eligius.st hostnames). If you plan to mine on either Eligius-Ra or Hu at that time, and think the default should be changed immediately upon its availability, vote "Hu default" (option 2). If you explicitly think waiting a week more is a good idea, you can vote "Extra week at Ra" (option 6). Regardless of these votes, hu.mining.eligius.st is currently functional as a redirect to Ra, and will switch to Hu immediately when it comes online.
2. Gradual shutdown of Eligius-Ra pool
Since PPLNS×8 does not allow for carryover of existing Extra Credit (EC), Eligius-Ra will continue to operate until the block subsidy halves to 25 BTC (I would need to rewrite the pool software to make it survive the 25 BTC drop). Because of the near Miners who have a lot invested in EC may wish to continue to mine Eligius-Ra until it has been paid to their satisfaction.
Due to the extreme improbability of Eligius-Ra catching up to 100% PPS in this timeframe, it is proposed that it be changed to "SMPPSAM" (ie, an Active Miners variant) until it closes: this would mean inactive miners on Ra would not receive EC until/unless all the active miners are paid an amount equal to their current earnings first. Miners who have EC on Eligius-Ra or plan to be mining on it at that time may vote to support (option 3) or oppose (option 4) the Active Miners rule.
Edit: Note that with the Active Miners rule enabled, ex-miners who have unpaid balances under 0.67 BTC will finally reach the 1 week inactivity and get their payout. Also note that when Eligius-Ra finally closes, all unpaid balances (not EC!) will be paid out regardless of the amount.
Please note that Eligius-Ra may not be updated to handle ASIC load!
Poll option G is for future use should someone propose any other changes: do not vote on it until it is defined. If you have any possibly better ideas, please do bring them up!
After much discussion, I am leaning toward this two-part plan (or something like it)...
1. Setup new Eligius-Hu pool
This will have the PPLNS×8 reward system: when a block is found, its reward is divided equally* across the last
That means that at the current difficulty 2,190,865, a block found today would reward 0.0000028527545056404662 BTC for each of the 17,526,920 shares preceding it, regardless of what "round" those shares were found in. After 8 blocks, assuming they are all within those 17,526,920 shares since the share was submitted, that share will have been paid a total of 0.00002282203604512373 BTC (equivalent to 100% PPS). If the pool gets lucky or unlucky, we might find more or less blocks within that window, all of which the share is paid for. This does potentially increase variance a bit, but an 8 block window should be enough to minimize it.
This summary is slightly inaccurate, as the shares will be of dynamic difficulty depending on your hashrate, and the value of each share will depend on your share-difficulty and the current block difficulty at the time the share is submitted, to avoid being hoppable during difficulty changes, and gracefully scale to ASICs as they are available.
There will also be a few under-the-hood changes to handle ASICs on Eligius-Hu: (new) BIP22 mining protocol support, and elimination of the permanent eternally-growing share database. The elimination of this database means the current Artefact2 stats will not work with this new pool unless someone steps up to update it. wizkid057 plans to write an updated stats interface.
You can express your support for this new pool only if you plan to use it by voting for the first poll option ("new Eligius-Hu"). If you are a current Eligius-Ra miner, and plan to leave the pool because you don't like Eligius-Hu, vote "dislike Hu" (option 5).
The default pool for the mining.eligius.st hostname will be changed to Eligius-Hu about a week after it goes live (miners can specify an explicit pool to use with the ra.mining.eligius.st or hu.mining.eligius.st hostnames). If you plan to mine on either Eligius-Ra or Hu at that time, and think the default should be changed immediately upon its availability, vote "Hu default" (option 2). If you explicitly think waiting a week more is a good idea, you can vote "Extra week at Ra" (option 6). Regardless of these votes, hu.mining.eligius.st is currently functional as a redirect to Ra, and will switch to Hu immediately when it comes online.
2. Gradual shutdown of Eligius-Ra pool
Since PPLNS×8 does not allow for carryover of existing Extra Credit (EC), Eligius-Ra will continue to operate until the block subsidy halves to 25 BTC (I would need to rewrite the pool software to make it survive the 25 BTC drop). Because of the near Miners who have a lot invested in EC may wish to continue to mine Eligius-Ra until it has been paid to their satisfaction.
Due to the extreme improbability of Eligius-Ra catching up to 100% PPS in this timeframe, it is proposed that it be changed to "SMPPSAM" (ie, an Active Miners variant) until it closes: this would mean inactive miners on Ra would not receive EC until/unless all the active miners are paid an amount equal to their current earnings first. Miners who have EC on Eligius-Ra or plan to be mining on it at that time may vote to support (option 3) or oppose (option 4) the Active Miners rule.
Edit: Note that with the Active Miners rule enabled, ex-miners who have unpaid balances under 0.67 BTC will finally reach the 1 week inactivity and get their payout. Also note that when Eligius-Ra finally closes, all unpaid balances (not EC!) will be paid out regardless of the amount.
Please note that Eligius-Ra may not be updated to handle ASIC load!
Poll option G is for future use should someone propose any other changes: do not vote on it until it is defined. If you have any possibly better ideas, please do bring them up!
Jump to: