The following content was written by rixtox on February 14, 2018, 09:38:40 PM in the thread How the disposable private keys are being shared in Lightning Network?. All content is owned by the author of the bitcointalk.org post. (original)
From the Lightning Network paper:
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?
The following content was written by Random Seller on February 15, 2018, 02:14:18 AM in the thread How the disposable private keys are being shared in Lightning Network?. All content is owned by the author of the bitcointalk.org post. (original)
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.
