[OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 #

[bmoconno]

Then explain to me where did the extra 25btc comes from? I know it came from a new block but it wasnt paid out according to shares log.... (shelved shares). How did that happen?

If you read wk's post from last night he clearly explains that the BTC for the double-payment came from block #277361 that was found just as he was taking the system out of fail-safe.  The original payment was meant to come out of the BTC mined from block #277343, which was found just before the system went into fail-safe mode.

Hope this clears it up for you, if not, please re-read the entirety of wk's post from last night where he explains the situation.

I understood the mess up. Please read the post above

Ok, we'll try it like this…

25 BTC came from block #277361
25 BTC came from block #277343

That's where the BTC for the double payment came from.

[1714260181]

1714260181

[1714260181]

1714260181

[seriouscoin]

Then explain to me where did the extra 25btc comes from? I know it came from a new block but it wasnt paid out according to shares log.... (shelved shares). How did that happen?

If you read wk's post from last night he clearly explains that the BTC for the double-payment came from block #277361 that was found just as he was taking the system out of fail-safe.  The original payment was meant to come out of the BTC mined from block #277343, which was found just before the system went into fail-safe mode.

Hope this clears it up for you, if not, please re-read the entirety of wk's post from last night where he explains the situation.

I understood the mess up. Please read the post above

Ok, we'll try it like this…

25 BTC came from block #277361
25 BTC came from block #277343

That's where the BTC for the double payment came from.

LOL thanks

But thats not my question. Look the payout method is sound but the implementation IMO isnt.
I would have gotten my own answers if there were stats to show all my submitted shares, paid out shares and shelved shares.

Where can we see this shares log?

Edit: wk's stats shows "rewards" which got messed up because it doesnt show negative balance. After this you understand why "shares"are more transparent than "reward". Look at BTCguild's PPLNS stats for example.

[novymivo]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

[seriouscoin]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

Didnt i get ppl here to confirm that he didnt pay out of his pocket?

My question is to get this clear. His payout got messed up meaning it wasnt paid out according to a proper shares log.

Hence my question "where did that 25BTC come from? "...... because it has to come from miners whose submitted shares werent paid. (shelved shares)

[bmoconno]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

He didn't pay out of pocket, he accidentally used the reward from the block that was found while he was fixing the system.  As a result, people who received a double payment had a negative balance set (it read as 0.00000000 BTC on stats).  This balance was "worked off" by the miners continuing to use the pool.  So, if you got a double payment, and you didn't do anything to your miners… they likely already payed off your double payment.

@seriouscoin

hahahahaha I must be tired, I see that you're asking how the shelving system was circumvented.  I don't believe it was, since the double payment that went out was merely a manual payment of what the system already had in the queue.  Since the system was in fail-safe mode and wk didn't check to see if a payment was made, his manual payment simply payed off what had been in the queue.

I see how having knowledge of how many shares you had in each block could be beneficial to miners, but I don't think it would have fixed this problem.  

A mistake was made, and I think that wks way of solving it was probably the best way to go about fixing it.  If he had made an announcement, it's likely that the pool would be at a -25 BTC deficit, because most of the people who got a double payment would have switched pools or changed their payout address to get around "working off" the double payment they received.

[novymivo]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

He didn't pay out of pocket, he accidentally used the reward from the block that was found while he was fixing the system.  As a result, people who received a double payment had a negative balance set (it read as 0.00000000 BTC on stats).  This balance was "worked off" by the miners continuing to use the pool.  So, if you got a double payment, and you didn't do anything to your miners… they likely already payed off your double payment.

@seriouscoin

hahahahaha I must be tired, I see that you're asking how the shelving system was circumvented.  I don't believe it was, since the double payment that went out was merely a manual payment of what the system already had in the queue.  Since the system was in fail-safe mode and wk didn't check to see if a payment was made, his manual payment simply payed off what had been in the queue.

I see how having knowledge of how many shares you had in each block could be beneficial to miners, but I don't think it would have fixed this problem.  

A mistake was made, and I think that wks way of solving it was probably the best way to go about fixing it.  If he had made an announcement, it's likely that the pool would be at a -25 BTC deficit, because most of the people who got a double payment would have switched pools or changed their payout address to get around "working off" the double payment they received.

Thank you for explanation.

[seriouscoin]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

He didn't pay out of pocket, he accidentally used the reward from the block that was found while he was fixing the system.  As a result, people who received a double payment had a negative balance set (it read as 0.00000000 BTC on stats).  This balance was "worked off" by the miners continuing to use the pool.  So, if you got a double payment, and you didn't do anything to your miners… they likely already payed off your double payment.

@seriouscoin

hahahahaha I must be tired, I see that you're asking how the shelving system was circumvented.  I don't believe it was, since the double payment that went out was merely a manual payment of what the system already had in the queue.  Since the system was in fail-safe mode and wk didn't check to see if a payment was made, his manual payment simply payed off what had been in the queue.

I see how having knowledge of how many shares you had in each block could be beneficial to miners, but I don't think it would have fixed this problem.  

A mistake was made, and I think that wks way of solving it was probably the best way to go about fixing it.  If he had made an announcement, it's likely that the pool would be at a -25 BTC deficit, because most of the people who got a double payment would have switched pools or changed their payout address to get around "working off" the double payment they received.

Ofcourse having shares stats wont fix the problem. The problem was identified as operator's mistake. But it would show transparency. I also want to here how he would "fix" the problem. Because i dont want to be the one paying for, you know what i mean.

 

[seriouscoin]

Thank you for explanation.

Dont forget to thank me for raising the question because at first you gave me attitude.

Even the founder of the pool, Luke , is confused at times. He said its coming from his pocket which is not yet proven. Wk wants miners to work off the mistake but no transparency whatsoever. Is he a saint or hes asking us to trust him completely even after his own mistake? Trust should never be a requirement. Beside, withholding the information means he doesnt trust his miners.

[bmoconno]

Hence my question "where did that 25BTC come from? "...... because it has to come from miners whose submitted shares werent paid. (shelved shares)

You posted this reply while I was posting my last one, but I think I kind of hit on what I think happened.  To make it more clear for others, though, this has less to do with shelved shares and more to do with the payment queue.

0.  Block #277343 is found.
1.  First payment goes out.
2.  System crashes before payment queue gets updated.  (the system probably waits from a confirmation or two before updating the queue to ensure payment happened).
3.  wk goes to the data center and fixes the problem.
4.  Block #277361 is found.
5.  wk initiates a manual payment according to the (now out of date) payment queue.

This means that the people 25 BTC down in the queue from the first payment didn't receive their BTC when expected.  They didn't lose any BTC, but they had to wait an additional block before they received their payment.

I believe that the section of code that he posted yesterday is intended to prevent this type of mistake in the future, because it won't let payments be made from fail-safe mode.  This will allow the queue to get updated accordingly before a payment is sent.

[novymivo]

Thank you for explanation.

Dont forget to thank me for raising the question because at first you gave me attitude.
Even the founder of the pool, Luke , is confused at times. He said its coming from his pocket which is not yet proven. Wk wants miners to work off the mistake but no transparency whatsoever. Is he a saint or hes asking us to trust him completely even after his own mistake? Trust should never be a requirement. Beside, withholding the information means he doesnt trust his miners.

Thank you as well

[bmoconno]

Dont forget to thank me for raising the question because at first you gave me attitude.

Even the founder of the pool, Luke , is confused at times. He said its coming from his pocket which is not yet proven. Wk wants miners to work off the mistake but no transparency whatsoever. Is he a saint or hes asking us to trust him completely even after his own mistake? Trust should never be a requirement. Beside, withholding the information means he doesnt trust his miners.

I think it's great that you raised the question, and I think it might lead to change in the system.  However, like I said before, I think wk made the right move in not announcing the situation.  I feel that a lot of people in BTC are in it to make a quick buck, and if they have the opportunity to get a significant amount of extra BTC for free I think most of them will take it.

Obviously, we shouldn't inherently trust all pool operators, but that's why there are multiple pools.  We all look for a pool we like and we hope we can trust them, it's not a perfect system.

[seriouscoin]

Hence my question "where did that 25BTC come from? "...... because it has to come from miners whose submitted shares werent paid. (shelved shares)

You posted this reply while I was posting my last one, but I think I kind of hit on what I think happened.  To make it more clear for others, though, this has less to do with shelved shares and more to do with the payment queue.

0.  Block #277343 is found.
1.  First payment goes out.
2.  System crashes before payment queue gets updated.  (the system probably waits from a confirmation or two before updating the queue to ensure payment happened).
3.  wk goes to the data center and fixes the problem.
4.  Block #277361 is found.
5.  wk initiates a manual payment according to the (now out of date) payment queue.

This means that the people 25 BTC down in the queue from the first payment didn't receive their BTC when expected.  They didn't lose any BTC, but they had to wait an additional block before they received their payment.

I believe that the section of code that he posted yesterday is intended to prevent this type of mistake in the future, because it won't let payments be made from fail-safe mode.  This will allow the queue to get updated accordingly before a payment is sent.

I disagree, as payout queue is directly tied to shelved shares/ shareslog (as i understood the method)

The first payement was "sent", the second was "generated" (based on your screenshot)

So i supposed the first payment was manual and the second was automatic.

If the ppl 25BTC down in the queue didnt receive their BTC as expected, that means their shelved shared was never paid. Assume we wont have all 25BTC deficit worked off, are all the miners gonna pay for it? because those shelved shares arent going anywhere unless WK delete those and call them "mistake"

[bmoconno]

If the 25BTC down in the queue didnt receive their BTC as expected, that means their shelved shared was never paid. Assume we wont have all the miners to "work off" this 25BTC deficit, are all the miners gonna pay for it? because those shelved shares arent going anywhere unless WK deleted those and call them "mistake"

I believe wk said that he would take any deficit that isn't paid back by the miners who received double payment will be paid back to the pool from the BTC that was donated for the developers.  Which is unfortunate, because development is exactly what is needed to help prevent problems like this in the future.

[wizkid057]

I don't understand some people here.
He paid from his own pocket, what else you want from him?
wk please put the list of addresses with double pay :
If i see my address here i will return the money , simple.
Don't forget we do not pay anything for using Eligius.st !!!!

Didnt i get ppl here to confirm that he didnt pay out of his pocket?

My question is to get this clear. His payout got messed up meaning it wasnt paid out according to a proper shares log.

Hence my question "where did that 25BTC come from? "...... because it has to come from miners whose submitted shares werent paid. (shelved shares)

I think you completely miss the point on how CPPSRB actually works.  Keep in mind that the payout queue and the share log are not the same entity.
Let me try to explain exactly what happened here so you can better understand, and try to explain a bit about CPPSRB in the process.

...

• Was business as usual.  Shares accepted, put on top of the share log.
• Payout queue contained a list of payouts for distribution for when the next block (277343) was found.
• Block 277343 was found.
• CPPSRB could not reconcile the share for the block with the database quickly due to the issue described previously and went into fail-safe mode.  This was BEFORE processing the share log and tallying payouts included in block 277343.
• I panic and shutdown the pool servers.  Then I save CPPSRB's state without realizing it was in fail-safe mode.  All shares are still accounted for, but the ones that would be marked paid by finding block 277343 were not yet marked paid.
• After fixing the hardware issue and resuming operations, I started CPPSRB again.  Since fail-safe mode was not part of the state (it is now) the system loaded and continued to work as if block 277343 never happened.
• Block 277361 was found.
• I realized and reacted too late (right after block 277361 was found) to fix the issue.  Block 277361 was found, the top of the share log was marked paid accordingly, and the payouts in 277361 were tallied.
• Then block 277343 was recognized and processed by CPPSRB. The share log at that block's work's issue time had shares marked paid, and then the payouts in block 277343 were tallied revealing the double payments to the CPPSRB system and driving a handful of balances negative.

The pool-side user balances are not the same as the share log.  Balances increase when blocks are found and shares are marked paid.  Due to the double payment, shares for two found blocks were marked paid in the share log (increasing pool-side user balances by ~50BTC+fees), but only ~25 BTC actually covered owed pool-side balances in the actual payments.  The payout queue grew another ~25 BTC, so the next manual payout would require an additional 25 BTC to pay everyone's balances, which has to come from somewhere (ie: my pocket).

Fortunately, it seems that at least a good percentage of the people overpaid have "worked off" their over-payment (new share log shares marked paid increasing their negative balance above zero) leaving very few outstanding overages and much less than the full 25 BTC to come out of pocket.

He said its coming from his pocket which is not yet proven.
Wk wants miners to work off the mistake but no transparency whatsoever.
Is he a saint or hes asking us to trust him completely even after his own mistake?
Trust should never be a requirement. Beside, withholding the information means he doesnt trust his miners.

First, the above should show why the balance of the overage will come out of my pocket.  In short, to do a manual payout and catch up the payout queue the funds have to come from somewhere.  Since the pool's offline wallet never received a 25 BTC payment for the block in question, those funds aren't there.  So, when I process the payout I will be moving the remaining overage from my own funds into the pool funds to raise the balance to match what is owed miners.

All of these stats are publicly accessible.  I ask no one to trust me for anything.  Simply look at your stats or the data exposed via various APIs.  While the stats code does not support the negative balance, the API (balances.json) does.

I'm not not a saint.  I'm human, and I make mistakes.  I won't let miners suffer for my mistakes, which is why whatever is left overpaid when I do the next manual payout will be coming from my own received donations.

As for trusting miners, no.  There are very few miners that I actually trust.  Eligius has no registration, no usernames or emails or any identifying information whatsoever about its miners.  They're basically anonymous, faceless, fearless entities that can and will react in their best interest when possible, regardless of if it is in the pool's best interest.  This is a fact, and is provable by the number of overpaid miners that simply stopped mining on Eligius within an hour of my post about the double payment issue.  Its sad, but true.  I try to make everything on this end as trust-free as possible by exposing every possible piece of data.  Miners on the other hand, I have no control over and will act how they want regardless.

Anyway, don't make this out to be a witch hunt or an Eligius bashing spree.  There is no need.  I screwed up, and I'm paying for the screw up.  It happened, and I've put in more code to help prevent it from happening again in the future.  No miners are underpaid because of this, so please understand how everything works before making baseless accusations.

-wk

Edit: Clarifications: Only miners who were overpaid are "working off" their over payment.  Everyone else is unaffected.

[seriouscoin]

If the 25BTC down in the queue didnt receive their BTC as expected, that means their shelved shared was never paid. Assume we wont have all the miners to "work off" this 25BTC deficit, are all the miners gonna pay for it? because those shelved shares arent going anywhere unless WK deleted those and call them "mistake"

I believe wk said that he would take any deficit that isn't paid back by the miners who received double payment will be paid back to the pool from the BTC that was donated for the developers.  Which is unfortunate, because development is exactly what is needed to help prevent problems like this in the future.

Lets put trust aside for a second.....


Or he can use some of shelved shares (we have never gotten to 100% reward for more than a month) to cover the deficit ?

Why cant we all see the shares log? or would this info cost us 1% "fee" ?

EDIT: i made this post b4 wk's post.

WK why do you feel offended? why do you say my posts are accusation? Again, how do we check what you said you're doing? please dont tell me to use API because i believe its the pool that needs to be transparent. I dont accuse you of anything, i simply want you to give transparency.

EDIT2: i understand how CPPSRB works, i just dont understand how your implementation works.... please be clear about this.

[HellDiverUK]

WK why do you feel offended?

Probably because you're clueless and won't leave it alone, and because you can't and don't understand the multiple explanations given to you, so you're stuck in a "I don't trust you" loop.

[wizkid057]

WK why do you feel offended?

Probably because you're clueless and won't leave it alone, and because you can't and don't understand the multiple explanations given to you, so you're stuck in a "I don't trust you" loop.

^ This is pretty accurate.

If the 25BTC down in the queue didnt receive their BTC as expected, that means their shelved shared was never paid. Assume we wont have all the miners to "work off" this 25BTC deficit, are all the miners gonna pay for it? because those shelved shares arent going anywhere unless WK deleted those and call them "mistake"

I believe wk said that he would take any deficit that isn't paid back by the miners who received double payment will be paid back to the pool from the BTC that was donated for the developers.  Which is unfortunate, because development is exactly what is needed to help prevent problems like this in the future.

Lets put trust aside for a second.....


Or he can use some of shelved shares (we have never gotten to 100% reward for more than a month) to cover the deficit ?

Why cant we all see the shares log? or would this info cost us 1% "fee" ?

EDIT: i made this post b4 wk's post.

WK why do you feel offended? why do you say my posts are accusation? Again, how do we check what you said you're doing? please dont tell me to use API because i believe its the pool that needs to be transparent. I dont accuse you of anything, i simply want you to give transparency.

EDIT2: i understand how CPPSRB works, i just dont understand how your implementation works.... please be clear about this.

If you understood how CPPSRB worked, then you would understand my implementation.... it is CPPSRB.

Asking about shelved shares being used to cover the overage proves you do not know how CPPSRB works.

Shelved shares are fiat.  They have no value until the pool finds enough blocks to pay them.  They are shares in the share log that are not paid because the pool has not found enough blocks to pay them.  It is expected, due to orphans, that 100% PPS is impossible long term.

So there is no huge buffer of coins just sitting around waiting to be paid out to miners.  The only coins in the pool's cold wallet are the coins needed to cover the payout queue and miners who have not yet reached their minimum payout, actual pool funds owed to miners.

-wk

[wizkid057]

GHash.io are really transparent... 

I literally lol'd at this.

[smooth]

There is nothing wrong with wanting, and requesting, transparency. Transparency increases trust.

[smooth]

Question about payouts. I have a minimum set in My Eligius and sometimes I get payouts just above the minimum but I also sometimes get payments well below the minimum. What's up with that?