<p>My assumption was wrong: in a RSMC (Relative Sequence Maturity Contract), a Revocable Transaction refers to the transaction whose output can be spent after a specific amount of time (eg: 1000 blocks) by the counterparty, not the original party.</p>

<p>The counterparty won’t get all the funds in that channel, but whatever was their balance before. After 1,000 blocks, if the original party doesn’t notice the malicious activity, the counterparty is able to spend (presumably) more than they should (as the counterparty published an old Commitment Transaction, it means that they try to reverse the payment for whatever service or product the parties).</p>

<p>This is the reason why users may want to monitor the blockchain for old Commitment Transactions, as a counterparty caught broadcasting an old one will lose all their money when a BRT (Breach Remedy Transaction) is broadcast. The BRT’s private key might be delegated to a third party “watch tower”, since they can't do any harm.</p>

CC BY-SA 4.0
2018-07-03T16:25:00.500Z
2019-09-24T13:43:31.793Z
2019-09-24T13:43:31.793Z
Paul Razvan Berg
<p>From the Lightning Network's <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">whitepaper</a>, page 19:</p>

<blockquote>
  <p>If they do not broadcast their most recent version, they will be 
  penalized by taking all the funds in the channel and giving it to the
  counterparty.</p>
  
  <p>...</p>
  
  <p>If they do broadcast their most recent Commitment Transaction, there
  should be no revocation transaction superseding the revocable
  transaction, so they will be able to receive their funds after some
  set amount of time (1000 confirmations).</p>
</blockquote>

<p>By revocation transaction, I assume the author implies that one party can prove on the main chain that the Commitment Transaction broadcast by the counterparty was not the most recent one. </p>

<p>Given that's true, will the party receive all the funds in that channel? Conversely, what happens if the counterparty goes offline for a long time (more than 1,000 blocks as per the example in there) and there's no revocation transaction, despite the fact the broadcaster lied about the Commitment Transaction?</p>

<transactions><lightning-network><sequence>
Lightning Network's RSMC: what happens if there's no revocation transaction?
Paul Razvan Berg
# Lightning Network's RSMC: what happens if there's no revocation transaction?

(Asked by: username_0 on 2018-06-25)

From the Lightning Network's [whitepaper](https://lightning.network/lightning-network-paper.pdf), page 19:

> If they do not broadcast their most recent version, they will be
> penalized by taking all the funds in the channel and giving it to the
> counterparty.
>
> ...
>
> If they do broadcast their most recent Commitment Transaction, there
> should be no revocation transaction superseding the revocable
> transaction, so they will be able to receive their funds after some
> set amount of time (1000 confirmations).

By revocation transaction, I assume the author implies that one party can prove on the main chain that the Commitment Transaction broadcast by the counterparty was not the most recent one.

Given that's true, will the party receive all the funds in that channel? Conversely, what happens if the counterparty goes offline for a long time (more than 1,000 blocks as per the example in there) and there's no revocation transaction, despite the fact the broadcaster lied about the Commitment Transaction?

**Tags:** transactions, lightning-network, sequence


---

## 1 answers

### Answer by username_0 on 2018-07-03. Score: 0 | Accepted answer

My assumption was wrong: in a RSMC (Relative Sequence Maturity Contract), a Revocable Transaction refers to the transaction whose output can be spent after a specific amount of time (eg: 1000 blocks) by the counterparty, not the original party.

The counterparty won’t get all the funds in that channel, but whatever was their balance before. After 1,000 blocks, if the original party doesn’t notice the malicious activity, the counterparty is able to spend (presumably) more than they should (as the counterparty published an old Commitment Transaction, it means that they try to reverse the payment for whatever service or product the parties).

This is the reason why users may want to monitor the blockchain for old Commitment Transactions, as a counterparty caught broadcasting an old one will lose all their money when a BRT (Breach Remedy Transaction) is broadcast. The BRT’s private key might be delegated to a third party “watch tower”, since they can't do any harm.


---

