Topic: Bitminter bitcoin mining pool - shutdown mining 2020-07-01 website 2021-06-01 - page 40. (Read 325004 times)

The 99.1% block I think you were talking about took 8 days 8 hours. There was also a lot more hash in the pool then. There have been plenty of 90% blocks since then, but some of those only took 4-5 days because of the higher hash on the pool.
The number of users has gone from over a 1,000 most of the time then to the low 900's now.

I don't know what it will take to get the users /hash back. But if something doesn't cause a turn-around soon, it will be time to look for another pool myself, unfortunately.
I would rather get more smaller payouts than a single payout once a week or more (8 days 19 hours now.)

I think this all goes back to the debate that was had in this thread a page or so back. More frequent smaller payouts vs. larger payouts over a longer amount of time.

Just about all of my high % shifts have fallen off the board now, so when this block is finally hit, I will have probably spent 4x more on electricity than the payout will be worth.

I was browsing other pools as an alternative last night. Some have hit over 300 blocks in the last week. I'm not talking about moving to a Chi pool, either.

I want to be loyal and stick around here, but when it costs more to stay here than to move on, I will probably have to  explore other avenues.

I went back through the blocks, I didn't make note of the time taken to get the block but back at the beginning of January there was a 99% block 

What's the record time for NOT finding a block? I'm too lazy to look it up. 

p.s.

If someone will send me 5 BTC, I will put it all toward buying hash rate to point to the site.
Seems like the number of user and the hash rate have been dropping steadily over the last week. Not a good sign.

Sorry for the confusion, yes, increasing the number of payable shifts to more than 10 is what I was talking about. I almost put just "lengthening the shifts", but I added "payable" thinking that would avoid the confusion. Clearly not.

Like the others said, an increase, or decrease won't earn you more, or less. The only value to increasing the number of payable shifts is to see less of those 0 BTC shifts, it's purely superficial. But unless you increase that number to something like 35, then these +90% bad luck streaks are still going to leave you with those 0 BTC shifts.

Good day folks,,

I sincerely appreciate all the well-reasoned, knowledgeable replies to my inquiry from yesterday.

I wish I were knowledgeable enough and smart enough to debate these ideas and concepts with you.
Alas, I'm not. (Perhaps pre-dementia setting in? Or, I never was that smart to begin with. )

Anyway, I AM able to understand and comprehend some of the information and ideas being discussed and how they will effect the pool and the pool users. However, it is still way over my head to make reasoned, well thought out, and helpful conversation regarding this topic.

I do understand the operation and how things work in this type of pool system. But with my limited comprehension and understanding of the system operation, I realize it is best to let the "pros' run things as I can't wrap my head around how changing one part of the system will have a butterfly effect on other parts. But I do know that it can happen and will.

I'm sure the powers that be (Doc) has a much clearer picture and knowledge about how best to run this operation and the best way to make the operation run the smoothest.

Since I was presenting my thoughts purely from the perspective of a rookie miner who is looking to make more money by being able to keep more of my high % scores for payouts before they "roll off the board", I still can't say I fully understand how this would adversely effect others. But I do definitely have a better idea now how this could /would throw the system out of equilibrium.

Again, thank you all for your thoughts. I can't say that I understand all of what was said, the meaning of it, or the circumstances it could produce, but I do understand more.

Thank you all very much, it is greatly appreciated!!!!!

Unless I've made a silly mistake somewhere, the reward for each share is on average (B + fx) * Dp / Dn * (1 - f) where B = reward, fx = transaction fee, Dp = Pool difficulty, Dn = network difficulty, and f=pool fee.

No matter how DrH changes the shifts or shift sizes, the average reward per share will remain the same -- although each share might be paid smaller amounts multiple times.

The way I have written it is correct. I was explaining from the pool's point of view not the miner's.

If we hold the number of shifts constant and increase the shift size, the payout for each shift will remain the same. If the payout remains the same for each shift, an increase in the number of shares paid per shift will result in a decrease in the amount paid per share.

I will admit that I can see how a change in point of view could lead someone to falsely assume that they would be rewarded less.

I think the first part of your clarification may still be confusing for some folks.

The number of shares contributed by the miner will increase proportionally with the number of shares paid during a shift because the percentage of contributed shares by the miner should remain the same, pool variance over a different sampling window of a different sampling size notwithstanding.

Agreed

It's best to explain that statement since the way you've written it implies that you'd be rewarded less, which is false.

You left out the point that each share will, on average, be paid more than once ... so result, on average, with the same reward.

Increasing the N reduces variance, not reward.

It is common for pools that use PPLNS to set N equal to the network difficulty. That is because the average number of shares to find a block is equal to the network difficulty. BitMinter uses the PPLNS with shifts method and the number of shares paid over all shifts is approximately equal to the current difficulty.

Now, if we increase the shift size or the number of shifts while holding the other value constant, the number of shares paid will be greater than the average number of shares to find a block and the amount paid per share will be less. You appear to be advocating for this type of change. Is there any particular reason you want to increase the number of shifts?

I believe that there are valid arguments for a pool to set the number of shares paid to a value greater than, less than, and equal to the network difficulty. In our case, a pool with low overall network hashrate, I believe we should set N equal to or less than the network difficulty.

