Topic: [OLD] Eligius: ASIC, no registration, no fee CPPSRB BTC + 105% PPS NMC, 877 # - page 40. (Read 458370 times)

Sorry, I meant to include HellDiverUK's post:


Which I think means he's stopped mining bitcoin atm.

I almost don't even need network monitoring... there is almost always a forum post here within minutes of any web site issue

Looks like it was just a network hiccup between the web server and the web server caching server which resolved itself.

-wk

Yep, however none of my miners have switched over to the fallback so stratum is still up. Whoops it's back.

Mine mine mine! All mine!

down for me to.

Happy New Year... 2014 in Australia

Is the website down or is it just me? I'm getting gateway errors

Of course, but in the question it was implied that there was still mining going on.

What about if you haven't mined for a while? Won't the remainder be paid out regardless of the size?

I got payments of around 0.01-0.02 and my minimum is set to 0.25.  Just yesterday in fact. 

1KVviQoDmmFz2AyyFELkjZKzVvqGnEXAhj is my address.  I'm mining PPCoin at the moment, so that's why I'm not on Eligius.

Looks like you had set a minimum previously and one of the servers was using that amount instead.  I had it reverify your new options and all should be well.

PM sent

You should never get payouts below your minimum.  Above is normal because you enter queue when you reach your minimum.

Address?

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?

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

I literally lol'd at this.

^ This is pretty accurate.



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

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.

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.

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.


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.

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.

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"