Pages:
Author

Topic: [CLOSED] MtRed (PPS, LP+, API, 0 FEE) STRATUM on mine.mtred.com:3333 - page 3. (Read 176214 times)

donator
Activity: 2058
Merit: 1007
Poor impulse control.
So again, my apologies for jumping the gun with erroneous data. 
I rarely see such good humoured apologies on this forum, it's nice to see.

I generally don't make those kinds of mistakes, but, it happens.

Thanks organofcorti for finding the error!

-wk

I on the other hand always make these sorts of mistakes, which is why I'm good at finding them Wink
legendary
Activity: 1223
Merit: 1006
Regardless of a negative or positive buffer, it's obvious RR doesn't want to operate the pool anymore. He may have given bogus reasoning, but as long as he pays out what's owed, I don't see why we should care?

IMO it's probably for the best, (no offense) but RR was never the best at communicating with his miners or quick to fix the pool when it was broken. Too much downtime, etc. An irritation for miners, but I'm sure a massive headache and stressor for RR. I think this is good for everyone all around.

Running a pool certainly can be a huge headache, I can vouch for that.  (I spent almost all of last weekend working on Eligius...)

And my apologies to RR.  I did not realize my initial stats calculations (done for fun months ago at the request of a MtRed miner) were incorrectly tallying invalid blocks, and I didn't realize MtRed wasn't always PPS when I started them either.  So, using that data, and seeing a potential 1000 BTC+ buffer when the pool op claimed negative, it was worth mentioning.

Using the corrected data, they still did have a substantial buffer at the end of my stats (~570 BTC on 02/06/2013), and I'll trust that organofcorti's calculations from that point on are accurate, minus the missing block mentioned in my previous post, which should land with a slightly positive buffer.  Factoring in hosting and such, I'll just call it a wash, as its close enough to 0.  Seems that past couple of months have yielded pretty bad luck for MtRed, unfortunately.

So again, my apologies for jumping the gun with erroneous data.  I generally don't make those kinds of mistakes, but, it happens.

Thanks organofcorti for finding the error!

-wk
legendary
Activity: 1223
Merit: 1006
@organofcorti - Corrected my data to account for invalids. Our datas now match within rounding error up until block height 195530 @ 1345848076, which your data is missing entirely.

MTRED's data:
Code:
chain      hash                   timestamp      duration         amount        shares   confirmed
BTC b42aa431...17dc027d 1345848076 -1h-3m-29s 50.4055501 0 Yes

That's block 195530. No shares submitted, so a sanity check killed that round. I'd remove it from your data entirely.


Well according to the blockchain that block paid mtred, and would make the small negative buffer positive.

And MTRED would have paid miners. It may have been a long round or a short round, we don't know because the data is missing. We ca't even estimate from the average hashrate and duration, since thats in error too.



Actually, we know the duration: 19348 seconds.  And the proceeding round was a sequential blocks, with a duration of only 149 seconds and 2275352 shares?  Its obvious that the stats system simply added the shares to the next round... either that or MtRed had 65Th/sec of mining for 149 seconds.  I think the former is more likely (501 Gh/sec).
hero member
Activity: 504
Merit: 500
Regardless of a negative or positive buffer, it's obvious RR doesn't want to operate the pool anymore. He may have given bogus reasoning, but as long as he pays out what's owed, I don't see why we should care?

IMO it's probably for the best, (no offense) but RR was never the best at communicating with his miners or quick to fix the pool when it was broken. Too much downtime, etc. An irritation for miners, but I'm sure a massive headache and stressor for RR. I think this is good for everyone all around.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
@organofcorti - Corrected my data to account for invalids. Our datas now match within rounding error up until block height 195530 @ 1345848076, which your data is missing entirely.

MTRED's data:
Code:
chain      hash                   timestamp      duration         amount        shares   confirmed
BTC b42aa431...17dc027d 1345848076 -1h-3m-29s 50.4055501 0 Yes

