Why is this taking so long to resolve?
It actually was resolved pretty fast. (6 blocks ~ 1h)
There was a second incident on July 5th, with a 3-block orphan branch. There are still v2 miners out there, and the v3 miners are still accepting recent block hashes from them, and mining new blocks on top of them before they have time to validate (or even see) those parent. The fork was blotched.
Could you explain this further
I am not an expert, I am just learning from what is posted on forums, too. But basically mining pools have a way to "steal" the hash of newly mined blocks from each other, even before those blocks get out to the relay nodes. They must immediately start to mine a new block Y with the stolen block X as the parent, without waiting for X to propagate out to the relay nodes, otherwise the pool that mined X will have many seconds of head start. If they are lucky, they will solve block Y even before the block X has finished propagating to the nodes and the nodes have validated it.
Those miners do validate the transactions that they put into block Y (in parallel with mining it), but they cannot start validating block X, or even check whether it was mined by a v3 miner, because they only have the hash of block X, nothing else. Apparently they used to fetch and check block X, also in parallel with mining, once it became available; but F2Pool had stopped doing so, because (they said) it had cost them a block reward once (perhaps by using up some of their internet bandwidth).
Usually this shortcut works, because the block X was verified by its miner, and is valid 99.99% of the time. Hoever, just after the BIP66 rule became active, the miner BTCNuggets, that was still running v2 software, happened to mine the next block X. The BTC-China pool stole its hash from BTCNuggets, and F2Pool stole it from BTC-China. F2Pool (who had upgraded to v3) mined a new block Y on top of X, without realizing that X was invalid because it was mined with v2 rules. Then F2Pool mined another block Z on top of it, and AntPool mined another one on top of Z, and so on -- all without realizing that X was invalid.
I pretty much understand that instead of using bitcoin core they used an alternative SPV nodes which doesnt check the whole block chain, were not denying v2 blocks invalid when BIPP66 protocol went into effect but is faster to run to give them an edge. Doing so they were mining v2 and v3 blocks and accepting both because it took a while for them to get denied by the network. They should have know that they were going to loss the v2 blocks so it could have been greed even thought it meant bogging down the whole network. Even thought it was counter productive becuase v2 blocks were worthless. The current issues people are having are with the stress test and some transactions that are still kicking around from people who haven't upgraded there nodes or pools that haven't upgraded. All together it's having a bogged down effect felt with transactions being slow as well as miners processing worthless transactions from the test and maybe from invalid v2 blocks kicking around.The problem will resolve itself it just will take time to clear up all the junk and while miners and pool and node owners update. It's really not that big of a problem just it was last minute which they should have warned miners and pool owners in advance because they took profit hits. Big pools like f2pool and ant-pool are at fault themselves because they should be aware of stuff like this because the centralize and made a business out of it unlike small miners who have a full time job and do it as a hobby.
P2pool and forestv were on top of things for there community releasing updates ahead of time and not getting paid to do so if he could do that there is no excuse for big time pools. Support decentralized and get paid more no fees and no one taking a cut of your hashpower.
But you have to make sure you stay up to date with your node.