From the Lightning Network paper:
It's not clear to me how the throwaway private keys should be shared between the two parties. What if Alice had shared her key to Bob but Bob refused to disclose his? In that case Alice couldn't submit the earlier commitment since otherwise Bob can steal her time-locked funds. But Bob could still spend his previous commitment without worrying his funds being revoked by Alice.
Is it considered an unfair situation? And how the protocol address the problem?
Quote
... once an updated commitment transaction is agreed upon, the previous commitment transaction pair is revoked by sharing the private keys needed to redeem those encumbered outputs. Thus, A shares its (throwaway) private key, and B shares its throwaway private key. If A were to sign and broadcast a revoked commitment transaction, B could not only immediately spend its own output, but it has both A's key and its own to generate a transaction which can spend the output which normally go to A after a delay.
It's not clear to me how the throwaway private keys should be shared between the two parties. What if Alice had shared her key to Bob but Bob refused to disclose his? In that case Alice couldn't submit the earlier commitment since otherwise Bob can steal her time-locked funds. But Bob could still spend his previous commitment without worrying his funds being revoked by Alice.
Is it considered an unfair situation? And how the protocol address the problem?
What you are looking at is a situation where A is attempting to broadcast a revoked committed transaction.
In order to revoke a previous transaction A would need to send her per_commitment_secret to B. This allows B to generate a revocation_key if A attempts to broadcast that revoked committed transaction. And that would transfer the BTC to B.
B does not need to share his keys because this is an unfair situation. Where A is trying to cheat the system.
