Quote from: a123 on August 27, 2014, 07:24:23 AM

I've noticed several points in time today when consecutive POS blocks led to the blocks getting stuck in some clients. I'm comparing with only blockexperts.com/slm.

79651 - 79653: POW -> POS -> POS: The time difference between these three blocks is almost an hour. It showed that I had 23 orphans.

POW (I mined 79651) -> POS (79652@03:52:35) -> POS(79653@04:41:10) -> POW (I mined 79654@04:41:49)
-> POW (I mined at 03:52:52 -> forked) ... 22 POWs -> *Fork resolved back to the blockexpert's chain. ^

This happened another time: I noticed that blockexperts got stuck at a POS block, but it later resolved towards my chain. I can't remember the block numbers.

Same issue at POW@79776 -> POS -> POS -> POS -> POW (79780).
-> POW (+4 minutes after POS) -> 10 POW orphans -> fork resolved ^

Appears to be happening right now @ 79793. As of now it's 20 minutes since the block expert's client accepted a block, while it appears my client has ignored the POS and is happily going down it's POW chain.

Anything to do with the client #? Blockexperts seem to be a bit behind (v0.3.2.0-alpha vs v0.3.2.0.2-g53d7c33-alpha).

In all these cases, my client rejected the POS despite it being obviously earlier. So I'm guessing the POW score somehow made my client think I'm the winner, and the POS time made the blockexperts think it's the winner?

My client abandoned the POW chain only after another POS block hit in - I'm guessing it is some block score threshold hysteresis?

Since I'm obviously not the only miner around, I assume all other miners also couldn't submit their blocks through?

[edit: 79794, a second POS, brought the network back in line. i don't think this should be the correct behaviour though?]

Thank you for pointing this out. Could you send me your debug.log file in ~/.slimcoin. I would like to see what is causing those orphans after the PoS blocks.