Which one is a correct chain now?

72129 blocks with 1.43 diff or

71967 blocks with 0.25 diff (I tried to re-download the chain several times and I always picked this one up somehow)

I certainly have!  Doesn't look very promising when this is a recurring theme...

There are three chains...

One with diff 16K (0.244) @ block height 72031...
Plus one at height 72538...
Plus one at height 72129...

Something should be set, in code, to accept POS over POW, in the event where both are found at the same time. (If branched, the branch without the POS should immediately die, as it should be seen as invalid. Same when looking for block-heights. Since POS take almost no time to create, once the system decides it is time to create one. Killing the non-POS branch, which would interfere with the security that POS is intended to add. EG, building a chain on the non-POS branch would eventually lead to a separate POS there, causing another split... However, if the only chains accepted are the ones with the earliest POS, then we are all building off the same chain. Reducing the splitting, unless there truly is a network separation.)

Also note... this would require a constant "roaming" free IP slot. (Or multiple ones), so the wallets/coind can constantly "explore" for networks. Once they find x-connections, they stay there, as long as those connections are not lost. That should not be. Connections should be randomly closed, and replaced by ones that have not been tried yet. (Or ones that have not been tried in a while.)

I suggest closing one connection per x-blocks found, unless a replacement connection has not been found after having closed on a block previously found.

I think it just needs to use a more precise time, 1 second can be a long time when you have 2 different type of blocks that can be generated (one of which very easily).

Why not just make the time of block generation more precise by using milliseconds or even microseconds? The chances of a clash would then be much less likely and the winning block would invariably be the one with the smallest number of [milli/micro]seconds over the full second.

The chances of a clash when using milliseconds is 1 in 1,000
The chances of a clash when using microseconds is 1 in 1,000,000

I think the problem is that forks are not detected by the client and even if they are, there is no code to pick the best branch.
The client should always detect the longest chain and switch into it. It should be part of the code, right?

I also think that POS blocks should have lower priority than POW blocks, because POS are there to support the network when there are no POW blocks found.

I honestly think the other guys need to redownload... Our clients are rejecting the other chains for a reason... Are they failing an audit?

Block-height of the ONLY chain I can connect to, with all settings mentioned above, is still 72042.

I am guessing someone is using a client that is rejecting "speaking" to us, by killing our connections, if there isn't something "failing" in the other block-heights. Because they seem to be isolating themselves, and this chain will eventually topple-over the others, with the diff so low. (My wallet sees other heights, but no-one is delivering them... or they are, and they are failing an audit, thus, not accepted by the wallet as a "valid chain block".)

Sorry, but unless the others connect, I am going to just mine the hell out of the low diff chain until it surpasses the others. It is the only one passing an audit in my wallet, apparently.

That still says the same thing... block-height 72044 and it is constantly rejecting my connections...

The point of having a "reliable connection", is that it is reliable...

If we have to constantly keep manually connecting (apparently to the wrong chain that some individual wants us to connect to, instead of the one that works naturally), then there is no point mining on that poor connection, which will just continue to lead to crap like this.

The list of connections provided connects fine, well 4 connections... Removing all connections connects fine, to the same 4 connections. Not sure what is going on here, but it seems as though someone is purposely screwing with the networks in the pools. That, or they all have corrupted data, or they are isolating themselves, which is effectively doing a 51% attack, and then asking us to join the attacking chain, but refusing our connections.

You guys might want to check your ISP's, and see if they are rejecting our connections, which is keeping YOU isolated from US.

connection to IP 92.5.104.42 is not accepting connections, constantly closing them once connected.

Going back to the one that connects, which will rise above the others. I suggest you do the same. The other chains are high diff, and not growing as fast, and are selective to whom they talk with. You will constantly be forking talking to those unreliable connections.

Well, we weren't mining it this time, so no loss on my end.  I just had the daemon up so people could withdraw.  I hope payments haven't gone out into the ether..

P.S. Exchanges might want to halt delivery and acceptance for a while, until they figure out why the programs they are running, are isolating themselves from others on the network. You will be exchanging coins that are going to disappear soon.

Hard-coding blocks from those exchanges, on a network that is constantly isolating itself will NOT help.

Mining on the high diff chains will only work if you keep constant miners on there. Once they leave, the new miners will be connecting to the chain that is actually talking, the ones that you connect to without addnodes and the ones that are on the original addnodes listed on the front page.

Though, since the change, those four listed are not sending the block-chain to us, only telling us that they have a bigger block-height. Which is just useless if you want your chain to grow. It can't grow if you don't tell us what to build off of.

My personal wallet, the exchange, the block explorers don't seem to have an issue staying on the correct chain and the update is right around the corner.

I have these peers connected and all at the right height:
addnode= 192.241.222.16
addnode= 70.79.24.157
addnode= 70.98.114.237