1. Please tell me about the theblocksfactory pool. Is it your pool?
How can the pool run the latest wallet less than 2 minutes you announced.
2. Why did you insert theblocksfactory's checkpoint at latest commit?
This line you inserted.
( 1114311, uint256("0x93515f222f16a9ff3db6594e5ee7c12924cff9ba05b01dbe551d0a9e65dd141f"))
3. You are insisting theblocksfactory's checkpoint without any comments just pretending as fixing the bug. commit text was just plain not stating which blockchain will be chosen.
Do you think it's fair?
miningpoolhub, give-me-coins followed most active working dev(Wellenreiter)'s comment and you selected opposite blockchain.
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.