[1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff]

[testconpastas2]

I'm currently having a problem with the client:

Everything looks fine, I'm mining at a normal rate, and suddenly a popup comes up, saying 'wrong username or password'. I press ok, and everything goes back to normal.
A few minutes later, this repeats...

Anybody else with this problem? What can I do? Strange thing is the password is not wrong, as I just press ok and the mining continues (for about 5 mins)


Logs:
2012.10.02 [11:46]  Warning - slow network or server. Request took 52 sec.
2012.10.02 [11:46]  Work rejected. Server says: Duplicate proof of work
2012.10.02 [11:46]  Warning - slow network or server. Request took 43 sec.
2012.10.02 [11:46]  Warning - slow network or server. Request took 66 sec.
2012.10.02 [11:46]  Work rejected. Server says: Stale proof of work
2012.10.02 [11:46]  Warning - slow network or server. Request took 68 sec.
2012.10.02 [11:46]  Work rejected. Server says: Stale proof of work
2012.10.02 [11:48]  Warning - slow network or server. Request took 22 sec.
2012.10.02 [11:50]  Request failed: bad credentials

I`m having problems with lots of rejectings showing up randomly ( sometimes when a new block starts,  but i couldn't say if its cgminer 2.7.6 or last server modifications.

( i did change cgminer to the same time the server was updated).
I am mining in two servers with 2.7.6 and the rejectings are always in bitminter , this is why Im thinking in some kind of incompatibility (2.7.6 / Bitminter).

anyone with 2.7.6 is having rejecting issues?? 
Thank you.

[DrHaribo]

2012.10.02 [11:46]  Warning - slow network or server. Request took 52 sec.
2012.10.02 [11:46]  Work rejected. Server says: Duplicate proof of work

Duplicate proof of work is often caused by network issues. Also 52 second delay could also be due to a network problem.

Could you try "ping mint.bitminter.com" at commandline and see how that looks? Packetloss maybe?

I`m having problems with lots of rejectings showing up randomly ( sometimes when a new block starts,  but i couldn't say if its cgminer 2.7.6 or last server modifications.

The time the pool starts building upon a new block is usually the only time you get rejects.

How high a reject percentage are you getting?

[testconpastas2]

only sometimes, usually i get less than average, i got over 5% but last block i got 38% (over 250 rejecteds of 1300)  and rejecteds didnt't seem to stop till  i had to close and open cgminer in 4 windows.


can a rejected share become valid later??? because i think it was this block and now i only have 98 rejected instead of ~200

[DrHaribo]

only sometimes, usually i get less than average, i got over 5% but last block i got 38% (over 250 rejecteds of 1300)  and rejecteds didnt't seem to stop till  i had to close and open cgminer in 4 windows.

Sometimes you will see 5% rejected for a moment after a new round starts. This is because rounds always start with rejects, then the accepted proofs of work start to come in.

But 250 rejected out of 1300 proofs of work sounds like something is very wrong. Pool-wide the rejects are pretty low too.

Did you get reject after reject in all 4 separate cgminer instances?

can a rejected share become valid later??? because i think it was this block and now i only have 98 rejected instead of ~200

No, if it went down it must have been because a new round (block) started.

[willphase]

blocks from the future?

https://blockchain.info/block-height/201556 placed by BitMinter into blockchain at 2012-10-02 18:49:44 but block timestamp is 2012-10-02 19:02:42 which is actually almost 15 minutes in the future (I am typing this at 19:01)

Confused?

Will

[Mobius]

blocks from the future?

https://blockchain.info/block-height/201556 placed by BitMinter into blockchain at 2012-10-02 18:49:44 but block timestamp is 2012-10-02 19:02:42 which is actually almost 15 minutes in the future (I am typing this at 19:01)

Confused?

Will

Blockchain.info is not always accurate

[willphase]

Blockchain.info is not always accurate

This isn't from blockchain.info - this timestamp is obtained from the block header, and the block header is generated by the pool.  In this case, it looks to me that BitMinter must be generating block headers with future timestamps on them, and passing them to pool workers.

Check the block also on blockexplorer http://blockexplorer.com/b/201556 or, you can decode it yourself and view the timestamp manually:

./bitcoind getblock 0000000000000135f985cccb9e7d87af327c85fa75c46d7532ae406a711c21ec

time: 1349204562

--> Tue, 02 Oct 2012 19:02:42 GMT

Will

[hahahafr]

Well, does it matter?

[willphase]

Well, does it matter?

no

More just a curiosity, but if the clock on BitMinter is incorrect and this isn't being done deliberately (I can imagine some reason related to miners that take a long time to submit shares, and a perception that it might be somehow 'better' to have block timestamps in the future rather than the past...?) then this could cause more problems for DrHaribo so he might want to know, clockdrift can cause issues with SSL validation, for example.

Will

[DrHaribo]

In this case, it looks to me that BitMinter must be generating block headers with future timestamps on them, and passing them to pool workers.

Yes, this is what roll-ntime is about. Miners are allowed to generate new work to hash by fiddling with the block's timestamp (referred to as "ntime"). This way they don't have to talk to the server several times per second (in the case of fast miners) to get new work. As long as you don't get too far away from actual time this is OK and the block will be accepted by the rest of the bitcoin network.

[willphase]

Yes, this is what roll-ntime is about. Miners are allowed to generate new work to hash by fiddling with the block's timestamp (referred to as "ntime"). This way they don't have to talk to the server several times per second (in the case of fast miners) to get new work. As long as you don't get too far away from actual time this is OK and the block will be accepted by the rest of the bitcoin network.

ah, quite cool!  Thanks for the info!

Will

[WhitePhantom]

Yes, this is what roll-ntime is about. Miners are allowed to generate new work to hash by fiddling with the block's timestamp (referred to as "ntime"). This way they don't have to talk to the server several times per second (in the case of fast miners) to get new work. As long as you don't get too far away from actual time this is OK and the block will be accepted by the rest of the bitcoin network.

ah, quite cool!  Thanks for the info!

Will

Ditto!  I finally understand what roll-ntime means!  All I understood before now was that it allows miners to go longer without talking to the server.

[ralree]

I got a suggestion from PsychoticBoy to change the N in PPLNS from 2x difficulty to 4x difficulty. That would be to double the size of the shifts. Please speak up if you have an opinion on it.

As a 24/7 miner, I approve of this suggestion.

[hahahafr]

I got a suggestion from PsychoticBoy to change the N in PPLNS from 2x difficulty to 4x difficulty. That would be to double the size of the shifts. Please speak up if you have an opinion on it.

As a 24/7 miner, I approve of this suggestion.

Same here.

[testconpastas2]

Did you get reject after reject in all 4 separate cgminer instances?

Yep this is what I meant.

since then everything was ok. as usual.... I'll try to watch blocks' changes.

Thank you

[abeaulieu]

I got a suggestion from PsychoticBoy to change the N in PPLNS from 2x difficulty to 4x difficulty. That would be to double the size of the shifts. Please speak up if you have an opinion on it.

As a 24/7 miner, I approve of this suggestion.

Same here.

I guess I don't really understand that advantage of increasing the N in PPLNS. Miners just want more stability in payment?

I'm still quite impartial. Eventually as the hash rate creeeps up it's going to be necessary. If/When ASICs start being released, we'll probably see a spike on Bitminter with a steady (probably large) increase in hashrate thereafter. At that point N will probably be needed to increase several fold.

[Klober]

If this is talking about increasing how long shifts last from the current approximately 30m to 60m than I am definitely in favor. This will help even out my time when either A) I have to restart a miner or take it down temporarily for maintenance, and B) when I lose connection to BitMinter and my miner switches over to a backup pool for the next hour or two. This will also help with pool hoppers as they would need to remain in the pool that much longer to pull any significant amount of coins from the regulars.

Count my vote as an "AYE".

[DrHaribo]

Yes, increasing PPLNS's N up to 4x Difficulty will definitely reduce variance when you have some downtime. Just like it reduces the variance in the income of a non-24/7 miner, it will also reduce the variance in loss due to downtime for a 24/7 miner. Less chance of a big loss because your miners went down just before we found 3 quick blocks. It would still be a loss, but a smaller one.

It's not possible to pool hop on BitMinter though, and this won't make any difference in that regard. Of course you can move in and out of the pool as you wish, but since you can't predict beforehand whether you get high or low pay you can't "pool hop".

Making pool hopping impossible is really that simple. Just use a fair reward system. It's a shame some pools refuse to do so. And it is outright strange that so many miners still use those pools.

[willphase]

I'd certainly support increasing N - there appears to be no downside for people who mine on the pool 24/7 like myself.

Will

[miter_myles]

I'd certainly support increasing N - there appears to be no downside for people who mine on the pool 24/7 like myself.

Will

concur +1