Bitcoin Forum
March 29, 2024, 06:20:34 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 »
  Print  
Author Topic: [350 GH/s] "Eligius" (experimental) pool: almost feeless PPS, hoppers welcome  (Read 116918 times)
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 15, 2011, 08:02:20 PM
 #601

Base payouts on exactly the last N shares submitted, where N < the expected number of shares that will yield one block.

Yes, that means on a long round that takes for example 3N shares to reach, there's no credit at all for the first 2N shares submitted. Tough cookies. They had as much a chance as any other to be rewarded, there was no way to know in advance they wouldn't, and there's no incentive to leave after contributing them because the future is unknown and has as much positive expectation as ever. Ignore Sunk Costs.

What if a round takes less than N shares, say N/2 shares? Reach back to the previous N/2 shares – those that already paid out once – and pay them again. This situation too was just as unpredictable as the chance the next N shares will yield no blocks, so people can't gain any advantage by timing their entry or departure.
Already thought of this. Someone pointed out it's even less fair than the score-based approaches.

Only making the expected return per next-share-contributed be totally independent of the pool history/round-lengths can strategic entry/exit be made profitless. One way to do this is to pay a fixed amount per share no matter what the relation to successful blocks.. but that requires the pool to have a reserve and insure the long dry spells.
MaxPPS is like this, but makes the "reserve" per-user so they can't cheat the pool by withholding blocks.

Underpayments on the long blocks will be made up retroactively regardless of whether a miner has continued on the pool or not.
Then how does this punish pool hoppers?  It just delays their payout, but does not diminish it?
It's not supposed to punish pool hoppers (it's their right to hop-- so punishing them would be wrong). They simply don't earn any more than someone mining normally, so there's no incentive to do it.

1. Would it be possible to combine the earnings of both pools so those of us mining on slower rigs can reach the 1 BTC cash-out amount quicker?
The "big upgrade" I'm working on will be able to combine the pools to work together. The minimum payout will also likely be reduced.

In the US pool, there is mention of two different metrics: value and earnings.  When I check the http://eligius.st/~artefact2/us/ website, I can only see my unpaid reward, which is basically the total of the lowest of both value and earnings.

2. Would it be possible to display both the earnings and the value in the report so I have an idea how much more BTC I can expect to gain on future long blocks?
This is planned for the permanent version of MaxPPS.

I think one complaint people have is the lack of transparency we have in the process.  Your US pool's HDD was running out of space, so you shut it out.  You mentioned it would be good for another 48 hours, then a few moments later you shut it down anyways.  Those 48 hours would've made the difference for me and I'm sure many others of getting near the the minimum payment quota.  You gave us no ETA on when the US pool will be re-opened, which is a first step for us to begin mining so we can generate enough shares to get our first payment.
It was running out of space fast, and I had the opportunity to move it somewhere relatively quickly (~12 hours). All real-time discussion, including what's going on with the pools, takes place in our IRC channel.

Is the EU pool at risk of closing down due to lack of HDD space also?
The Europe server is far more powerful and has far more space than the US server. I'm not worried about it.


1711693234
Hero Member
*
Offline Offline

Posts: 1711693234

View Profile Personal Message (Offline)

Ignore
1711693234
Reply with quote  #2

1711693234
Report to moderator
1711693234
Hero Member
*
Offline Offline

Posts: 1711693234

View Profile Personal Message (Offline)

Ignore
1711693234
Reply with quote  #2

1711693234
Report to moderator
In order to achieve higher forum ranks, you need both activity points and merit points.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Katapult
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
June 15, 2011, 08:06:50 PM
 #602

Thanks for the replies Luke, I'm glad to see the big upgrade will solve those issues.  I'll try to find the IRC channel so I can follow the discussions live.
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 15, 2011, 08:47:12 PM
 #603

Base payouts on exactly the last N shares submitted, where N < the expected number of shares that will yield one block.

Yes, that means on a long round that takes for example 3N shares to reach, there's no credit at all for the first 2N shares submitted. Tough cookies. They had as much a chance as any other to be rewarded, there was no way to know in advance they wouldn't, and there's no incentive to leave after contributing them because the future is unknown and has as much positive expectation as ever. Ignore Sunk Costs.

What if a round takes less than N shares, say N/2 shares? Reach back to the previous N/2 shares – those that already paid out once – and pay them again. This situation too was just as unpredictable as the chance the next N shares will yield no blocks, so people can't gain any advantage by timing their entry or departure.
Already thought of this. Someone pointed out it's even less fair than the score-based approaches.


