I am not getting payed out can someone look into this.
Thanks
Send me a pm with your username & your payout method. Also, automatic payouts are hourly, so if you just changed it, it won't dump it immediately. |
|
|
|
|
Automated payments added to source
|
|
|
|
|
Automatic payout option added!
|
|
|
|
I should emphasize that mid-round estimates are fairly meaningless. It is always almost certain that round end will be far enough in the future that all current shares will be worthless. In particular, calculating the expected reward for already existing shares will be close to 0, while calculating the reward if the round ended now will be much higher.
However, the numbers you write might indicate a problem with the calculation. Please post all the values involved, as well as the lscore values of the last few shares - both in general and for the particular worker.
It seems to be behaving now, I think it was just the earlier implementation. It's off, just not quite as badly. Also, in your thread you say 0.001%(or less) fee!
If you use f=0, c=0.001 then it's not 0.001% fee, it's 0.1% fee. And it's the average - on any round it can be much higher. You can also consider using negative f to make the expected fee 0. so using $c = 0.001; $f = (-$c)/(1-$c); should result .1%? or should that be closer to 0? Is there a way to get to 0% without possible losses? So, if you're not trying to pool-hop, you will be paid slightly more than those who are.
Those not trying to pool-hop will, in expectation, earn exactly as much as those who are, per share submitted. Got it. |
|
|
|
My processing speed keeps pretty constant between 62,000-66,000 khash/s, but on my account page the hashrate is showing as between 40-50 MH/s. Is there a problem with the calculation or is there something else i'm not taking into account?
The hash rate is estimated based on the number of valid shares you submit relative to others. No, not relative  Just ((valid shares*4294967296)/600seconds) |
|
|
|
When do payout occur?
Specifically, once we find a block and it matures (120 confirmations) |
|
|
|
Well... you never know when you are going to find a block though. So you can't know when to rejoin. It's just good to be there right before it is found.
That works, unless you can use the current difficulty to estimate when the least profitable middle-third of the current round will occur, and then skip out on it. Disclaimer: I am terrible at probability and combinatorics. It's all magic quantum woo to me.Maybe, if the round was just one block. Plus, it's always possible to solve a block in less than the estimate. |
|
|
|
Open source, ok, where is the source of this "Miner Pool"?
Please don't claim that it is open source, if it is not.
Funny you mention that, I'm uploading it to a public github now!  It was based off Xenland's Miner Pool which was also opensource. He and I have spoken about cross-licensing, and came to an agreement. I'm comfortable enough now with the source too that it is on it's way shortly! Miner Pool is here : http://forum.bitcoin.org/index.php?topic=10617.0 |
|
|
|
So if i understand correctly, a simple situation would be this:
If Person 2 joined the pool at when the weighting was 5.
And the number means how many shares have been submitted at that weighting (would decrease within a given time period).
Person 1 Person 2 Share Weighting (Decreases with time until block is solved)
1 10
1 9
1 8
1 6
1 3 5
1 3 4
1 3 3
1 3 2
1 3 1
Person 1 submitted 10 shares. Has a total weighting of 55.
Person 2 submitted 15 shares. Has a total weighting of 45.
This means that Person 1 minimises their losses (or even equals or gets more than) Person 2 as he started mining earlier in the pool, and so the weighting starts canceling out the fact that Person 2 has a higher share of the reward.
No, that's what the scoring is meant to prevent. Share # Person a (Pool Hopper) Person b (loyal member) Share weight 1 1mh 1mh 1 100 1mh 1mh 1.1 10000 1mh 1mh 2 100000 0mh 1mh 4 1000000 0mh 1mh 10 Please note these numbers are purely made up, but they might help get the point across. Since you never know when a block will end and pool hopping exploits the start of a new block, it causes anyone trying to cheat to not get a disproportionate reward on short rounds. The share weights are not 1-1, and reset with each block, creating a constant sliding scale. Your rewards should be the same or better than a proportional share if you are not trying to exploit pool hopping. |
|
|
|
|
Well, looks like I'll lose just a tiny bit from this first round..... Since tx fees are mandated by the client, every cashout costs me .01 btc.
So, since I want to keep this pool free... Should I take the estimated tx fee out on cashout or should it make accounts go negative for the actual cost?
I run this for you, so I'm open to suggestions.
|
|
|
|
Sigh, my estimated earnings are still randomly decreasing and jumping about. Is the score calculation still flawed? I'll do my own calculations to determine how accurate it is. Edit: 50(13535/441462)=1.533 BTC My earnings are showing as 1.203 BTC  I am trying to iron-out the cheat-proof estimate. It's crazy logarithmic math. Payouts are also no longer 100% proportional. They are weighted towards miners who spend even time in the round. So, if you're not trying to pool-hop, you will be paid slightly more than those who are. Even if your estimate is off: the final payout will be correct. The final payout calculations are too complex and strenuous to run often enough for estimates. Could you explain the entire formula for calculating how we are paid? Then we can review it and fully understand how the reward system works. Also, with the current method, doesn't that mean the lower-power contributers (below 500 MH/s) are unfairly being disadvantaged relative to the high-power hashers, so long as the high-power hashers are present (or accepting shares while the low-power hashers are too)? No, hashrate has nothing to do with the scoring weight. It's weighted towards when you participate. Think of it as proportional scoring but also proportional to the length of the round you participated in. The actual proof and discussion is here if you want the technical details ( http://forum.bitcoin.org/index.php?topic=4787.0) |
|
|
|
Sigh, my estimated earnings are still randomly decreasing and jumping about. Is the score calculation still flawed? I'll do my own calculations to determine how accurate it is. Edit: 50(13535/441462)=1.533 BTC My earnings are showing as 1.203 BTC I am trying to iron-out the cheat-proof estimate. It's crazy logarithmic math. Payouts are also no longer 100% proportional. They are weighted towards miners who spend even time in the round. So, if you're not trying to pool-hop, you will be paid slightly more than those who are. Even if your estimate is off: the final payout will be correct. The final payout calculations are too complex and strenuous to run often enough for estimates. Yes its fixed now! Thank you very much  I had to rewrite all of the Miner Pool code I was using. The new code should be more reliable. |
|
|
|
"Yes, your earnings estimates are way off"
high or low?
They were both at the time that was posted. It should be somewhat close now. I'm monitoring closely. |
|
|
|
Just refreshed my stats, getting this error now: Notice: Undefined variable: roundEstimate in /var/www/includes/leftsidebar.php on line 54 Est. Earnings: BTC
Yes, sorry about that, just upgraded to the latest version of my framework. Yes, your earnings estimates are way off. I'll be fixing them shortly. Everyone should now be able to cashout, no more donatePercent issues (Really think it's fixed this time). Firstly, Happy Birthday! Secondly, im afraid im still seeing the error "Notice: Undefined index: donatePercent in /var/www/accountdetails.php on line 95" when i try to change my cashout address, it just remains the same. Back to the drawing board. I'll get it. UPDATE: Error should be gone, should be working now! |
|
|
|
Just refreshed my stats, getting this error now: Notice: Undefined variable: roundEstimate in /var/www/includes/leftsidebar.php on line 54 Est. Earnings: BTC
Yes, sorry about that, just upgraded to the latest version of my framework. Yes, your earnings estimates are way off. I'll be fixing them shortly. Everyone should now be able to cashout, no more donatePercent issues (Really think it's fixed this time). |
|
|
|
Hey, just wondering, I had been hashing since about 8 hours ago and I have seen that you found a block, I know my share would be pretty small but will my shares only go the next finding of a block as I received no share of BTC. Also it currently states 600 odd shares, so I guess it is carrying over to the next finding of a block?
Rexz
Yes, the block was probably found just before you started hashing. Just successfully cashed out. But I would like to point out two bugs with the process: 1. When I clicked "cash out" I was presented with a message "You have successfully cashed out 0 BTC to address (address)" and then my balance showed up as 0. However, I still got the BTC. 2. I received the full amount of BTC to 7 decimal places. I thought that all transactions were limited to two decimal places? I don't know, it just looks really awkward in my Bitcoin.  No, it should go to 8 decimal places. I'll fix that message to be correct. |
|
|
|
|
Just now waking up, I'm determined to fix the null donate_percent db issue.
|
|
|
|
User 176, please step forward..... you have the honor of our first probable solved block!
Hey, I found the first block! WINNING! I wasn't going to call you out, but yes! Thanks |
|
|
|
|
Show Posts
