Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1185
|
 |
August 07, 2011, 08:02:01 PM |
|
Not my tool, so no idea how to get at the data... but changing the wording on the page to something along the lines of "your reward will be placed in the payout queue once it crosses the threshold" could be a start, and maybe followed by "click here for an estimate of the payment progress". I'd recommend "This amount will be eligible for payout to you when it reaches approximately 0.33554432 BTC or after one week of inactivity. Eligible payouts are sent 50 BTC at a time when the pool finds a block, oldest balance first.
|
|
|
|
|
|
|
|
"The nature of Bitcoin is such that once version 0.1 was released, the
core design was set in stone for the rest of its lifetime." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
anodyne
|
 |
August 07, 2011, 09:58:24 PM |
|
Not my tool, so no idea how to get at the data... but changing the wording on the page to something along the lines of "your reward will be placed in the payout queue once it crosses the threshold" could be a start, and maybe followed by "click here for an estimate of the payment progress". I'd recommend "This amount will be eligible for payout to you when it reaches approximately 0.33554432 BTC or after one week of inactivity. Eligible payouts are sent 50 BTC at a time when the pool finds a block, oldest balance first. "This amount will be eligible for payout to you when it reaches [approximately] 0.33554432 BTC or after one week of inactivity. If the total of eligible rewards exceeds 50BTC payouts will be sent 50BTC at a time, as blocks are found by the pool, with oldest balances paid first." I think that's the most informative/concise wording I can come up with. Also, does it need "approximately" when the amount is specified to eight decimals...? 
|
Bitcoins: solid enough to build pyramids.
|
|
|
enquirer
|
 |
August 10, 2011, 10:02:46 PM |
|
With SMPPS or any other "delayed return" system, if pool is lucky, owner has a surplus.
If pool is unlucky, the most reasonable strategy for any miner is to stop mining for that pool and go mine for another pool which is currently lucky. So, assuming all players are reasonable, pool will die. Pool owner will never have to refund any money.
So mathematical expectation (average over an infinite ensemble of all possible pools) of pool's surplus grows as ~sqrt(time).
|
|
|
|
caish5
|
 |
August 15, 2011, 06:07:28 PM |
|
Can anybody tell me why the payment per share has jumped on the latest block from 0.00002647 BTC to 0.00004292 BTC?
Not that I'm complaining!
|
|
|
|
Artefact2
|
 |
August 15, 2011, 06:35:37 PM |
|
Can anybody tell me why the payment per share has jumped on the latest block from 0.00002647 BTC to 0.00004292 BTC?
Not that I'm complaining!
It's a mistake, the share count is way off. I'll try to fix it. [Edit: fixed]
|
A pool-biased blockchain representation, by me: pident (WTFPL)
|
|
|
Grinder
Legendary
Offline
Activity: 1284
Merit: 1001
|
 |
August 16, 2011, 05:30:31 PM |
|
The time stamp on blocks solved by Eligius is at least 6 minutes into the future. I recommend you start syncing the time using ntp.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1185
|
 |
August 16, 2011, 05:51:56 PM |
|
The time stamp on blocks solved by Eligius is at least 6 minutes into the future. I recommend you start syncing the time using ntp. The timestamp does not have to be the exact time, nor is it usually based on the system clock (which is kept in sync with ntp) for Eligius.
|
|
|
|
iopq
|
 |
August 20, 2011, 01:44:44 PM |
|
The "broken by design" part is due to the fact that the pool pays by generation – so payments are limited to the 50BTC, plus income from fees, that can be fit into that part of a block. So, since the PPS system means that the pool can reward more than 50BTC during a round, rewards accumulated during long rounds cause a backlog that will have to be fit into future blocks. Once you get over the threshold, you can get an estimate on your place in the queue on this page made by twmz: http://eligius.st/~twmz/And yes, I agree that it could be made a little bit clearer, since the information about the payout threshold on the stats pages dates back to the time when the pool was still proportional. if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay?
|
|
|
|
gentakin
Member

Offline
Activity: 98
Merit: 10
|
 |
August 20, 2011, 02:06:54 PM |
|
if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay?
Probably not, back when eligius was proportional there was a delay as well. It's a bad thing to have a lot of small transactions for payout, because when you spend the coins later, you have to pay higher fees and it pollutes the block chain. Something just came to my mind that could shorten the payout queue, although I'm not sure if it works, and it seems rather dangerous to do. Why doesn't eligius put transactions with a very high fee (input: maybe 50BTC, output: maybe 0.01BTC, fee: 49.99BTC) in its blocks. The fee should be available in the generation transaction instantly and can be used for >50BTC payouts.  Just need to make very sure that transaction is not broadcasted to the network for other pools to pick up.. And now that I mention it, of course: it's a bad idea, because the block might be orphaned later and then others can put the transaction into their own block.
|
1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1185
|
 |
August 20, 2011, 02:39:07 PM |
|
if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay? PPLNS never rewards more than 50 BTC per block (like SMPPS does), so delays would be very rare.
|
|
|
|
twmz
|
 |
August 20, 2011, 03:45:15 PM |
|
if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay?
The minimum balance functionality (you don't get paid until your balance is > 200 TBC) would still cause payout delays. For example, if when a block is found suddenly a lot of old accounts are now above the balance, you can have more than 50 BTC due for payment. But it will typically be a shorter delay than is seen after long blocks with SMPPS. With SMPPS, we occasionally see delays of as much as 7-8 blocks. I shouldn't get that bad with PPLNS.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
bitfoo
Donator
Sr. Member
Offline
Activity: 289
Merit: 250
|
 |
August 22, 2011, 08:46:07 PM |
|
if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay?
The minimum balance functionality (you don't get paid until your balance is > 200 TBC) would still cause payout delays. For example, if when a block is found suddenly a lot of old accounts are now above the balance, you can have more than 50 BTC due for payment. But it will typically be a shorter delay than is seen after long blocks with SMPPS. With SMPPS, we occasionally see delays of as much as 7-8 blocks. I shouldn't get that bad with PPLNS. I don't understand how this can happen with PPLNS. Since no block is ever paid out more than 50 BTC, every old account with a pending balance technically already has the required BTC in the pool fund, it's just not paid out yet. The pool should never owe more than it has on hand.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1185
|
 |
August 22, 2011, 08:54:39 PM |
|
if the pool switched to PPLNS, would that mean that it would pay out rewards as they are earned? in other words, there would be no delay?
The minimum balance functionality (you don't get paid until your balance is > 200 TBC) would still cause payout delays. For example, if when a block is found suddenly a lot of old accounts are now above the balance, you can have more than 50 BTC due for payment. But it will typically be a shorter delay than is seen after long blocks with SMPPS. With SMPPS, we occasionally see delays of as much as 7-8 blocks. I shouldn't get that bad with PPLNS. I don't understand how this can happen with PPLNS. Since no block is ever paid out more than 50 BTC, every old account with a pending balance technically already has the required BTC in the pool fund, it's just not paid out yet. The pool should never owe more than it has on hand. SMPPS also never pays out more than the pool has. The reward system isn't the delay-- the payout system is. Generating all payouts means only 50 BTC can be paid at once, even if there's 51 BTC passing the minimum payout at once.
|
|
|
|
bitfoo
Donator
Sr. Member
Offline
Activity: 289
Merit: 250
|
 |
August 22, 2011, 09:16:13 PM |
|
SMPPS also never pays out more than the pool has. The reward system isn't the delay-- the payout system is. Generating all payouts means only 50 BTC can be paid at once, even if there's 51 BTC passing the minimum payout at once.
OK, I'd like to clarify my understanding of this a little bit. Let's assume that we have a fresh start, with everyone having zero balances. We find one block, so the total of everyone's pending balance is 50 BTC. Out of this 50 BTC, let's say 40 BTC is above the payout threshold, so they will be included in the next block. I assume the remaining 10 BTC goes into the pool buffer. Now 60 BTC is owed. But only 50 BTC can be paid out every block. I assume with SMPPS a few short rounds can clear out the pending payouts since the pool will owe less on those rounds than it earns. With PPLNS, I don't see how the pending payments can ever go down - since at every round the pool makes 50 BTC, owes 50 BTC, and pays out less than 50 BTC. This would mean that payouts keep getting delayed more and more? Hmm, I think I understood it while typing this out. After some point, all 50 BTC earned in a block will be paid out because it meets the payout threshold. But the pool buffer that you've built up to this point is basically yours to keep, since it can never be withdrawn from anyway. Do I understand this right?
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1185
|
 |
August 22, 2011, 09:22:12 PM |
|
SMPPS also never pays out more than the pool has. The reward system isn't the delay-- the payout system is. Generating all payouts means only 50 BTC can be paid at once, even if there's 51 BTC passing the minimum payout at once.
OK, I'd like to clarify my understanding of this a little bit. Let's assume that we have a fresh start, with everyone having zero balances. We find one block, so the total of everyone's pending balance is 50 BTC. Out of this 50 BTC, let's say 40 BTC is above the payout threshold, so they will be included in the next block. I assume the remaining 10 BTC goes into the pool buffer. Now 60 BTC is owed. But only 50 BTC can be paid out every block. I assume with SMPPS a few short rounds can clear out the pending payouts since the pool will owe less on those rounds than it earns. With PPLNS, I don't see how the pending payments can ever go down - since at every round the pool makes 50 BTC, owes 50 BTC, and pays out less than 50 BTC. This would mean that payouts keep getting delayed more and more? Hmm, I think I understood it while typing this out. After some point, all 50 BTC earned in a block will be paid out because it meets the payout threshold. But the pool buffer that you've built up to this point is basically yours to keep, since it can never be withdrawn from anyway. Do I understand this right? If there's >= 50 BTC ready for payout, it won't payout less. The only way it can be > 50 BTC is if someone is earning less than the minimum payout, which means that in between his payouts, there's extra space in the 50 BTC for other payouts. So it all evens out much faster/easier.
|
|
|
|
Lundy
Newbie
Offline
Activity: 16
Merit: 0
|
 |
August 22, 2011, 09:56:11 PM |
|
The block we have been working on for the last 21+ hours reminds me why I like mining at this pool. 
|
|
|
|
sveetsnelda
|
 |
August 23, 2011, 06:12:50 AM |
|
Just pointed 19 Ghash your way... 
|
14u2rp4AqFtN5jkwK944nn741FnfF714m7
|
|
|
Bobnova
|
 |
August 24, 2011, 09:28:07 PM |
|
SMPPS also never pays out more than the pool has. The reward system isn't the delay-- the payout system is. Generating all payouts means only 50 BTC can be paid at once, even if there's 51 BTC passing the minimum payout at once.
Hmm, I think I understood it while typing this out. After some point, all 50 BTC earned in a block will be paid out because it meets the payout threshold. But the pool buffer that you've built up to this point is basically yours to keep, since it can never be withdrawn from anyway. Do I understand this right? Yup, that you do. Do some calculations on it and you'll find that the pool owner has over a thousand bitcoins in his wallet. There have been lots of streaks of good luck that paid off the debt and then only paid out a few bitcoins, the rest going to luke. That "buffer" is a laughable name for his pocket, were it a buffer the server wouldn't be 6-10 blocks in the hole right now. What we have right now with this payout system is a system that works great for everybody with good luck, and poorly for the miners (but fine for luke) with bad luck. (Easy to calculate his pocket, take all the blocks that paid less than 50 to users and add the amount not paid to users together. Just like the "buffer" does, except don't subtract from the buffer on blocks that award >50 bitcoins) I'd like to see the 1000-2000 in lukes pocket put into a real buffer, personally. I really like the system other than that part.
|
BTC: 1AURXf66t7pw65NwRiKukwPq1hLSiYLqbP
|
|
|
|
Bobnova
|
 |
August 25, 2011, 01:52:03 AM |
|
The server has owed other people money for longer, so it's paying them first. Given the 50btc cap on payments per block found, it's going to be a bit before those of us further down on the list see any money.
Were the "server funds" actually paid out like the stat site says they are, we'd all have been paid right on time.
|
BTC: 1AURXf66t7pw65NwRiKukwPq1hLSiYLqbP
|
|
|
|