A big side tangle is being created that is being stitched to the tangle at a certain time by transaction x.
getTransactionsToApprove is called and a tip is selected that approves transaction x then the transactions of the sidetangle are also approved indirectly.
In order to validate that the ledger is in a consistent state, the entire sidetangle must be traversed. It is important to observe that the network itself continues to relay transactions. Only the the tip selection mechanism is being blocked.
During the consistency check, if after a predetermined amount of transactions we didn’t reach the end of the subtangle or we didn’t encounter a milestone just quit the calculation and declare the subtangle inconsistent.
The disadvantage of this approach is that we may be disqualifying valid transactions.
If a strong node actually did the work of verifying the big subtangle and confirmed it with a honest transaction x, other nodes will orphan x and its subtangle even though though they are perfectly valid.
The reason that we are normally not doing long calculations is because we have checkpoints (aka milestones ). Milestones trigger IRI to create internal snapshots of the state of the tangle’s ledger. So when we check for consistency we can stop analyzing transactions below the latest milestones.
So the idea is to use checkpoints that are not milestones. The new checkpoints won’t confirm anything, but they will create internal ledger states (only the state confirmed by milestones will be the “real” state). With this approach we will stop analyzing the side tangle once we reach the first checkpoint. Then we can check consistency by comparing the internal states.
This approach doesn’t have disadvantage of the first solution.
The disadvantage here that it far more complicated than solution (1). There are also many open questions I have in my here about this approach, and probably more questions will come in the future.