Ming-Chuan

cc Istanbul BFT's author, @yutelin

Probably no :disappointed: https://github.com/ethereum/EIPs/issues/650 here is the algorithm's spec I followed, and looks like they still have not fix this issue yet.

The only way I know is to add some mechanisms to "unlock" the lock, but that will make the Istanbul BFT basically become Tendermint. IMHO, Istanbul BFT is just an...

@saltiniroberto published [Correctness Analysis of IBFT](https://arxiv.org/abs/1901.07160) which also points out this liveness issue. Two possible directions to fix the issue (without proof) are mentioned in section 6.2.1 and 6.2.2. You...

@Ywmet yes I misunderstand the meaning of the rule mentioned in https://github.com/ethereum/EIPs/issues/650: `Unlock: A validator is unlocked at height H and block B when it fails to insert block B...

@drequinox Yes, what you said looks correct. But I don't understand the reason why you point out these facts. Do these facts prove/disprove safety or liveness? > this is an...

Sorry I forgot to reply. > Even if we assume this unlikely scenario, after step 3 the 'locked node' will also participate in round change, therefore the network will recover....

> If a locked node receives the round change message, it will check if there is already a locked hash, if there is, it will repropose that. This is also...

Yes that scenario actually cannot happen because I misinterpret (I accidentally fixes safety issue for them...) the rule mentioned in ethereum/EIPs#650: `Unlock: A validator is unlocked at height H and...

cc @markdroth cc @ctiller cc @markb74 cc @ejona86 cc @TaWeiTu cc @napathome