That's block 195530. No shares submitted, so a sanity check killed that round. I'd remove it from your data entirely.


Well according to the blockchain that block paid mtred, and would make the small negative buffer positive.

And MTRED would have paid miners. It may have been a long round or a short round, we don't know because the data is missing. We ca't even estimate from the average hashrate and duration, since thats in error too.

legendary
Activity: 1223
Merit: 1006
@organofcorti - Corrected my data to account for invalids. Our datas now match within rounding error up until block height 195530 @ 1345848076, which your data is missing entirely.

MTRED's data:
Code:
chain      hash                   timestamp      duration         amount        shares   confirmed
BTC b42aa431...17dc027d 1345848076 -1h-3m-29s 50.4055501 0 Yes

That's block 195530. No shares submitted, so a sanity check killed that round. I'd remove it from your data entirely.


Well according to the blockchain that block paid mtred, and would make the small negative buffer positive.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
@wizkid057 and organofcorti

Why the witch-hunt? He's decided to shut down the pool. He's planning on paying users.

I don't see the problem.

Based on my initial data, it seemed appropriate to mention that the reasoning didn't fit the data.

organofcorti actually appears to not be on my side anyway. Wink after correcting my data I may not be on my side either. Lol

Yes, no witch hunt. I thought wizkid057's comment was fair enough - if someone's claiming to have been bankrupt by a negative buffer, then that should be checked. If MTRED did have a huge positive buffer, then redditorrex's explanation would have been false, implying he was using buffer to pay for server costs. That would have cast some doubt on whether or not he will fulfill his obligations.

AFAIK MTRED had a small negative buffer at the time the pool closed.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
@organofcorti - Corrected my data to account for invalids. Our datas now match within rounding error up until block height 195530 @ 1345848076, which your data is missing entirely.

MTRED's data:
Code:
chain      hash                   timestamp      duration         amount        shares   confirmed 
BTC b42aa431...17dc027d 1345848076 -1h-3m-29s 50.4055501 0 Yes

That's block 195530. No shares submitted, so a sanity check killed that round. I'd remove it from your data entirely.
legendary
Activity: 1223
Merit: 1006
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?


Because MTRED didn't start using PPS until 12th October 2011. You're including blocks that were paid proportionally.

As I mentioned, if you set the buffer to 0 on that day using my data you still end up with about a 1000 BTC buffer. We both cant be right...

Also, your dataset only goes up until 3rd Feb. It doesn't explain all the difference though. I'm still comparing datasets to find the differences. You might want to do the same.

Edit: From a quick check it appears you're also neglecting to subtract orphaned blocks. Thats the only other difference I can find so far. eg:

My dataset:

Code:
     timestamp  shares difficulty   amount orphan    buffer
165 1311026854  621401    1563028 50.13674      0 301.86576
166 1311065220 2810450    1563028 50.10101      0 261.88112
167 1311067565  236270    1563028 50.01450      0 304.33534
168 1311223958 9686912    1690896 50.00550      0  67.86614
169 1311269109 2770041    1690896 50.01400      0  35.94674
170 1311272103  270857    1690896 50.02950      1  27.93274
171 1311287350 1074074    1690896 50.08295      0  46.20250
172 1311326567 2407824    1690896 50.03550      0  24.98779
173 1311356721 1998726    1690896 50.12313      0  15.86280
174 1311372823 1041527    1690896 50.07450      0  35.09333
175 1311377806  409263    1690896 50.01850      0  73.00539

Your dataset:
Code:
         epoch difficulty sharecount blockreward confirmed poolbuffer
