Bitminter bitcoin mining pool - shutdown mining 2020-07-01 website 2021-06-01

[in2tactics]

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!!!

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.

[kano]

...
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.
...

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.

[in2tactics]

...
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.
...

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

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.

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

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.

Increasing the N reduces variance, not reward.

Agreed

[organofcorti]

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.

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.

[wmabern]

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!!!!!

[teslaman]

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 .

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.

[wmabern]

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.

[gt_addict]

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 

[wmabern]

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  

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.

[wmabern]

So finally a block - a stale one. Just when I had 2 high % shifts left on the pay board. Oh well.

[gt_addict]

I cannot believe it. "gafter" finally broke the bad streak, only to be thanked with a stale block  

Fingers crossed for a good old double in quick succession.

[Darthswan]

Coming up to my last days of mining in this pool.

[Mikestang]

Out all weekend and came home to see the round duration had reset on my monitor, so I was like "yay" but then I saw it was a stale solve.  It's sad to see that one bad block has caused the pool to lose like 35% of its hash.

[Cali_LiteCoin]

Hit the block again!!! , keep going guys!!

[HerbPean]

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  

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.

99% block are expected, getting a stale or orphan on that particular block is also and probably just bad luck (Maybe code optimization COULD save one of those stale block but it's pure speculation). Knowing that you'll be getting high diff block in any pool and IF you decide to mine at Bitminter then, someday, you'll have to face a long period of time without getting a payment.

People have a very small memory when it come to luck. They look at feet instead of the horizon, meaning the AVG payout of this pool is far from been bad even if you hit some back luck on road which is normal.

Lower pool hashrate only means you'll have to wait longer to get a bigger payment because, yes the pool will find a block even if it takes a week.

The only issue I got with the 1 block a week/bad luck is that 1 week is about half a difficulty period and during a period of diff increment it hurts, especially when the block is stale like the last big block. But it's part of the game ... it's like getting 4 block in the same day with a super lucky day.

Running after luck is a non-winner strategy from my humble opinion.

I mined here for like a year and half, people quit on bad luck and come back when the luck is over the AVG. It's also part of the game...

I moved on, but luck as nothing to do with my decision.

There is a lot of users on the Top 50 that I have been pushed down the list but when the bigger guy quits on bad luck, they are always making their way to the top. They look on the long term.

This is just my humble opinion 

[Antdog319]

Hello all,

 Sadly after 6 months of mining, my apartments are coming down on me hard about my mining setup, threatening an eviction if I did not shut them down, they were quoting some fire code bs. Been on BitMinter since buying my first Antminer U2, this is a very fair and awesome pool (Thanks Bitminter Team!) that has just been experiencing its law of averages lately. What I mean is for months it was hitting below the expected CDF of 50%, so it was bound to happen. That has nothing to do with leaving though, when I get out of apartment Auschwitz here and into a house I plan the buy new units and get back in.

Until then, I need to sell my over 20Th/s of equipment. If anyone is interested, please take a look at my Craigslist ad. (I will have pictures up shortly.)

http://sandiego.craigslist.org/nsd/ele/5576654359.html

If you're far from California but interested, I will ship to you. (Never shipped anything but, I'll figure it out.)

Thanks for reading.

Updated: 5/08/2016

[gt_addict]

Anyone else getting the occasional disconnection? Its been happening for the past couple of days and again today. Never had a problem before 

[Mikestang]

No problems here, my workers have been mining away 24/7.  Glad to see that little run of green blocks, certainly helped make that red one feel better.

[csa00]

https://bitminter.com/banner/pool

Mint new bitcoins at the Bitminter mining pool!

Why you want to join us:

• A brand you can trust, serving your mining needs since 2011
• Over 375 000 total users since launch
• Merged mining - free namecoins with your bitcoins, without slowing your bitcoin mining
• We pay income from transaction fees in addition to the freshly minted coins
• 99% of mining income paid out
• Under continuous development and improvement

Joining us takes seconds:

• 1. Choose a user name to sign up at https://bitminter.com/signup
• 2. Point your miner to mint.bitminter.com:3333 with your user name and a dummy (x or 123) password
• 3. Profit

Hi Bitminter Community,sorry to bother.

why does the ghps is not represented on the site when bitminter is running, but it does appear properly when i use my cgminer with antminer u3 how come?

[gt_addict]

The hashrate on the site fluctuates. I cant remember the reason why but its basically an average. Since ive been with bitminter the shift hashrate has always matched the hashrate of whatever miners I have been using.

While a shift is happening you may see considerably more Ghps than you have, then other times less. But it is always correct when the shift completes