I refrained from explaining PPLNS with shifts further as it adds nothing to the overall discussion, but if you wish we can discuss that as well. As an aside, PPLNS with shifts is also sometimes referred to as Pay Per Last N Groups (or shifts) PPLNSG. Yes, I know the acronym looks wrong. It is not my acronym.

I wasn't necessarily advocating for longer shifts ( I don't think I was, or not in the way I'm thing about it). Maybe I was and didn't even know it .

I was looking at something like increase the number of payable shifts from say the current 10, to maybe 12 or 15. I don't know if that would be considered making the shifts longer or how that would effect payouts. I'm a newbie to all of this, so I don't really understand how changing one part of the system would have an effect on another part of the system or the users of the pool.

If someone has a few minutes, and could enlighten me in simple-mans English and in just few paragraphs or two, I would greatly appreciate it.

When I hear the term "lengthening the shifts", I think of increasing the time it takes for one complete shift (which currently has been hovering around 5 to 6 hours depending on the hash being put it to the shift) being increased to 8 or 10 hours or something like that to hit 100%.
That wasn't what I was talking about or intending.

The thoughts I'm having is to leave the 5-6 hours it takes to complete a shift untouched so you are still completing  the shift counter in the same amount of time as before (until the shift counter reads 100%.) (And at ~5-6 hours)
BUT,
Instead of completed shift work being rolled off the "Still eligible for pay" table after 10 shifts (~55-65 hours), we keep those shifts eligible for pay for, maybe, 2 or 5 more shifts.

Is that what you mean when you say "lengthening the shifts" (because the wording confuses me) and I'm just looking at it in some weird, odd way??
Or, does it make a difference if that is done and does it take longer for payouts or cause lower amounts of payouts?

Please, someone in the know please enlighten me as what the damages would be and why what I propose is such a bad idea. I'm just trying to understand.
Please explain in simple English, (please) as it has taken me 30 minutes or more to type out what I think I'm trying to say. LOL
As I'm not sure if what I typed out was what I have meant to type say anyway! 

Thanks for any and all insights!!!

I thought I should chime in on this, since lengthening the payable shifts would actually force me to leave. I'm not sure how much longer I can keep my ~10.7TH of Neptune miners running anyways, but that would certainly kill it for me. Those dead zones are a gambling opportunity to save on electric without losing anything. Just 24hrs of downtime saves me $15. I hope to keep going until the halving, but we'll see. Would be great to see that idea bring more power hungry miners back to the pool, even if they only mine for around 2/3 of the month.

I could be wrong, but I doubt that most people leave over the payable shift length and instead leave because of the periods of bad luck. Nearly a week is a long time to see no payouts and some people just don't have the patience.

The luck has indeed been bad lately. Jan and Feb were great though, well above expected earnings, so I can't complain. Sucks when it evens itself out though.  

Thank you for your pool DrHaribo! I started mining on Bitminter and will likely end here.  I think BTCGuild is the only other Bitcon pool I've used. Wish I could keep going, but the centralization is a killer. Can't say I'd cry over a few KnC-sized data centers burning to the ground, lol.

i cant see what you are on about. What specific section of the "my account" menu are you talking about?

ON the accounts page what does the future column represent?

It's also interesting (and annoying) to see that in the last two months the same person has a hit a block 4 separate times. That's pretty damn lucky.

No personal animosity, just wish it were me. If I weren't too busy today (and hated math) I would sit down and and try to figure out the odds of that happening. I'm sure the odds are pretty darn steep.
Maybe that person should be playing Powerball also.

Even a 96.4% CDF block back in December only took 4 days and 22 hours!  

Continuing to watch those high percentage scores fall into non-payable zone is getting very, very old.

I may have to look around at some of the other pools that pay out more frequently, but with a smaller payout. I know they will eventually work themselves out evenly in the long run. But...
But the long run isn't today.

I'm pretty sure that is the reason the hash power is going somewhere else. Which in turn causes a vicious circle. Less hash=longer to hit a blocks.

Hitting 4 or 5 blocks a month is not doing it. (That number may be, and probably is slightly inaccurate, but is probably becoming the average.) I know it evens out eventually, so I don't need to hear about that info.

rant/

Also just noticed the difficulty has gone back up again. Oh joy!

The last 90% block (92%) only took 5 days 13 hours

I was thinking the same thing when I checked the website. I wore red underwear (not the girlfriends stuff though) when the cdf turned red but no joy. Can't remember the last time I saw a 90% block.

Six and a half freakin' days for a block!!  
That's not sustainable.

When you plan out your strategies for 5 to 6 1/2 days max to hit a block and it's already over 6 days 13 hours in duration. That certainly throws a left-handed monkey wrench into the gears.

Well, that might be a good thing because the last time I bitc#ed and complained, a block was found soon after (actually it was found as I typed) So let's hope for the best and cross the fingers!
:-)

AaronS, thanks for mining with us for such a long time.

It is indeed a shame that mining has become so centralized.

I hope you'll still be part of the bitcoin world, even though you won't be mining.