165 1311026854    1563028     621401    50.13674       Yes  301.86579
166 1311065220    1563028    2810450    50.10101       Yes  261.88116
167 1311067565    1563028     236270    50.01450       Yes  304.33538
168 1311223958    1690896    9686912    50.00550       Yes   67.86618
169 1311269109    1690896    2770041    50.01400       Yes   35.94678
170 1311272103    1690896     270857    50.02950   Invalid   77.96228
171 1311287350    1690896    1074074    50.08295       Yes   96.23204
172 1311326567    1690896    2407824    50.03550       Yes   75.01733
173 1311356721    1690896    1998726    50.12313       Yes   65.89234
174 1311372823    1690896    1041527    50.07450       Yes   85.12287
175 1311377806    1690896     409263    50.01850       Yes  123.03493

*facepalm*

Looks like a typo in my code that let them get tallied. I will recalculate when I get home. Your estimate still seems low.. . Sorry folks. Sad

@organofcorti - Corrected my data to account for invalids. Our datas now match within rounding error up until block height 195530 @ 1345848076, which your data is missing entirely.
legendary
Activity: 1778
Merit: 1008
Why the witch-hunt? He's decided to shut down the pool. He's planning on paying users.
Side note: A mtred user on IRC was complaining that apparently they aren't paying shares found after the last block, and that he was unable to withdraw his full balance...

yet. he was unable to withdraw his full balance YET. as expected.
sr. member
Activity: 280
Merit: 250
Nom Nom Nom
The current round that tipped the %50 rule will be credited, i just want to reflect it in the rewards table. Been busy, but I will probably get to it after work tonight.
legendary
Activity: 2576
Merit: 1186
Why the witch-hunt? He's decided to shut down the pool. He's planning on paying users.
Side note: A mtred user on IRC was complaining that apparently they aren't paying shares found after the last block, and that he was unable to withdraw his full balance...
legendary
Activity: 1223
Merit: 1006
@wizkid057 and organofcorti

Why the witch-hunt? He's decided to shut down the pool. He's planning on paying users.

I don't see the problem.

Based on my initial data, it seemed appropriate to mention that the reasoning didn't fit the data.

organofcorti actually appears to not be on my side anyway. Wink after correcting my data I may not be on my side either. Lol

hero member
Activity: 504
Merit: 500
@wizkid057 and organofcorti

Why the witch-hunt? He's decided to shut down the pool. He's planning on paying users.

I don't see the problem.
legendary
Activity: 1223
Merit: 1006
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?


Because MTRED didn't start using PPS until 12th October 2011. You're including blocks that were paid proportionally.

As I mentioned, if you set the buffer to 0 on that day using my data you still end up with about a 1000 BTC buffer. We both cant be right...

Also, your dataset only goes up until 3rd Feb. It doesn't explain all the difference though. I'm still comparing datasets to find the differences. You might want to do the same.

Edit: From a quick check it appears you're also neglecting to subtract orphaned blocks. Thats the only other difference I can find so far. eg:

My dataset:

Code:
     timestamp  shares difficulty   amount orphan    buffer
165 1311026854  621401    1563028 50.13674      0 301.86576
166 1311065220 2810450    1563028 50.10101      0 261.88112
167 1311067565  236270    1563028 50.01450      0 304.33534
168 1311223958 9686912    1690896 50.00550      0  67.86614
169 1311269109 2770041    1690896 50.01400      0  35.94674
170 1311272103  270857    1690896 50.02950      1  27.93274
171 1311287350 1074074    1690896 50.08295      0  46.20250
172 1311326567 2407824    1690896 50.03550      0  24.98779
173 1311356721 1998726    1690896 50.12313      0  15.86280
174 1311372823 1041527    1690896 50.07450      0  35.09333
175 1311377806  409263    1690896 50.01850      0  73.00539

Your dataset:
Code:
         epoch difficulty sharecount blockreward confirmed poolbuffer
