Currently a lite client must check 2/3 + 1 signatures.

I believe that the lite client could instead check that 1/3 + c signed the header hash, and you get a sliding scale of guarantees in exchange for better efficiency.

• When c > 0, the lite client is guaranteed that upon seeing conflicting satisfying commits, the 1/3 assumption has been broken. Upon learning this, the client can feel free to panic / abandon the chain until manual override, etc.
• For 0 < c < 1/3, the lite client increases its odds of catching the double-signing node.
• When c > 1/3, the lite client is guaranteed that upon seeing conflicting satisfying commits, it can create a fraud proof for at least one entity.

Since seeing a successful fork is such an extreme event, it seems likely to me that many lite clients may find it sufficient to be aware of the fork and deal w/ it via social consensus, and to not have to be able to submit the fraud proof.

(This whole point is moot once aggregate signatures are in. Then theres no advantage to only verifying a partial amount)

Moved from: cometbft/tendermint-rs#54 (comment)