How is it unfair? Can you explain or provide a link or query that would find prior discussion?

I think it's like a score system but with a hard cliff for shares over a certain age (in share ticks), rather than slow decay.

Another benefit would be that less state is required to calculate payouts, because you only need a fixed-size rolling window of the last N shares to calculate payout on the next hit. Fewer disk space problems!

For people who believe that a long round means a pool is 'due' (a fallacy but popular), it might even encourage participation in long rounds.

The only way I can see it being considered unfair is if there's a belief that every share needs to actually earn something, no matter how far removed it is from a success, rather than just earn a equal chance at something. But if that is a strong belief, just go with Deepbit-style pay-per-share. Other hard-to-understand improvised blended models create gaming opportunities for miners or the pool operator.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 15, 2011, 08:57:04 PM
 #604

The only way I can see it being considered unfair is if there's a belief that every share needs to actually earn something, no matter how far removed it is from a success, rather than just earn a equal chance at something. But if that is a strong belief, just go with Deepbit-style pay-per-share. Other hard-to-understand improvised blended models create gaming opportunities for miners or the pool operator.
Straight PPS is vulnerable to withholding attack due to infinite risk for the pool operator.

HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 15, 2011, 09:07:27 PM
 #605

The only way I can see it being considered unfair is if there's a belief that every share needs to actually earn something, no matter how far removed it is from a success, rather than just earn a equal chance at something. But if that is a strong belief, just go with Deepbit-style pay-per-share. Other hard-to-understand improvised blended models create gaming opportunities for miners or the pool operator.
Straight PPS is vulnerable to withholding attack due to infinite risk for the pool operator.

Not straight PPS; the proposal I made. For distinction let's call it Pay-Per-Last-N-Shares (PPLNS).

There's no risk to the pool operator, they only pay when there's a hit, and they always pay exactly the last N shares received. Earlier shares get nothing.

There's no increased or decreased return to any miner based on time of entry or exit, because payouts have nothing to do with past history or the length of the current round or the pool operator's reserves or whatever.

My initial intuition was N could be any number up to the average number of shares expected to yield a hit, but on further thought, I think N can be anything so long as it is constant. Exercise left to the reader.
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 15, 2011, 09:22:24 PM
 #606

Only making the expected return per next-share-contributed be totally independent of the pool history/round-lengths can strategic entry/exit be made profitless. One way to do this is to pay a fixed amount per share no matter what the relation to successful blocks.. but that requires the pool to have a reserve and insure the long dry spells.
MaxPPS is like this, but makes the "reserve" per-user so they can't cheat the pool by withholding blocks.

So it shows as earnings, but they're on hold indefinitely until you work some more? An amount held hostage to ensure loyalty?

Seems a lot like scrip you can only spend at the company store – an abusive practice from the old company/mining towns of yore.

Strongly, strongly dislike this MaxPPS as described. Seems against the transparency/instantness that was the initial appeal of Eligius.

I can see how for a miner that commits to Eligius for 'now and forever' it eventually evens out to about the same as pure PPS (or PPLNS). But my guess is miners as a group have a very large discount rate given all the levels of uncertainty in the bitcoin economy, so a system that requires an indefinite commitment to get full returns will have a small audience.
Yeti
Member
**
Offline Offline

Activity: 112
Merit: 10

Firstbits: 1yetiax


View Profile
June 15, 2011, 09:53:38 PM
 #607

To all of you who want a fee : there's nothing stopping you from donating a small percentage of your payouts back to the pool, really Tongue
True. That's why I just donated the "small change" to the pool. But I still like the "1% fee on the first x blocks of the day" concept if that would enable Luke-Jr to work on the pool part time and not on spare time.

1YetiaXeuRzX9QJoQNUW84oX2EiXnHgp3 or http://payb.tc/yeti

