Topic: Eligius Miners: [POLL] Proposed changes to Eligius Reward System (Read 11727 times)
Wow. So greater than 50% of people (more than 60%, actually) have voted in favor of "active mining" variant, but still no dice.
August 10, 2012, 04:02:32 PM
PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks. Can still hop on short blocks.
This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.I'm not sure what I've done to deserve your distrust, but I honestly spent some time thinking about these things.
Edit: Ok, I will stop derailing the thread. I'll be happy to continue discussing PPLNS in an on-topic thread such as PPLNS.
I like you sexy PPLNS talk...my thread or yours! Great stuff Meni...
August 10, 2012, 04:01:01 PM
Regardless of which MPPS variant you decide on, a hybrid PPS-SMPPS with a 2% fee would reduce the average 100 round maturity time by 20% and the average 200 round maturity time by 28%. The longer it goes, the lower the average maturity time until it would be on average very close to 1 round. You'd still have long runs of bad luck that would increase the time to payment maturity, but there would be no risk to Luke-jr and significant benefits to miners.
Of course, Eligius has been a free pool for so long there would be significant resistance to a 2% fee. What miners should realise is that they would have more btc sooner, and there is a significant time value of money in the current high interest btc market.
Of course, Eligius has been a free pool for so long there would be significant resistance to a 2% fee. What miners should realise is that they would have more btc sooner, and there is a significant time value of money in the current high interest btc market.
Brilliant!
August 09, 2012, 11:50:15 AM
When does the polling close and any changes that are going to take place take place? It's been running around 5 days now.
August 08, 2012, 06:51:32 AM
It could be possible to make some sort of Swap instrument,
that is valid for the next x blocks,
where you have a % fee that goes to the holders of this swap as payment for risk, and that any credit in unlucky times is financed from the pool of paid in coins by the buyers of the swap.
When there are lucky period money is added to the pool, when there are unlucky periods money is deduced from the pool.
at the end of the x blocks, buyers of the swap are paid back the remaining pool + the % fee.
Then a new offering is made for the next x blocks.
That way you finance a pool of money that can promptly pay out, and the risk of an unlucky period is taken by the buyers of this swap.
An there are probably investors ready since the pool has credibility compared to other investments opportunities in bitcoin.
that is valid for the next x blocks,
where you have a % fee that goes to the holders of this swap as payment for risk, and that any credit in unlucky times is financed from the pool of paid in coins by the buyers of the swap.
When there are lucky period money is added to the pool, when there are unlucky periods money is deduced from the pool.
at the end of the x blocks, buyers of the swap are paid back the remaining pool + the % fee.
Then a new offering is made for the next x blocks.
That way you finance a pool of money that can promptly pay out, and the risk of an unlucky period is taken by the buyers of this swap.
An there are probably investors ready since the pool has credibility compared to other investments opportunities in bitcoin.
August 06, 2012, 03:16:10 AM
Regardless of which MPPS variant you decide on, a hybrid PPS-SMPPS with a 2% fee would reduce the average 100 round maturity time by 20% and the average 200 round maturity time by 28%. The longer it goes, the lower the average maturity time until it would be on average very close to 1 round. You'd still have long runs of bad luck that would increase the time to payment maturity, but there would be no risk to Luke-jr and significant benefits to miners.
Of course, Eligius has been a free pool for so long there would be significant resistance to a 2% fee. What miners should realise is that they would have more btc sooner, and there is a significant time value of money in the current high interest btc market.
Of course, Eligius has been a free pool for so long there would be significant resistance to a 2% fee. What miners should realise is that they would have more btc sooner, and there is a significant time value of money in the current high interest btc market.
August 05, 2012, 11:33:26 PM
I hope that merely by time-shifting it and terming it as 'Extra Credit' that there is not somehow a perceived lesser moral duty to pay it out??
+1
August 05, 2012, 11:18:09 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely.
No, this is dealing with Extra Credit (EC), not unpaid rewards.Wait.. do I detect a certain sense of magnanimity in your attitude to this 'Extra Credit'?
Let's not forget that this EC is required to bring the earnings of this pool up to rough equivalency with other pools.
It's surely part of the 'reward' - just shifted in time to even out the luck.
I hope that merely by time-shifting it and terming it as 'Extra Credit' that there is not somehow a perceived lesser moral duty to pay it out??
(when (if!?) the overall pool luck eventually provides the necessary funds that is)
August 05, 2012, 02:58:37 PM
Yes, exactly. I don't think the entire CPPSBAM description was read or was somehow misunderstood...
I think the problem was putting two proposals in one discussion thread.
August 05, 2012, 02:54:33 PM
So under CPPSBAM, every time I point my miners to a new eligius address... my old address will effectively be an 'inactive miner' and although the EC credit is there - it's effectively lost to me unless I point some hashing power there again??
That would be correct.
Yuck.
August 05, 2012, 03:43:41 AM
As long as that is the case, perhaps we should take another look at MPPS? The only reason we went with SMPPS AFAIK was because it allows mobility between addresses.
use ESMPPS
August 04, 2012, 04:09:13 PM
Correct me if I'm wrong.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
While it is true that if you split your mining between multiple addresses you will have to mine longer to reach the payout threshold. But even if you never reach the threshold, auto-payouts kick-in after a week of inactivity so that only means you'll get payed later, not less.
Ok. That will continue, right?
August 04, 2012, 04:01:30 PM
Where does rounding come into it?
By rounding I meant that fact, that you get paid in "chunks" (couldn't be otherwise). So creating an address is effectively not totally free, you'd be about -0.34 BTC on average just by having an extra address.
Sorry if I wasn't clear.
Correct me if I'm wrong.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
While it is true that if you split your mining between multiple addresses you will have to mine longer to reach the payout threshold. But even if you never reach the threshold, auto-payouts kick-in after a week of inactivity so that only means you'll get payed later, not less.
Ok. That will continue, right?
August 04, 2012, 03:58:30 PM
May I suggest switching to proportional ?
You may not.
Correct me if I'm wrong.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
While it is true that if you split your mining between multiple addresses you will have to mine longer to reach the payout threshold. But even if you never reach the threshold, auto-payouts kick-in after a week of inactivity so that only means you'll get payed later, not less.
August 04, 2012, 03:34:25 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
New address tax?
Yeah well, nothing significant, but whenever you create a new account you increase the cumulative rounding down. It's just a little, but it's something (you are on average (~0.67 BTC/2) * number_of_addresses overdue).
Correct me if I'm wrong.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
August 04, 2012, 03:21:20 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
New address tax?
Yeah well, nothing significant, but whenever you create a new account you increase the cumulative rounding down. It's just a little, but it's something (you are on average (~0.67 BTC/2) * number_of_addresses overdue).
Correct me if I'm wrong.
You aren't paid until you reach the threshold, and then you're only paid for what you mined up to that point. So, at any instant other than when you've just been paid, you're overdue an amount X, that's between 0 and the threshold (can be a bit more but let's forget about that). Statistically, you're overdue half the amount of the threshold on average, multiplied by the number of addresses.
August 04, 2012, 03:18:05 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
New address tax?
Yeah well, nothing significant, but whenever you create a new account you increase the cumulative rounding down. It's just a little, but it's something (you are on average (~0.67 BTC/2) * number_of_addresses overdue).
August 04, 2012, 03:14:44 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely.
No, this is dealing with Extra Credit (EC), not unpaid rewards.Ok.
It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
There is no "new address tax" right now... if there was, it wouldn't be a major downside to this proposal.I posted just a few minutes ago about that.
August 04, 2012, 03:11:43 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
New address tax?
Yeah well, nothing significant, but whenever you create a new account you increase the cumulative rounding down. It's just a little, but it's something (you are on average (~0.67 BTC/2) * number_of_addresses overdue).
August 04, 2012, 03:10:26 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely.
No, this is dealing with Extra Credit (EC), not unpaid rewards.It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
There is no "new address tax" right now... if there was, it wouldn't be a major downside to this proposal. August 04, 2012, 03:02:01 PM
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
New address tax?
August 04, 2012, 02:59:59 PM
May I suggest switching to proportional ?
August 04, 2012, 02:46:29 PM
One of Eligius's advantages is that you can create separate little stashes of 'virgin' coins. I would have thought this an appealing point of differentiation for Eligius against other pools.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
From a purely moral standpoint, I think refusing to pay inactive addresses is wrong. It's due payment for past work, it shouldn't be pushed back indefinitely. It also punishes the creation of new addresses, which beats one of the selling points of mining here ("virgin coins"). There is already a "new address tax", there shouldn't be any more.
August 04, 2012, 02:32:55 PM
Let's say we finally use CPPSBAM, inactive miners are pushed to be active again to receive their EC. Well, how we classify miners as active/inactive? If we consider only through a submitted share to classify inactive miner to be active miner, then folks we have problem when miners use this way to extend their activity period ( like a week in address' graph).
Actually, this makes me realize a benefit of the "activity limit": it fixes the problem of inactive miners not getting payouts after a week. August 04, 2012, 01:06:09 PM
Let's say we finally use CPPSBAM, inactive miners are pushed to be active again to receive their EC. Well, how we classify miners as active/inactive? If we consider only through a submitted share to classify inactive miner to be active miner, then folks we have problem when miners use this way to extend their activity period ( like a week in address' graph).
Well, the other piece to it is that you can only earn EC up to the amount of non-EC you earn each block. So if you're only submitting 1 share once a way, you'd only get paid 1 share of EC a week.
Yes, exactly. I don't think the entire CPPSBAM description was read or was somehow misunderstood...
August 04, 2012, 12:26:07 PM
Let's say we finally use CPPSBAM, inactive miners are pushed to be active again to receive their EC. Well, how we classify miners as active/inactive? If we consider only through a submitted share to classify inactive miner to be active miner, then folks we have problem when miners use this way to extend their activity period ( like a week in address' graph).
Well, the other piece to it is that you can only earn EC up to the amount of non-EC you earn each block. So if you're only submitting 1 share once a way, you'd only get paid 1 share of EC a week.
August 04, 2012, 12:21:28 PM
Let's say we finally use CPPSBAM, inactive miners are pushed to be active again to receive their EC. Well, how we classify miners as active/inactive? If we consider only through a submitted share to classify inactive miner to be active miner, then folks we have problem when miners use this way to extend their activity period ( like a week in address' graph).
August 04, 2012, 06:10:15 AM
...
Is everyone else just using a single payout address?
...
I do, but I'm certain some people use multiple addresses for various reasons. But the only real one I can think of is as a way for slower miners to force more frequent payouts (even at just 1 Hash per minute, you can get payed every week if you switch addresses weekly). But even then, you only need to cycle between a few addresses for this to work.Is everyone else just using a single payout address?
...
If you use different addresses from the same wallet, when you make a transfer, the client will use funds associated with multiple addresses to make up the total amount of the transfer, effectively binding those addresses in the public record.
If you use addresses from different wallets, then you increase the risk of loosing coins due to a mistake as you switch between wallets and an astute observer might still be able to link those addresses if you ever transfer their contents to a single account in order to make a larger payment.
...
There are times where a miner might have to stop mining for legitimate reasons (say winding down from mining for good) and if this happens to happen during a time of poor pool luck, they get screwed. There needs to be a mechanism that those people get caught up, even if its the lowest priority.
While the greed in me would like to encourage as many miners as possible to quit in order for the difficulty to go back down. Therefore anything that discourages potential quitters is a bad thing. The jerk in me finds it hard to sympathize with people who don't want anything to do with mining but still insist on maximum payment for past mining. I guess I would be fully satisfied if we could limit it to only miners in other pools quitting (at least until solo mining with a single GPU becomes a viable option again) There are times where a miner might have to stop mining for legitimate reasons (say winding down from mining for good) and if this happens to happen during a time of poor pool luck, they get screwed. There needs to be a mechanism that those people get caught up, even if its the lowest priority.
August 04, 2012, 12:56:48 AM
One of Eligius's advantages is that you can create separate little stashes of 'virgin' coins. I would have thought this an appealing point of differentiation for Eligius against other pools.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
I agree with this and I think a happy compromise could be:
EC is paid out to current miners first and if there's still remaining credit, then EC is paid off.
There are times where a miner might have to stop mining for legitimate reasons (say winding down from mining for good) and if this happens to happen during a time of poor pool luck, they get screwed. There needs to be a mechanism that those people get caught up, even if its the lowest priority.
August 03, 2012, 09:28:20 PM
One of Eligius's advantages is that you can create separate little stashes of 'virgin' coins. I would have thought this an appealing point of differentiation for Eligius against other pools.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
Its not that you have to mine a single address. The CPPSBAM method only effects inactive miners in times when there is no buffer available. So, during average or lucky times for the pool, you could still switch addresses without any negative effects.
August 03, 2012, 07:48:16 PM
One of Eligius's advantages is that you can create separate little stashes of 'virgin' coins. I would have thought this an appealing point of differentiation for Eligius against other pools.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
If you have to mine to a single address and then transfer coins on the blockchain - you tie these stashes together in the public record.
It wouldn't bother me if payout to inactive addresses was low precedence and slow.. but it should be automatic and complete.
August 03, 2012, 06:08:57 PM
So under CPPSBAM, every time I point my miners to a new eligius address... my old address will effectively be an 'inactive miner' and although the EC credit is there - it's effectively lost to me unless I point some hashing power there again??
That would be correct.It would be in your best interest to use the same address (and most do) to ensure steady payouts, even under the existing system.
Why? It should make no difference under SMPPS. August 03, 2012, 06:03:55 PM
So under CPPSBAM, every time I point my miners to a new eligius address... my old address will effectively be an 'inactive miner' and although the EC credit is there - it's effectively lost to me unless I point some hashing power there again??
That would be correct.
Is everyone else just using a single payout address?
It would be in your best interest to use the same address (and most do) to ensure steady payouts, even under the existing system.
-wk
August 03, 2012, 06:01:57 PM
So under CPPSBAM, every time I point my miners to a new eligius address... my old address will effectively be an 'inactive miner' and although the EC credit is there - it's effectively lost to me unless I point some hashing power there again??
Is everyone else just using a single payout address?
Hope I've misunderstood... not liking the way the vote is going.
Is everyone else just using a single payout address?
Hope I've misunderstood... not liking the way the vote is going.
August 03, 2012, 05:08:44 PM
It doesn't need a full poll system. Its two questions. It could be a code copy from namecoin signing with just a tweak. You sign one of two statements for each question.
I suppose. I could also sign a message and make a post here with my vote. Guess that goes against the whole anonymity thing, but, I'd love to hear comments on why someone voted a certain way.
Here's mine:
bitcoind verifymessage 1EXfBqvLTyFbL6Dr5CG1fjxNKEPSezg7yF G68d1ygLbfwAnQj7nswnWtl1jb94IQvj/DwpU8T6qh5V0txNayzdXJ8b3qkedpxOat64haj7mC6oPodBphzMER4= CPPSBAM
I will point out that Eligius has been my backup pool (I solo mine for fun), but, I support CPPSBAM.
-wk
August 03, 2012, 05:02:13 PM
It doesn't need a full poll system. Its two questions. It could be a code copy from namecoin signing with just a tweak. You sign one of two statements for each question.
August 03, 2012, 04:16:32 PM
Not true. Address signing. Just like you do to get namecoins.
I was making the point that Luke would specifically have to code a voting system in. Seems like extra work for something the forums can do without trouble. Only real problem is that pool hoppers could game the vote, but I doubt any of them care enough to even read the topic.
Why would he have to code it himself? There are ton of open source scripts or some that cost $5-10 on codecanyon.net that he could easily modify slightly and implant. It's seriously not hard as a web developer myself, the internet has a lot of scripts out their to use as a base.
5s google: http://pollcode.com
Would have to implement bitcoin signing and verification into any new or existing poll system, which would have to be coded.
Edit: The specific site mentioned, pollcode, would be completely useless since its run a 3rd party server... ie, no way to verify bitcoin address signatures.
Sorry but why do you need to check bitcoin signing / verification? You just need a page coded in pure html/js where users can vote and comment on any new suggestions. It needs nothing to do with "Bitcoins" or servers
If thats all that was wanted, then we're fine with the poll here on this forum.
If we were to setup a poll on the Eligius.st site, it would be for miners only. And since Eligius has no official miner accounts of any kind, to verify that they are in fact a miner they would need to sign a message with their private key for their bitcoin payment address. This has been discussed above...
-wk
August 03, 2012, 03:13:38 PM
Not true. Address signing. Just like you do to get namecoins.
I was making the point that Luke would specifically have to code a voting system in. Seems like extra work for something the forums can do without trouble. Only real problem is that pool hoppers could game the vote, but I doubt any of them care enough to even read the topic.
Why would he have to code it himself? There are ton of open source scripts or some that cost $5-10 on codecanyon.net that he could easily modify slightly and implant. It's seriously not hard as a web developer myself, the internet has a lot of scripts out their to use as a base.
5s google: http://pollcode.com
Would have to implement bitcoin signing and verification into any new or existing poll system, which would have to be coded.
Edit: The specific site mentioned, pollcode, would be completely useless since its run a 3rd party server... ie, no way to verify bitcoin address signatures.
Sorry but why do you need to check bitcoin signing / verification? You just need a page coded in pure html/js where users can vote and comment on any new suggestions. It needs nothing to do with "Bitcoins" or servers
August 03, 2012, 03:09:31 PM
Not true. Address signing. Just like you do to get namecoins.
I was making the point that Luke would specifically have to code a voting system in. Seems like extra work for something the forums can do without trouble. Only real problem is that pool hoppers could game the vote, but I doubt any of them care enough to even read the topic.
Why would he have to code it himself? There are ton of open source scripts or some that cost $5-10 on codecanyon.net that he could easily modify slightly and implant. It's seriously not hard as a web developer myself, the internet has a lot of scripts out their to use as a base.
5s google: http://pollcode.com
Would have to implement bitcoin signing and verification into any new or existing poll system, which would have to be coded.
Edit: The specific site mentioned, pollcode, would be completely useless since its run a 3rd party server... ie, no way to verify bitcoin address signatures.
August 03, 2012, 03:08:16 PM
Not true. Address signing. Just like you do to get namecoins.
I was making the point that Luke would specifically have to code a voting system in. Seems like extra work for something the forums can do without trouble. Only real problem is that pool hoppers could game the vote, but I doubt any of them care enough to even read the topic.
Why would he have to code it himself? There are ton of open source scripts or some that cost $5-10 on codecanyon.net that he could easily modify slightly and implant. It's seriously not hard as a web developer myself, the internet has a lot of scripts out their to use as a base.
5s google: http://pollcode.com
Or even better, setup a eligius forum for users to use and where latest announcements and polls can be added using MyBB / PHPBB / SMF (Free Forum Scripts)
August 03, 2012, 02:09:51 PM
I also don't think that consensus matters much in a technical problem like this. The decision should be taken by those with a better understanding of the problem, and I guess Luke is the main man. Then probably we can discuss it here and agree something, but democracy is not the way to solve engineering problems.
This is certainly true. I believe the pool operator has the implied right to do what they feel is needed to effectively run the pool, with or without any type of poll or voting. However, being more open about it (ie, here on a well known public forum related to the topic) is a much better idea IMO.
In the end, the final decision will certainly rest with Luke-Jr, however, on how to proceed. That said, I'd be willing to bet that the outcome of the poll would have significant weight in that decision.
---
In response to this line of posts:
It would be better if you made an page dedicated to this new system suggestion and a public poll / comment system on Eligius site itself rather then here as active users are more likely to participate their then sign up on this forum just to voice 1 opinion
Eligius payouts are psuedo-anonymous, so there isn't really a way to do this on their site. We don't have typical "miner accounts".
Not true. Address signing. Just like you do to get namecoins.
I had considered doing a voting system like this. However, after considering the pros and cons of such a system, in the end it really just wouldn't be much better than a vote here. A vote here is open, public, permanent, and simple for users. A vote as described using signing techniques is complicated to implement, doesn't guarantee the accuracy of the vote in any case, would be run on the site owned by the pool (someone could just say it was faked with no real way to defend that), and a slew of other reasons why it just isn't necessary.
Anyway, I hope everyone is actually reading this thread and considering all of the points of all of the options before voting. I've made it clear that I fully support CPPSBAM. I believe that if you support the pool, you should get awarded accordingly, and if you don't, then you don't. Seems like a pretty straightforward and very fair process to me.
-wk
As of now: "2012-08-03 15:11:42 - EC Limit/CPPS Votes: Y/Y [CPPSBAM]: 18 (46.15%) | Y/N [SMPPS w/EC Limit]: 7 (17.95%) | N/Y [CPPSEB]: 6 (15.38%) | N/N [No Changes]: 8 (20.51%) ||| Total of 39 votes ||| Overall in favor of CPPS: 24 (61.54%) | ... of EC rewarding limited to active miners: 25 (64.10%) ||| Cast your vote @ http://goo.gl/O6A9q"
August 03, 2012, 01:38:24 PM
Not true. Address signing. Just like you do to get namecoins.
I was making the point that Luke would specifically have to code a voting system in. Seems like extra work for something the forums can do without trouble. Only real problem is that pool hoppers could game the vote, but I doubt any of them care enough to even read the topic.
August 03, 2012, 01:15:57 PM
It would be better if you made an page dedicated to this new system suggestion and a public poll / comment system on Eligius site itself rather then here as active users are more likely to participate their then sign up on this forum just to voice 1 opinion
Eligius payouts are psuedo-anonymous, so there isn't really a way to do this on their site. We don't have typical "miner accounts".
Not true. Address signing. Just like you do to get namecoins.
August 03, 2012, 01:12:12 PM
It would be better if you made an page dedicated to this new system suggestion and a public poll / comment system on Eligius site itself rather then here as active users are more likely to participate their then sign up on this forum just to voice 1 opinion
Eligius payouts are psuedo-anonymous, so there isn't really a way to do this on their site. We don't have typical "miner accounts".
August 03, 2012, 12:21:38 PM
It would be better if you made an page dedicated to this new system suggestion and a public poll / comment system on Eligius site itself rather then here as active users are more likely to participate their then sign up on this forum just to voice 1 opinion
August 03, 2012, 04:20:00 AM
I'm going to review this tomorrow and I'll vote and also make my opinion public
but I just want to note right now - that whatever the best payout route is for eligius - I do not believe that a bitcointalk forum poll is the best system for determining who should have a say and how much of a say in what happens here
and I say that as someone who has (through the good and the bad) mined nearly exclusively with this pool for the better part of a year and always being in the top 5 for hashrate
I am not saying my vote should mean more than any other miner who has contributed extensively to this pool but I am saying that it should mean more than some random person who reads this thread
-Tom
http://eligius.st/~artefact2/7/1Cp8HBr3vtEAvQ1RqQhjbhGciYDapf3ATN
but I just want to note right now - that whatever the best payout route is for eligius - I do not believe that a bitcointalk forum poll is the best system for determining who should have a say and how much of a say in what happens here
and I say that as someone who has (through the good and the bad) mined nearly exclusively with this pool for the better part of a year and always being in the top 5 for hashrate
I am not saying my vote should mean more than any other miner who has contributed extensively to this pool but I am saying that it should mean more than some random person who reads this thread
-Tom
http://eligius.st/~artefact2/7/1Cp8HBr3vtEAvQ1RqQhjbhGciYDapf3ATN
Agreed. I haven't read enough about it to make an informed judgement, but in any case a poll here doesn't seem like the proper way to make a decision.
I also don't think that consensus matters much in a technical problem like this. The decision should be taken by those with a better understanding of the problem, and I guess Luke is the main man. Then probably we can discuss it here and agree something, but democracy is not the way to solve engineering problems.
August 03, 2012, 03:58:11 AM
sorry for the noob question, but what does EC actually stand for?
Extra Credit. http://eligius.st/wiki/index.php/Shared_Maximum_PPS August 03, 2012, 03:54:24 AM
sorry for the noob question, but what does EC actually stand for?
August 03, 2012, 12:17:54 AM
several months isn't 'a little bit of bad luck'.
It wasn't; the evidence points to Eligius having been the target of a block withholding attack. Luke-Jr posted this to bitcoin-dev about a week after Eligius started falling behind very badly:
http://article.gmane.org/gmane.comp.bitcoin.devel/1112
August 02, 2012, 11:23:29 PM
several months isn't 'a little bit of bad luck'.
It wasn't; the evidence points to Eligius having been the target of a block withholding attack. Luke-Jr posted this to bitcoin-dev about a week after Eligius started falling behind very badly:
http://article.gmane.org/gmane.comp.bitcoin.devel/1112
IMHO none of these payout tweaks does anything to fix the block withholding attack vulnerability; they just redistribute the pain. You should consider giving a 1% bonus to the submitter of the share-that-finds-a-block (deducted from everybody else's reward, of course) like P2Pool does. If you jack it up to 3% it means that a share-withholder only gets 97% of their submitted hashrate, which should at least make idiot jackasses think twice. The only penalty is that small-time miners only get PPS-level variance on 97% of their payout; the other 3% will have solo-miner-level variance.
I do not believe that a bitcointalk forum poll is the best system for determining who should have a say and how much of a say in what happens here… and I say that as someone who has (through the good and the bad) mined nearly exclusively with this pool for the better part of a year and always being in the top 5 for hashrate
Agreed, from someone who was always in the top 3 for six months (and the top continuous/non-bursty miner for several months) until switching Eligius to "backup" status in response to the payout trainwreck. But I guess you guys see people like me as "part of the problem".
August 02, 2012, 10:33:55 PM
I am not saying my vote should mean more than any other miner who has contributed extensively to this pool but I am saying that it should mean more than some random person who reads this thread
While in general, you're probably right. However, I think that due to the nature of Eligius's account-less service, tallying votes linked to individual miners (via message signing and such) would be troublesome for even some of the largest Eligius miners. I had considered writing up a setup to do just this, then realized that it just was too bothersome.
I think overall that even if non-miners vote after actually reviewing the poll that the consensus will be valid.
I've argued the merits of CPPSBAM on IRC several times today and convinced several miners that its the obvious choice. I believe that anyone with the pool's well being as a whole at heart when voting will see it the same way. If not, please give me the opportunity to attempt to convince you before voting.
In my opinion, if someone decides that the EC payout limit to active miners is a bad thing, that just means they are either an inactive Eligius miner or someone with some other self-serving benefit to vote against it.
An honest miner who mines the pool faithfully will not notice any negative effects from CPPSBAM, and these are the miners that I would say the pool wishes to attract and retain.
A pool hopper or someone who just bails on the pool after a bit of bad luck obviously wouldn't desire the change because it effectively bars them from receiving their extra credit rewards unless they actually support the pool. I honestly don't see how this is a bad thing.
Basically, if you're an honest, steady miner, CPPSBAM is the way to go.
-wk
August 02, 2012, 10:16:13 PM
I'm going to review this tomorrow and I'll vote and also make my opinion public
but I just want to note right now - that whatever the best payout route is for eligius - I do not believe that a bitcointalk forum poll is the best system for determining who should have a say and how much of a say in what happens here
and I say that as someone who has (through the good and the bad) mined nearly exclusively with this pool for the better part of a year and always being in the top 5 for hashrate
I am not saying my vote should mean more than any other miner who has contributed extensively to this pool but I am saying that it should mean more than some random person who reads this thread
-Tom
http://eligius.st/~artefact2/7/1Cp8HBr3vtEAvQ1RqQhjbhGciYDapf3ATN
but I just want to note right now - that whatever the best payout route is for eligius - I do not believe that a bitcointalk forum poll is the best system for determining who should have a say and how much of a say in what happens here
and I say that as someone who has (through the good and the bad) mined nearly exclusively with this pool for the better part of a year and always being in the top 5 for hashrate
I am not saying my vote should mean more than any other miner who has contributed extensively to this pool but I am saying that it should mean more than some random person who reads this thread
-Tom
http://eligius.st/~artefact2/7/1Cp8HBr3vtEAvQ1RqQhjbhGciYDapf3ATN
August 02, 2012, 09:39:12 PM
Well, between the time EC mode started and now, lets say there were X shares submitted. If the hash rate were still doubled, there would be 2X shares submitted now instead of X shares. That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted. So, since history shows that 1X shares did not get us out of the rut as of now, it is possible that 2X shares could have by now.
Flawed logic. Specifically "That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted." Its just as probable they could have been unlucky.
Its not flawed. What I said is 100% accurate, although it is from the optimistic view. The shares could have resulted in lucky rounds. You can not deny this. Just because they also could have been unlucky does not make my statement flawed.
You're right, it could. So why is a vague statement like this used as support for change?
August 02, 2012, 09:35:03 PM
Well, between the time EC mode started and now, lets say there were X shares submitted. If the hash rate were still doubled, there would be 2X shares submitted now instead of X shares. That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted. So, since history shows that 1X shares did not get us out of the rut as of now, it is possible that 2X shares could have by now.
Flawed logic. Specifically "That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted." Its just as probable they could have been unlucky.
Its not flawed. What I said is 100% accurate, although it is from the optimistic view. The shares could have resulted in lucky rounds. You can not deny this. Just because they also could have been unlucky does not make my statement flawed.
August 02, 2012, 09:26:25 PM
Well, between the time EC mode started and now, lets say there were X shares submitted. If the hash rate were still doubled, there would be 2X shares submitted now instead of X shares. That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted. So, since history shows that 1X shares did not get us out of the rut as of now, it is possible that 2X shares could have by now.
Flawed logic. Specifically "That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted." Its just as probable they could have been unlucky.
August 02, 2012, 03:29:29 PM
If we maintained hashrate we could possibly have been past this stroke of bad luck by now. Possibly not, but the odds would have been better.
-wk
-wk
Actually, no. If the pool had been lucky, the EC could have been paid off sooner. Maintaining the hashrate while the the pool was unlucky wouldn't get the pool out of the rut faster.
You could also say that since the pool continues to be unlucky, the loss of hash power has been a good thing because less EC has accrued as would have otherwise.
Well, between the time EC mode started and now, lets say there were X shares submitted. If the hash rate were still doubled, there would be 2X shares submitted now instead of X shares. That gives X extra shares which could have resulted in lucky rounds, but instead were never submitted. So, since history shows that 1X shares did not get us out of the rut as of now, it is possible that 2X shares could have by now.
Make sense? Luke's post summarizes this better I think anyway.
[Hash rate] does play a part in how quickly the variance ("luck") swings from one extreme to the other.
-wk
August 02, 2012, 02:43:05 PM
If we maintained hashrate we could possibly have been past this stroke of bad luck by now. Possibly not, but the odds would have been better.
-wk
-wk
Actually, no. If the pool had been lucky, the EC could have been paid off sooner. Maintaining the hashrate while the the pool was unlucky wouldn't get the pool out of the rut faster.
You could also say that since the pool continues to be unlucky, the loss of hash power has been a good thing because less EC has accrued as would have otherwise.
August 02, 2012, 01:58:01 PM
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance.
I agree with that statement. Looking at http://eligius.st/~artefact2/, hashrate appears to have dropped by about 50GH on average over the last month. Do you happen to have any longer term graphs tucked away anywhere?
I don't have a graph anywhere, but I suppose I could generate one, technically.
In any case, at the point the buffer flipped into extra credit we had over 550GH IIRC, meaning we easily lost over half of the hash power we originally had due to SMPPS extra credit mode.
-wk
-wk
August 02, 2012, 01:55:12 PM
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance.
I didn't say it determined luck, I said hash rate determines how long it'll take to get out of the rut, on average. If we maintained hashrate we could possibly have been past this stroke of bad luck by now. Possibly not, but the odds would have been better.
-wk
Edit: Whoops, didn't see that Luke had already responded to this more concisely than I.
August 02, 2012, 11:27:12 AM
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance.
I agree with that statement. Looking at http://eligius.st/~artefact2/, hashrate appears to have dropped by about 50GH on average over the last month. Do you happen to have any longer term graphs tucked away anywhere?
August 02, 2012, 11:24:56 AM
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance.
August 02, 2012, 11:21:06 AM
That being said, there is also the "the bigger the block, the more likely to be orphaned" problem that lost us 6 blocks before being caught. That has been addressed for the short term (making smaller blocks) and I am working on addressing it for the long term (patching the reference implementation to minimize block propagation time regardless of transaction count).
Thank you for this.
August 02, 2012, 11:19:32 AM
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
Certainly you aren't saying that hash rate determines luck. Otherwise, the little miners don't stand a chance.
August 02, 2012, 10:44:12 AM
several months isn't 'a little bit of bad luck'. perhaps something is broken and that should be addressed before changing the payout system?
Several months isn't a little bit, but it is within the normal expectations. How many months of a positive buffer did we have? That's no more likely than extra credit.That being said, there is also the "the bigger the block, the more likely to be orphaned" problem that lost us 6 blocks before being caught. That has been addressed for the short term (making smaller blocks) and I am working on addressing it for the long term (patching the reference implementation to minimize block propagation time regardless of transaction count).
August 02, 2012, 04:52:27 AM
PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks. Can still hop on short blocks.
This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.I'm not sure what I've done to deserve your distrust, but I honestly spent some time thinking about these things.
Edit: Ok, I will stop derailing the thread. I'll be happy to continue discussing PPLNS in an on-topic thread such as PPLNS.
August 02, 2012, 04:39:33 AM
I just want to briefly clarify CPPSBAM to those who may misunderstand it.
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
several months isn't 'a little bit of bad luck'. perhaps something is broken and that should be addressed before changing the payout system?
Honestly, I don't believe it would have been several months if we maintained the hash rate of the pool at the time the bad luck (orphans) started. It was a run of orphans that was the cause of the bad luck, then half of the pool left which pretty much increases the time to pull out of the rut insanely. CPPSBAM works against miners who leave the pool, plain and simple. If you don't want to mine the pool and support it, then you don't get paid. Easy as that. If you feel like supporting the pool later, then by all means "unlock" your EC.
-wk
August 02, 2012, 04:36:26 AM
I just want to briefly clarify CPPSBAM to those who may misunderstand it.
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
several months isn't 'a little bit of bad luck'. perhaps something is broken and that should be addressed before changing the payout system?
August 02, 2012, 04:35:13 AM
I just want to briefly clarify CPPSBAM to those who may misunderstand it.
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
It is a very fair system. It keeps a fairly steady flow of reward to active miners.
In good luck/positive buffer times, this is 100% PPS all the time.
In bad luck times, it more hastily rewards immediately active miners in a "you can't get more out then you put in" type setup.
The goal of CPPSBAM is to curb what has happened to Eligius over the past several months where the pool hits a little bit of bad luck in SMPPS, miners get a little less on payout due to extra credit and then leaving the pool only to make the loyal miners take longer to have the buffer catch up. CPPSBAM is specifically designed to reward the loyal miner who stays with the pool continuously. The "disloyal" miner does not technically lose anything since they can simply mine the pool in lucky times for a quick payout of all extra credit they have.
-wk
August 02, 2012, 04:25:40 AM
PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks. Can still hop on short blocks.
This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.Actually, turns out the document I had initially read on the topic was of an incorrect implementation. My mistake. However, it's still able to be hopped in any case, just not as easily or predictably.
-wk
August 02, 2012, 04:24:08 AM
If you're worried about rewarding current miners, then why aren't you suggesting CPPSRB?
Because that method still does not give the pool a way to catch up in unlucky rounds when miners are leaving the pool. Sure, it will more readily reward active miners in long stretches of bad luck.
In any case, CPPSBAM does not just throw away extra credit that inactive miners have earned. It just simply is not paid to them if they are not active. If they become active again, then they can easily be paid their extra credit as well as normal CPPS reward. See http://eligius.st/wiki/index.php/Capped_PPS#CPPS_with_Backpay_for_Active_Miners_.28CPPSBAM.29.
This is also why Eligius as a backup pool is not really effected by CPPSBAM. you're not losing out on earnings regardless. You would only be effected at all if you were to mine a lot on Eligius while in extra credit mode (ie bad luck times) and then stop mining completely, which is hitting on the miner loyalty issue CPPSBAM is designed to correct in the first place.
-wk
August 02, 2012, 03:07:47 AM
My exact vote was:
YES!!! (limit the extra credit)
...Limiting the EC should also deter pool hopping.
No (I guess?) -- do not change from SMPPS to CPPS with backpay
(or do... I don't care about that part)
...either way I'm fine with ANY change that limits the extra credit from being so slow to payout for active, hardworking miners.
YES!!! (limit the extra credit)
...Limiting the EC should also deter pool hopping.
No (I guess?) -- do not change from SMPPS to CPPS with backpay
(or do... I don't care about that part)
...either way I'm fine with ANY change that limits the extra credit from being so slow to payout for active, hardworking miners.
August 02, 2012, 02:42:23 AM
If you're worried about rewarding current miners, then why aren't you suggesting CPPSRB?
August 01, 2012, 11:32:57 PM
I know I shouldn't be posting here, but...
I know there's not much information content in me saying this, but I was trying to make each reward system look exactly as good as it is. The causality is "Hopping-proof is good -> I developed hopping-proof methods", not "I developed hopping proof methods -> I say hopping-proof is good".
Score-based methods pay out (roughly) according to actually received rewards so they don't have these problems.
Putting aside the false modesty: I understand math. Most people don't. If you want to follow the parts of my derivations that you can, and take my word for or query the parts that you don't, great. If not that's your choice but I'd appreciate not going around saying I have some malicious agenda.
Keeping in mind the author is trying to make specific reward systems look better than others.
Because the huge royalties I get from all the DGM pools allow me to change the laws of math? I know there's not much information content in me saying this, but I was trying to make each reward system look exactly as good as it is. The causality is "Hopping-proof is good -> I developed hopping-proof methods", not "I developed hopping proof methods -> I say hopping-proof is good".
SMPPS will always fail, statistically, just because any disruption in income will cause a "loss" that is statistically impossible to recover in the long term.
Which is basically what I've said, and if I understand the thread correctly this is now becoming visible in practice.PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks. Can still hop on short blocks.
This is false, PPLNS is hopping-proof. You probably misunderstood how PPLNS works (or misimplemented it), most likely thinking it only rewards shares from the current round.The score systems and other such systems seem to be tailored to the pool operator's profit, IMO.
This is false. The expected profit of the pool op in a score method is 0 (if the fee is 0).The issue with all payout systems is that disruptions in the income from blocks (orphans, mainly) throw off the equilibrium that is the heart of the SMPPS/CPPS/PPS/etc systems. This is why I propose that inactive miners not be paid their backpay if they are not mining for the pool. This gives the pool as a whole a small way to offset those disruptions by freeing up funds to pay backpay/extra credit during unlucky times. Without some way of doing so, all "100% PPS" systems will eventually fail, statistically.
In true PPS the op is paying from his own funds, and it is his business decision what fee to charge to compensate for the losses and risks.Score-based methods pay out (roughly) according to actually received rewards so they don't have these problems.
I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.
I'd heard of CPPS but I can't write about every crazy non-hopping-proof method someone comes up with.Putting aside the false modesty: I understand math. Most people don't. If you want to follow the parts of my derivations that you can, and take my word for or query the parts that you don't, great. If not that's your choice but I'd appreciate not going around saying I have some malicious agenda.
August 01, 2012, 10:51:28 PM
One comment about part /1/: I agree it is beneficial to limit paying extra credit to active miners first, but I would advise caution on how to classify 'inactive' miners. I use this pool as a backup pool, so my average hashrate is very low, and this pool would become useless to me if there was some arbitrary 'active' MH/s threshold other than '> 0'.
I think the best idea from part 1 is to limit the extra credit rewarded in a round to the amount of normal credit earned, this would automatically reward only active users, without any arbitrary minimums. I think it is also a 'fair' approach in that the rate of extra credit is directly proportional to the rate of active mining.
I think the best idea from part 1 is to limit the extra credit rewarded in a round to the amount of normal credit earned, this would automatically reward only active users, without any arbitrary minimums. I think it is also a 'fair' approach in that the rate of extra credit is directly proportional to the rate of active mining.
August 01, 2012, 04:32:58 PM
I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.
No, that paper does not specifically mention CPPS, however, I do not believe it is new. The specific page I linked describing it was created about a year ago.
It is a no-pool-risk low variance payout method, so, I suppose it would fall into whatever category in that paper you should see fit.
In my simulations, I pitted CPPS against SMPPS and CPPS always had a much higher chance of pulling out of a rut than SMPPS, mainly since the buffer was never grown substantially since on even or lucky rounds all miners are already fully paid. SMPPS plays a lot of catch up. Tacking on the CPPSBAM variant gives the pool a way to have even better odds of keeping a positive buffer for miner payouts.
-wk
August 01, 2012, 04:27:02 PM
I don't think the paper specifically references CPPS, and I haven't heard of it until now either, so I must assume it is something that has been developed recently. I will reserve judgement on it specifically for that reason until I can learn more about it.
August 01, 2012, 03:39:26 PM
Keeping in mind the author is trying to make specific reward systems look better than others.
Because they are better.I agree that this article does seem biased, and not just because of the numbers.
In any case, the numbers generally don't lie, and I've written a simulation to test many payout methods before proposing these changes.
For my personal analysis:
SMPPS will always fail, statistically, just because any disruption in income will cause a "loss" that is statistically impossible to recover in the long term. It is also not statistically compatible with the block reward halving while in EC mode.
Proportional is just flat out off the list due to obvious exploits of the system (hopping).
PPLNS has the same drawbacks as proportional except they're slightly offset for longer blocks. Can still hop on short blocks.
The score systems and other such systems seem to be tailored to the pool operator's profit, IMO.
CPPS variants are reasonable, as they mostly solve the problems of lowering variance, hopping, and miner loyalty.
The issue with all payout systems is that disruptions in the income from blocks (orphans, mainly) throw off the equilibrium that is the heart of the SMPPS/CPPS/PPS/etc systems. This is why I propose that inactive miners not be paid their backpay if they are not mining for the pool. This gives the pool as a whole a small way to offset those disruptions by freeing up funds to pay backpay/extra credit during unlucky times. Without some way of doing so, all "100% PPS" systems will eventually fail, statistically.
For example, if you bet any number in roulette in any large number of spins with no 0 or 00, on average, you'll break even. However, throw in even one of the 0 or 00 (to equate to bitcoin, orphaned blocks) and on average, you'll lose no matter what. http://en.wikipedia.org/wiki/Law_of_large_numbers
-wk
August 01, 2012, 03:24:44 PM
Keeping in mind the author is trying to make specific reward systems look better than others.
Because they are better. August 01, 2012, 03:23:50 PM
Keeping in mind the author is trying to make specific reward systems look better than others.
August 01, 2012, 03:19:40 PM
You should consider reading this carefully:
https://bitcoil.co.il/pool_analysis.pdf
https://bitcoil.co.il/pool_analysis.pdf
August 01, 2012, 03:12:30 PM
THIS POLL IS NOW SUPERSEDED BY THIS NEW POLL:
https://bitcointalk.org/?topic=100301
Please cast your votes on the new poll. Thanks.
------
After many discussions on IRC, I am putting to vote a change to the Eligius miner reward system.
I would prefer that, on the honor system, only Eligius miners with some amount of EC on their address vote on this poll.
This is a two part proposal. Please read carefully!
Background/Reasoning:
As of now, the pool has accrued a substantial amount of "extra credit" under the SMPPS system. This is causing reward payouts for active miners to be significantly lower than 100% PPS.
From what I can tell, a large portion of the "extra credit" is being slowly paid to miners who have stopped mining at the pool entirely, thus slowing the reward payout for active miners who are currently supporting the pool.
I believe that miners who support the pool through good and bad luck times should be rewarded and have a good chance of reaching 100% PPS. Recently, due to the pool's run of bad luck, many miners have left the pool. This makes it much harder for the remaining miners to catch up and pay the extra credit to the inactive miners, potentially to the point where it becomes statistically improbable. These proposals, if adopted, should provide a system which makes mining at Eligius, even during bad luck times, more reasonable and more enticing than the system as it exists now.
On a personal note, I recommend voting YES to both proposals. I believe that these changes will make the pool more viable in the long term and give miners, new and old, more incentive to mine at the pool.
----
Part 1
For the first part of this proposal, I propose that extra credit payments NOT be made to miners who are not actively mining at the pool. Further, I propose that extra credit reward payouts be adjusted like so:
- Miners who have an extra credit balance may not be paid more extra credit in a round than they have earned normally for the round. (For example, if you have 1 BTC in EC, and you mine 0.1 BTC in shares, the biggest reward payout you can get from that block would be 0.2 BTC (your earnings plus and equal amount of your extra credit)).
- The extra credit that is not able to be paid to a miner (inactive, low hash rate, etc) under this system will be added to the available funds for paying active miner extra credit.
This setup rewards active miners during unlucky times (such as now) over those who have stopped supporting the pool.
If you believe this is reasonable, then vote "Yes EC Limit".
For details on SMPPS please see http://eligius.st/wiki/index.php/Shared_Maximum_PPS.
-----
Part 2
As the second part of this proposal, I propose that Eligius switches to a reward system based on CPPS with backpay rather than SMPPS. On average, this should get miners the same amount as SMPPS. The advantage is that even when the pool is having a run of bad luck, when the pool is lucky for even one block, you will get 100% PPS for that block.
Please read http://eligius.st/wiki/index.php/Capped_PPS for details on CPPS.
I propose that if you agree with the above proposal AND CPPS with backpay that Eligius implement "CPPSBAM" as described in the link above, which rewards only active miners.
If you agree with CPPS with backpay, but not only for active miners, then I propose we use "CPPSEB" as described in the link above.
For the vote, if you agree with CPPS with backpay, please vote an option with "Yes CPPS".
----
Any questions or clarification please post or see us on freenode in #eligius. I'd be happy to answer questions.
Thanks!
-wk
P.S. - I just want to point out to clear up some misunderstandings that no miners will ever lose any earned extra credit under any of the proposed reward systems. *Please* read http://eligius.st/wiki/index.php/Capped_PPS#CPPS_with_Backpay_for_Active_Miners_.28CPPSBAM.29 carefully! It specifically explains that even inactive miners never lose their extra credit under CPPSBAM.
Edit: Clarification that this is for the miner reward system (initially ambiguously referred to as payout system)
Edit: Added P.S. to emphasize CPPSBAM does not mean losing extra credit.
Jump to: