Bitcoin Forum
May 09, 2024, 07:43:50 PM *
News: Latest Bitcoin Core release: 27.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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 ... 200 »
  Print  
Author Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #  (Read 458140 times)
Luke-Jr (OP)
Legendary
*
Offline Offline

Activity: 2576
Merit: 1186



View Profile
August 07, 2011, 08:02:01 PM
 #281

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 Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1715283830
Hero Member
*
Offline Offline

Posts: 1715283830

View Profile Personal Message (Offline)

Ignore
1715283830
Reply with quote  #2

1715283830
Report to moderator
anodyne
Full Member
***
Offline Offline

Activity: 518
Merit: 100


View Profile
August 07, 2011, 09:58:24 PM
 #282

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...? Smiley

Bitcoins: solid enough to build pyramids.
enquirer
Sr. Member
****
Offline Offline

Activity: 306
Merit: 257


View Profile
August 10, 2011, 10:02:46 PM
 #283

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
Sr. Member
****
Offline Offline

Activity: 324
Merit: 250



View Profile WWW
August 15, 2011, 06:07:28 PM
 #284

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!

Bitvolcano YAC, BBQ and WDC P2Pools at http://bitvolcano.com
Artefact2
Full Member
***
Offline Offline

Activity: 123
Merit: 100


View Profile WWW
August 15, 2011, 06:35:37 PM
 #285

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 Offline

Activity: 1284
Merit: 1001


View Profile
August 16, 2011, 05:30:31 PM
 #286

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 Offline

Activity: 2576
Merit: 1186



View Profile
August 16, 2011, 05:51:56 PM
 #287

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
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


View Profile
August 20, 2011, 01:44:44 PM
 #288

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 Offline

Activity: 98
Merit: 10


View Profile
August 20, 2011, 02:06:54 PM
 #289

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. Cheesy 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 Offline

Activity: 2576
Merit: 1186



View Profile
August 20, 2011, 02:39:07 PM
 #290

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
Hero Member
*****
Offline Offline

Activity: 737
Merit: 500



View Profile
August 20, 2011, 03:45:15 PM
 #291

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?  1TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs
WoT, GPG

Bitrated user: ewal.
bitfoo
Donator
Sr. Member
*
Offline Offline

Activity: 289
Merit: 250



View Profile
August 22, 2011, 08:46:07 PM
 #292

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 Offline

Activity: 2576
Merit: 1186



View Profile
August 22, 2011, 08:54:39 PM
 #293

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 Offline

Activity: 289
Merit: 250



View Profile
August 22, 2011, 09:16:13 PM
 #294

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 Offline

Activity: 2576
Merit: 1186



View Profile
August 22, 2011, 09:22:12 PM
 #295

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 Offline

Activity: 16
Merit: 0


View Profile
August 22, 2011, 09:56:11 PM
 #296

The block we have been working on for the last 21+ hours reminds me why I like mining at this pool. Smiley
sveetsnelda
Hero Member
*****
Offline Offline

Activity: 642
Merit: 500


View Profile
August 23, 2011, 06:12:50 AM
 #297

Just pointed 19 Ghash your way...  Wink

14u2rp4AqFtN5jkwK944nn741FnfF714m7
Bobnova
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
August 24, 2011, 09:28:07 PM
 #298

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
strictlyfocused
Newbie
*
Offline Offline

Activity: 55
Merit: 0


View Profile
August 25, 2011, 12:45:42 AM
 #299

Is there a reason payouts are not being sent???

https://i.imgur.com/12qqm.png
Bobnova
Full Member
***
Offline Offline

Activity: 210
Merit: 100


View Profile
August 25, 2011, 01:52:03 AM
 #300

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
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 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 ... 200 »
  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!