<p>So the question is if it would be unfair to Alice if:</p>

<ul>
<li>Bob wouldn't reveal his secret information and  </li>
<li>Bob broadcasts the previous commitment transaction</li>
</ul>

<p>Now, the only case in which Bob would broadcast the previous transaction is if it would have a higher balance for Bob. That would mean that the intention for the channel state update is that Bob would like to pay Alice for something. However, an update of a channel state (balance) is a two-step process:</p>

<ol>
<li><p>Alice and Bob exchange the new Commitment Transactions</p></li>
<li><p>Alice and Bob invalidate their prior Commitment Transactions (by sending each other a (secret) piece of information)</p></li>
</ol>

<p>That means as long as Bob doesn't reveal his secret information to Alice, the channel state is not considered as updated. Therefore it's perfectly fine for Bob to broadcast his previous Commitment Transaction as it represents the current balance. So it wouldn't be unfair to Alice, as from her point of view she hasn't been paid (yet) anyway. Only after she received the secret info from Bob, she would consider the payment as successful.</p>

CC BY-SA 4.0
2018-10-19T14:41:41.090Z
2018-10-20T09:59:16.550Z
2018-10-20T09:59:16.550Z
Thomas Braunberger
<p>From the <a href="https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf" rel="noreferrer">Lightning Network paper</a>:</p>

<blockquote>
  <p>... 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.</p>
</blockquote>

<p>It's not clear to me how the throwaway private keys should be shared between the two parties. What if Alice shared her key to Bob but Bob refuse to disclose his? In that case Alice cannot spend the earlier commitment since otherwise Bob can steal her time-locked funds. But Bob could still spend his previous commitment without worrying his fund be revoked by Alice.</p>

<p>Is it considered an unfair situation? And how the protocol address the problem?</p>

<lightning-network><micropayments><micropaymentchannels>
How the disposable private keys are being shared in Lightning Network?
Rix
# How the disposable private keys are being shared in Lightning Network?

(Asked by: username_0 on 2018-02-13)

From the [Lightning Network paper](https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf):

> ... 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 shared her key to Bob but Bob refuse to disclose his? In that case Alice cannot spend the earlier commitment since otherwise Bob can steal her time-locked funds. But Bob could still spend his previous commitment without worrying his fund be revoked by Alice.

Is it considered an unfair situation? And how the protocol address the problem?

**Tags:** lightning-network, micropayments, micropaymentchannels


---

## 1 answers

### Answer by username_1 on 2018-10-19. Score: 4

So the question is if it would be unfair to Alice if:

* Bob wouldn't reveal his secret information and
* Bob broadcasts the previous commitment transaction

Now, the only case in which Bob would broadcast the previous transaction is if it would have a higher balance for Bob. That would mean that the intention for the channel state update is that Bob would like to pay Alice for something. However, an update of a channel state (balance) is a two-step process:

1. Alice and Bob exchange the new Commitment Transactions
2. Alice and Bob invalidate their prior Commitment Transactions (by sending each other a (secret) piece of information)

That means as long as Bob doesn't reveal his secret information to Alice, the channel state is not considered as updated. Therefore it's perfectly fine for Bob to broadcast his previous Commitment Transaction as it represents the current balance. So it wouldn't be unfair to Alice, as from her point of view she hasn't been paid (yet) anyway. Only after she received the secret info from Bob, she would consider the payment as successful.


---