Since Bitcoin Randomizer is dead, join the Bitcoin Pyramid (referrer id #203)! Be quick, be on top! Instant payout as soon as one of your referrals deposits!
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 15, 2011, 10:34:44 PM
 #608

Only making the expected return per next-share-contributed be totally independent of the pool history/round-lengths can strategic entry/exit be made profitless. One way to do this is to pay a fixed amount per share no matter what the relation to successful blocks.. but that requires the pool to have a reserve and insure the long dry spells.
MaxPPS is like this, but makes the "reserve" per-user so they can't cheat the pool by withholding blocks.
So it shows as earnings, but they're on hold indefinitely until you work some more? An amount held hostage to ensure loyalty?
No, and I'm tired of refuting these ridiculous misexplanations that seem to assume some few elite should pool hop while everyone else shouldn't.

HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 15, 2011, 11:28:00 PM
 #609

Only making the expected return per next-share-contributed be totally independent of the pool history/round-lengths can strategic entry/exit be made profitless. One way to do this is to pay a fixed amount per share no matter what the relation to successful blocks.. but that requires the pool to have a reserve and insure the long dry spells.
MaxPPS is like this, but makes the "reserve" per-user so they can't cheat the pool by withholding blocks.
So it shows as earnings, but they're on hold indefinitely until you work some more? An amount held hostage to ensure loyalty?
No, and I'm tired of refuting these ridiculous misexplanations that seem to assume some few elite should pool hop while everyone else shouldn't.

Your examples at http://eligius.st/wiki/index.php/Maximum_PPS always show miners with leftover 'value' balances, even with no intent to pool-hop.

The only way they seem to get these is by continuing to mine, right?

Disregarding the independent question of fees, it seems MaxPPS pays out less than PPS for any fixed time period. It approaches PPS over an infinite timeframe. Depending on the number of independent miners with small unclaimed 'value' balances, the operator might wind up holding an arbitrarily large balance in the 'value' reserve.

Hard to see why that would be preferred by miners when there are other ways to disincentivize hopping.

And I'm not even sure MaxPPS does completely disincentivize hopping. Whenever a miner has a positive 'value' balance, it seems hopping is still worthwhile: it's the best possible way to push 'earnings' up to the 'value' without overshooting which would leave still more 'value' held as a security deposit (if that's a more respectful term than 'hostage') to the pool operator.
testerx
Hero Member
*****
Offline Offline

Activity: 608
Merit: 500



View Profile
June 16, 2011, 12:05:38 PM
 #610

Is anybody else seeing really ridiculously low hash rates today on Eligius?  I mean on the stats page for your username-my hash rate looks fine locally on the machines but the site is telling me I have almost nothing.

This is the US server, I couldn't even get the hashrate over 0 on the euro server.
bitcoin0918
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 16, 2011, 01:07:04 PM
 #611

Is anybody else seeing really ridiculously low hash rates today on Eligius?  I mean on the stats page for your username-my hash rate looks fine locally on the machines but the site is telling me I have almost nothing.

This is the US server, I couldn't even get the hashrate over 0 on the euro server.

I was on the US server for several hours last night, and while my graphs showed activity, the reported "submitted shares" was 0, which was absolutely wrong. So I switched to EU overnight and this morning it looks fine. I will stay away from the US server until this "upgrade" is completed.
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
June 16, 2011, 03:43:26 PM
 #612

Your examples at http://eligius.st/wiki/index.php/Maximum_PPS always show miners with leftover 'value' balances, even with no intent to pool-hop.
The error is in assuming either 'value' or 'earnings' are owed to the miner. Until the miner does the actual work (collected in 'value') and earned the pool enough funds (collected in 'earnings'), nothing is due under MaxPPS. For an ordinary miner, in an ordinary scenario, doing the work should also earn the funds required. There are two scenarios where this is not the case:
  • someone withholding valid blocks -- in this case, under MaxPPS, he harms the overall pool income, and inevitably everyone is hit with a loss in 'earnings' -- with straight PPS, the pool operator takes 100% of the risk for this, even if he charges a large fee (both DeepBit and BitPenny charged 10%, and the latter had to close because it was losing too much money even still)
  • pool hoppers -- in this case, under MaxPPS, pool hoppers might continue to work only on short blocks, and always participate in earning the pool the appropriate funds to pay for the work they do, but they are never paid more than the work they do, so there is no incentive to hop -- under straight Proportional, these miners would only participate when there was a chance at getting paid more than the work they put into the pool, and inevitably the pool would be left empty if everyone did it

Disregarding the independent question of fees, it seems MaxPPS pays out less than PPS for any fixed time period. It approaches PPS over an infinite timeframe.
You can't fairly disregard fees here. Straight PPS is impractical even with a 10% fee. MaxPPS should pay out more than that remaining 90% in theory.

Depending on the number of independent miners with small unclaimed 'value' balances, the operator might wind up holding an arbitrarily large balance in the 'value' reserve.
The mistake here is in assuming the pool actually has funds to pay everyone's "value"; if that is the case, it also means everyone has the "earnings" too. The only time these are different are in excessive periods of bad luck (possibly induced artificially by a cheater) when everyone shares the "hit", or excessive periods of luck where everyone is paid in full for the work they do (and all build a reserve to cover the risk of future bad luck).

Hard to see why that would be preferred by miners when there are other ways to disincentivize hopping.
If you know of a better way, feel free to suggest it. Every other way I've seen is unfair to some normal miners.

bitcoin0918
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 16, 2011, 05:42:48 PM
 #613

Finally, a block! Tongue
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
June 16, 2011, 06:45:46 PM
 #614

If you know of a better way, feel free to suggest it. Every other way I've seen is unfair to some normal miners.

The score-based method is not better, but it definitely is easier for miners to understand (and it seems to work well on Slush's pool), and is less confusing. It is also way easier to implement.

Also, a few general ideas :

* You wanted to put a fee ? Do it.
* If you do so, consider adding the tx fees in the rewards. We would be the first pool to do this at the moment !
* If you keep MaxPPS, please, please, write a clear explanation and/or a FAQ in the wiki. And announce when you'll deploy it.

A pool-biased blockchain representation, by me: pident (WTFPL)
bitcoin0918
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 16, 2011, 07:34:12 PM
 #615

* If you do so, consider adding the tx fees in the rewards. We would be the first pool to do this at the moment !
Actually, mineco.in holds that distinction, although a very small pool atm.
bitcoin0918
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 16, 2011, 07:36:29 PM
 #616

Quote
The US pool is currently being retarded and nobody knows why
Come now, that doesn't instill confidence. It would be better to just keep the message vague and generic, rather than drive people away. Just my opinion. Tongue
HanSolo
Newbie
*
Offline Offline

Activity: 59
Merit: 0



View Profile
June 16, 2011, 07:40:18 PM
 #617

If you know of a better way, feel free to suggest it. Every other way I've seen is unfair to some normal miners.

I suggested a method that is hop-proof, by always offering the same expected return for the next share contributed, and riskless for the pool-operator. It's what (a couple messages after initial proposal) I labeled 'Pay-Per-Last-N-Shares' (PPLNS). It's not the same as proportional or straight PPS.

You suggested PPLNS was unfair but didn't explain why/how.

It's simple to implement, clear, hop-proof, and operator-friendly in the amount of risk (none) and running state required to calculate payout (very little).

If you make N small, some shares contributed wind up earning nothing.. but that's totally unpredictable and affects all shares equally, so there's no tilt towards any miner timing or scale there. It's perfectly fair in those dimensions. By making N arbitrarily large (but still constant and pre-advertised), you could make the likelihood any share pays zero arbitrarily small (if you think fairness requires every share get some token payment no matter how far removed from success).

I'm pretty sure PPLNS provides a disincentive to the 'withholding sabotage' as well.. anyone who's been mining for a while makes marginally more by submitting a found share, compared to waiting for someone else to.

And it doesn't require the operator holding a bunch of 'earnings' in reserve, in the meantime paying some amount that seems to be roughly minimum(pps(miner),proportional(miner)).

I could be wrong, but if so you haven't explained the problems.

And of course it's your pool, your rules. I'm just providing an honest assessment of how MaxPPS looks from the outside.
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
June 16, 2011, 09:05:22 PM
 #618

If you make N small, some shares contributed wind up earning nothing.. but that's totally unpredictable and affects all shares equally, so there's no tilt towards any miner timing or scale there. It's perfectly fair in those dimensions.

It's fair in average. But not enough. People who can't for some reason (malicious or not) contribute at the end of a block end up getting nothing, whereas the score-based system still gives them a little something. While, technically, the method you suggested is fair, it can be very frustrating for an isolated miner that got absolutely nothing for his work.

A pool-biased blockchain representation, by me: pident (WTFPL)
martin
Full Member
***
Offline Offline

Activity: 150
Merit: 100



View Profile WWW
June 17, 2011, 02:24:45 AM
 #619

I mined on the eligius pool a little bit a couple of weeks back, using this address to check my stats:

http://eligius.st/~artefact2/eu/1DP5XtbkwF3xVoijHXfnq6RQ3fxYKrEp49

Now, I go there and it says no stats because I haven't mined for over a week, that's fair enough but shouldn't I have received any coins I mined by now?
bitcoin0918
Newbie
*
Offline Offline

Activity: 70
Merit: 0



View Profile
June 17, 2011, 02:52:10 AM
 #620

Now, I go there and it says no stats because I haven't mined for over a week, that's fair enough but shouldn't I have received any coins I mined by now?
Is this your transaction? It looks like you got 0.22btc:

http://blockexplorer.com/address/1DP5XtbkwF3xVoijHXfnq6RQ3fxYKrEp49
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 [31] 32 33 34 35 36 37 38 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!