1. No.
2. It wasn't TBF's checkpoint. I think most of those early blocks were mined by ocminer's pool when mining was resumed with -disablesafemode. TBF joined it a few hours later with a lot of hash power and forked ocminer's pool off. It happens.
3. I think an older wallet release should have a preference in such a situation. When BTC got forked in March of 2013 due to differences in data base layers of v0.7 and v0.8, they forced the v0.7 chain and prepared a solution later. It is still unclear if this FTC fork was an accident or a deliberate attack. Someone with an address 6yWiXr4cyVrtQPDfyus9AR4v3KehpyXpBL injected a very fast block sequence. He managed to get 6 blocks in 2 minutes, though time stamps may be not accurate. This chain was validated by v0.9, but not by v0.8 and v0.11 which went into safe mode immediately. Therefore no RPC and no new blocks could be submitted, though their Stratum front ends were running as usual. When safe mode was disabled 10 hours later per my suggestion, this chain moved on and carried a higher cumulative difficulty than the v0.9 fork in less than a day. I hope you know that competing PoW chains are chosen by cumulative difficulty rather than length. Many v0.9 nodes reorganised to the current chain on their own. Therefore my checkpoint secured what had been decided already by the protocol.
Thank you for clear explanation about what happended technically.
the TBF's checkpoint I referenced is about the blockchain actually.
miningpoolhub and give-me-coins were on A blockchain and TBF was on B blockchain. I was disappointed that B blockchain was selected without clear reason, explanation.
I understand that you were busy with wallet issue to prevent any new attacks but blockchain selection could be A too. Additionally, there were some communication error between feathercoin devs. miningpoolhub and give-me-coins were just mining on blockchain A more than a day thinking that it's all okay.
We didn't insist this blockchain to be selected, just followed the dev's comment and kept pool open.
There were two dev as you know, one at forum.feathercoin.com suggesting 0.9.x and you suggested 0.8.x on here. Sadly I didn't know you were the dev too.
You are saying that PoW chains are chosen by cumulative difficulty in technical reason but if blockchain difference is too big, then wallets just ignore each other as different coin. Blockchains don't revert over the mining confirmation heights if there's no forced checkpoint as you know.
Sadly, blockchain height were too different and just went their own ways.
So selecting B blockchain is not automatically, technically done. You are saying like B blockchain was purely chosen by wallet itself explaining the PoW compete mechanism. Actually it's not. There were two blockchains at last, forked, and not merged, will not merge automatically forever if you didn't insert checkpoint.
If your statement was right, you would not needed to add checkpoint code too. Because it will be fixed automatically.
"A" blockchain was candidate too. My wallet had more than 48 connections and have seen many of them were synced to my wallet's height too. (wallet's max connection was 50)
There were more than half of peers on 0.9.x too. I saw that TBF op saying 0.8.x wallets are triple more nodes but it was not actually. 0.9.x were more on my wallet. So it can't be easily said that 0.8.x is the majority version.
In addition, I already told this, official website was releasing 0.9.x to users. I'm sure everybody will agree that official website version is the major.
But you just have chosen B blockchain by checkpoint code without explaining reasons.
And saying like this is done automatically, technically chosen by PoW cumulative difficulty competes.
You see why I'm disappointed?
There were not clear explanation on selecting blockchain. I'm not disappointed that why my blockchain is not selected. Disappointed about communication.
I don't want to blame the other dev on forum.feathercoin.com, and you.
I just want to express what point I disappointed and expect better communication next time.