It may have aggravated the situation somehow. Not on the problem itself (because blocks on the other chain were always rejected anyway) but it may have slowed down some transaction propagation. But when the problem was identified multiple seed nodes were still connected to nodes on both sides, so I don’t think it was really problem.
It would have reduced the probability of that happening, but it would have happened anyway at some point.
Ultimately they would have reached the same height yes, but it takes time to adjust.
No, it uses the chain with the most accumulated difficulty. Destroyed share days do no count here.
It’s not your grant specifically, it could have been any grant.
This is what happened: 2 miners found a block at about the same time. It happens frequently but what was special this time was that the 2 blocks included a custodian grant. They both broadcasted their blocks, so some of the network received one, and others received the other one, and a few seconds later they all received the other one. The problem was the nodes rejected the second block they received because it included a grant to a custodian that was already elected (in their view of the chain).
The update of the “already elected custodians” is handled properly when the reorganization happens. But we missed the fact it may prevent the reorganization from happening in the first place.
The fix solves this. It only considers the custodians that were elected before the height of the block the client is checking. So when you install it you should start downloading the highest chain immediately.
