<p>You touch a point that is a bit subtle but never the less no problem. I have explained it step by step in the channel operation chapter:
<a href="https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc" rel="nofollow noreferrer">https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc</a></p>
<p>TL;DR:
While changing the balance of a channel Alice does only revoke her tx and state after she has received signatures for the new state from Bob. Thus if Bob becomes unresponsive during the process and alice dies not have new signatures yet it is save for her to force close with the latest state for which she does have the signatures (as that state has not been revoked yet)</p>
<p>While moving forward the balance for a short moment each side of the channel temporarily has two fully signed but unrevoked commitment transactions. This is secure though as publishing the &quot;old&quot; state is not wrong while the new one is not fully agreed upon.</p>

CC BY-SA 4.0
2021-08-04T18:12:48.197Z
it seems the link has changed to https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc
DeLorean88
CC BY-SA 4.0
2021-06-28T04:48:23.007Z
2021-08-11T09:05:00.687Z
2021-08-11T09:05:00.687Z
Rene Pickhardt
<p>After reading about Lightning Networks in <a href="https://medium.com/@yyforyongyu/till-its-lightning-fast-uncover-the-lightning-network-transactions-f3180e467857" rel="nofollow noreferrer">this</a> and similar articles, I realized that I don't understand how the protocol &amp; the system prevents the following scenario:</p>
<ol>
<li>There is an established channel between Alice &amp; Bob.</li>
<li>The transaction outputs of the latest 'agreed' off-chain transaction are 1BC on Alice's side and 1 BC on Bob's side.</li>
<li>Alice &amp; Bob initiate a new transaction.</li>
<li>Alice &amp; Bob exchange their parts of revocation keys.</li>
<li>Bob decides to cheat and pretends to &quot;disappear&quot;, not signing the new transaction and not responding, but still being online and monitoring on-chain transactions.</li>
<li>At some point in time, if Alice wants to free up her 1 bitcoin, she executes latest 'agreed' transaction, but her funds are locked for 2 weeks.</li>
<li>While pretending to be unresponsive, Bob is monitoring the chain and executes the revocation clause as soon as it happens, getting both bitcoins.</li>
</ol>
<p>Obviously, significant time may pass between #5 and #6, but if Bob can afford to wait, he can pull that trick.</p>
<p>It seems that in order to avoid that, new off-chain transactions need to be signed in a single distributed transaction with the exchange of revocation keys, but I don't see how it is feasible. I've read multiple mentions that the keys are exchanged prior to signing new transactions.</p>
<p>I've read a similar question <a href="https://bitcoin.stackexchange.com/questions/81406/order-of-exchanging-revocation-keys-during-lightning-transactions">here</a>, but I don't think it really addresses the situation I've described.</p>
<p>What am I missing?</p>

<lightning-network>
Lightning Network: tricking a node to cancel transaction with revocation & money loss
Max
# Lightning Network: tricking a node to cancel transaction with revocation & money loss

(Asked by: username_0 on 2021-06-28)

After reading about Lightning Networks in [this](https://medium.com/@yyforyongyu/till-its-lightning-fast-uncover-the-lightning-network-transactions-f3180e467857) and similar articles, I realized that I don't understand how the protocol & the system prevents the following scenario:

1. There is an established channel between Alice & Bob.
2. The transaction outputs of the latest 'agreed' off-chain transaction are 1BC on Alice's side and 1 BC on Bob's side.
3. Alice & Bob initiate a new transaction.
4. Alice & Bob exchange their parts of revocation keys.
5. Bob decides to cheat and pretends to "disappear", not signing the new transaction and not responding, but still being online and monitoring on-chain transactions.
6. At some point in time, if Alice wants to free up her 1 bitcoin, she executes latest 'agreed' transaction, but her funds are locked for 2 weeks.
7. While pretending to be unresponsive, Bob is monitoring the chain and executes the revocation clause as soon as it happens, getting both bitcoins.

Obviously, significant time may pass between #5 and #6, but if Bob can afford to wait, he can pull that trick.

It seems that in order to avoid that, new off-chain transactions need to be signed in a single distributed transaction with the exchange of revocation keys, but I don't see how it is feasible. I've read multiple mentions that the keys are exchanged prior to signing new transactions.

I've read a similar question [here](https://bitcoin.stackexchange.com/questions/81406/order-of-exchanging-revocation-keys-during-lightning-transactions), but I don't think it really addresses the situation I've described.

What am I missing?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2021-06-28. Score: 3 | Accepted answer

You touch a point that is a bit subtle but never the less no problem. I have explained it step by step in the channel operation chapter:
<https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc>

TL;DR:
While changing the balance of a channel Alice does only revoke her tx and state after she has received signatures for the new state from Bob. Thus if Bob becomes unresponsive during the process and alice dies not have new signatures yet it is save for her to force close with the latest state for which she does have the signatures (as that state has not been revoked yet)

While moving forward the balance for a short moment each side of the channel temporarily has two fully signed but unrevoked commitment transactions. This is secure though as publishing the "old" state is not wrong while the new one is not fully agreed upon.

> **Comments:**
> **username_2**: it seems the link has changed to https://github.com/lnbook/lnbook/blob/develop/09_channel_operation.asciidoc  

---