165 1311026854    1563028     621401    50.13674       Yes  301.86579
166 1311065220    1563028    2810450    50.10101       Yes  261.88116
167 1311067565    1563028     236270    50.01450       Yes  304.33538
168 1311223958    1690896    9686912    50.00550       Yes   67.86618
169 1311269109    1690896    2770041    50.01400       Yes   35.94678
170 1311272103    1690896     270857    50.02950   Invalid   77.96228
171 1311287350    1690896    1074074    50.08295       Yes   96.23204
172 1311326567    1690896    2407824    50.03550       Yes   75.01733
173 1311356721    1690896    1998726    50.12313       Yes   65.89234
174 1311372823    1690896    1041527    50.07450       Yes   85.12287
175 1311377806    1690896     409263    50.01850       Yes  123.03493

*facepalm*

Looks like a typo in my code that let them get tallied. I will recalculate when I get home. Your estimate still seems low.. . Sorry folks. Sad
legendary
Activity: 924
Merit: 1000
Think. Positive. Thoughts.
Thanks for the hard work in maintaining/developing this fine pool. Sad to see it go.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?


Because MTRED didn't start using PPS until 12th October 2011. You're including blocks that were paid proportionally.

As I mentioned, if you set the buffer to 0 on that day using my data you still end up with about a 1000 BTC buffer. We both cant be right...

Also, your dataset only goes up until 3rd Feb. It doesn't explain all the difference though. I'm still comparing datasets to find the differences. You might want to do the same.

Edit: From a quick check it appears you're also neglecting to subtract orphaned blocks. Thats the only other difference I can find so far. eg:

My dataset:

Code:
     timestamp  shares difficulty   amount orphan    buffer
165 1311026854  621401    1563028 50.13674      0 301.86576
166 1311065220 2810450    1563028 50.10101      0 261.88112
167 1311067565  236270    1563028 50.01450      0 304.33534
168 1311223958 9686912    1690896 50.00550      0  67.86614
169 1311269109 2770041    1690896 50.01400      0  35.94674
170 1311272103  270857    1690896 50.02950      1  27.93274
171 1311287350 1074074    1690896 50.08295      0  46.20250
172 1311326567 2407824    1690896 50.03550      0  24.98779
173 1311356721 1998726    1690896 50.12313      0  15.86280
174 1311372823 1041527    1690896 50.07450      0  35.09333
175 1311377806  409263    1690896 50.01850      0  73.00539

Your dataset:
Code:
         epoch difficulty sharecount blockreward confirmed poolbuffer
165 1311026854    1563028     621401    50.13674       Yes  301.86579
166 1311065220    1563028    2810450    50.10101       Yes  261.88116
167 1311067565    1563028     236270    50.01450       Yes  304.33538
168 1311223958    1690896    9686912    50.00550       Yes   67.86618
169 1311269109    1690896    2770041    50.01400       Yes   35.94678
170 1311272103    1690896     270857    50.02950   Invalid   77.96228
171 1311287350    1690896    1074074    50.08295       Yes   96.23204
172 1311326567    1690896    2407824    50.03550       Yes   75.01733
173 1311356721    1690896    1998726    50.12313       Yes   65.89234
174 1311372823    1690896    1041527    50.07450       Yes   85.12287
175 1311377806    1690896     409263    50.01850       Yes  123.03493
legendary
Activity: 1223
Merit: 1006
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?


Because MTRED didn't start using PPS until 12th October 2011. You're including blocks that were paid proportionally.

As I mentioned, if you set the buffer to 0 on that day using my data you still end up with about a 1000 BTC buffer. We both cant be right...
donator
Activity: 2058
Merit: 1007
Poor impulse control.
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?


Because MTRED didn't start using PPS until 12th October 2011. You're including blocks that were paid proportionally.
legendary
Activity: 1223
Merit: 1006
OK, stats fixed. Sorry folk!

MTRED buffer from 12 October 2011 until bankruptcy is -33.68262 btc.

data here: http://www.bitbin.it/YsYg9VtP





Not home so cant verify your data... but if you take mine and simple set the buffer to 0 when they started PPS then its still almost 1000 BTC positive...

Ideas where/how our datas differ so much?
Pages:
Jump to: