<p>The cost is proportional to the number of committed HTLCs on the channel at the time of closure. Each HTLC has an output in the commitment transaction which pays into either a HTLC-success transaction script or a HTLC-timeout transaction script, depending on whether the HTLC was incoming our outgoing. The commitment also usually has an output to the spender (timelocked) and a regular P2WSH output to the other party of the channel.</p>

<p>Due to both parties needing to agree up-front about the transaction fees involved (in order to sign matching transactions), the protocol works on an "estimated weight", which assumes worst-case sizes for signatures etc.</p>

<p>The estimated weights are broken down in full in <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights" rel="nofollow noreferrer">BOLT#3</a>, but the key values are</p>

<pre><code>Commitment weight:   724 + 172 * num-untrimmed-htlc-outputs
HTLC-timeout weight: 663
HTLC-success weight: 703 
</code></pre>

<p>The transaction fee is then the agreed upon feerate in satoshi/kweight * expected_weight / 1000 (rounding down).</p>

<p>Clearly it is undesirable to have a large number of htlcs in flight in case of unilateral closure. There is a technical limit of 453 due to the 10k script limit in Bitcoin, but ideally you will want to use a much smaller number.</p>

<p>With other developments like Taproot, it should be possible to bring these costs down significantly for the most likely outcomes.</p>

CC BY-SA 4.0
2019-03-03T17:31:30.400Z
So the smart contracts are structured in a way, that the cheater has to pay all the transaction fees? What if the fees have singificantly risen since we both agreed on the contract?
Grunzwanzling
CC BY-SA 4.0
2019-03-03T18:00:54.723Z
The transaction fees are paid out of the channel funds, which are initially provided by the channel funder when the channel is created. On a unilateral close, the cost of the commitment transaction is above regardless of whether it was cheating or not, the only difference being that the claimant of a penalty transaction uses signature||revocation_key versus signature||payment_hash as the witness for their to_local output, and their witness for the htlc transactions is signature||1.
Mark H
CC BY-SA 4.0
2019-03-03T18:07:56.863Z
Do I understand it correctly: 100% of channel funds are on my side and there are a lot of htlcs associated with the channel. If my peer decides to cheat, he has almost nothing to lose, ecxept for a tiny amount of fees, but I have to pay a huge fee on a big transaction to prove him wrong, otherwise I lose all of the money that is in the channel?
Grunzwanzling
CC BY-SA 4.0
2019-03-03T18:16:26.710Z
The fee is paid regardless of whether you prove him wrong or not. You will never lose *all* of the money in the channel, but at worst, you may lose the to_remote amount or the amounts of any timed out htlcs of the revoked commitment the cheater broadcasts if you don't issue the penalty. The fee is paid by the channel funder. The fundee has no obligation to cooperate with you except the funds on their side of the channel which they might be able to gain if they do cooperate. There is a `channel_reserve` for this purpose, which ensures that there is a minimum amount kept by the fundee
Mark H
CC BY-SA 4.0
2019-03-03T18:19:52.040Z
There is also a `push_amount` on channel open, which establishes that the fundee at least has some funds if they cooperate. There is an incentive for them to accept channels because they stand to gain from it. Also, if they don't keep enough funds on their side of the channel, their output will be truncated and they will gain nothing, unless they successfully cheat. Since the fundee cheating is always possible, the funder needs to account for the possibility and set a sufficiently low `max_htcls_in_flight` that they can afford to pay if the other party is uncooperative.
Mark H
CC BY-SA 4.0
2019-03-03T18:21:28.913Z
I wanted to say: I would lose money, if I decided not to challenge his fraudulent transaction.
Grunzwanzling
CC BY-SA 4.0
2019-03-03T18:23:26.163Z
Transactions are larger if there is a dispute, right? So if the cheater has no money on his side, he can attempt to cheat, risk nothing and harm me, as I have to issue a larger transaction that I would have if he cooperated.
Grunzwanzling
CC BY-SA 4.0
2019-03-03T18:26:38.113Z
Yes, the commitment transaction is larger than the mutual close transaction. The idea of the `channel_reserve` is to make it so that a peer never has no money on their side of the channel, and therefore, attempting to cheat would be throwing away the money they do have. On the other hand, they have an incentive to keep the channel open because it provides them with inbound capacity for receiving payments.
Mark H
CC BY-SA 4.0
2019-03-03T18:43:48.793Z
The channel_reserve system is a good idea, but it only works once the other side has money on their side. Do you know if this value is set by default?
Grunzwanzling
CC BY-SA 4.0
2019-03-03T18:56:40.537Z
I'm not aware of what each client sets their `channel_reserve` to by default. It should be user configurable. The purpose of the `push_msat` in the channel opening is to provide the other side with some money. The won't attempt to cheat unless that have had at least some money at some point in the past (ie, there is a revoked commitment which would award them some of the channel funds). If they have never had funds, they stand to gain nothing by closing the channel anyway.
Mark H
CC BY-SA 4.0
2019-04-29T02:29:55.473Z
@Grunzwanzling: In the future, please be sure to either include follow-up questions into the question, or to ask follow-up questions as a new topic so that they're also added to our question and answer body.
Murch
CC BY-SA 4.0
2019-04-29T02:30:49.893Z
@MarkH: When you answer follow-up questions, it would be preferable to collect the gist of the answers in your answer post for the same reason. :)
Murch
CC BY-SA 4.0
2019-03-03T17:22:47.960Z
2019-03-03T17:28:43.063Z
2019-03-03T17:28:43.063Z
Mark H
<p>If someone breaches a Lightning channel (aka tries to spend more than he is allowed to), the other party has to intervene and prove that the coins actually belong to them. This process happens on-chain. How large would such a transaction be? Is it proportional to the number of transactions that happened while the channel was open?</p>

<lightning-network><micropaymentchannels><ln-penalty-transaction>
What is the cost of resolving a Lightning channel breach?
Grunzwanzling
# What is the cost of resolving a Lightning channel breach?

(Asked by: username_0 on 2019-03-03)

If someone breaches a Lightning channel (aka tries to spend more than he is allowed to), the other party has to intervene and prove that the coins actually belong to them. This process happens on-chain. How large would such a transaction be? Is it proportional to the number of transactions that happened while the channel was open?

**Tags:** lightning-network, micropaymentchannels, ln-penalty-transaction


---

## 1 answers

### Answer by username_1 on 2019-03-03. Score: 2 | Accepted answer

The cost is proportional to the number of committed HTLCs on the channel at the time of closure. Each HTLC has an output in the commitment transaction which pays into either a HTLC-success transaction script or a HTLC-timeout transaction script, depending on whether the HTLC was incoming our outgoing. The commitment also usually has an output to the spender (timelocked) and a regular P2WSH output to the other party of the channel.

Due to both parties needing to agree up-front about the transaction fees involved (in order to sign matching transactions), the protocol works on an "estimated weight", which assumes worst-case sizes for signatures etc.

The estimated weights are broken down in full in [BOLT#3](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#appendix-a-expected-weights), but the key values are

```
Commitment weight:   724 + 172 * num-untrimmed-htlc-outputs
HTLC-timeout weight: 663
HTLC-success weight: 703 

```

The transaction fee is then the agreed upon feerate in satoshi/kweight \* expected\_weight / 1000 (rounding down).

Clearly it is undesirable to have a large number of htlcs in flight in case of unilateral closure. There is a technical limit of 453 due to the 10k script limit in Bitcoin, but ideally you will want to use a much smaller number.

With other developments like Taproot, it should be possible to bring these costs down significantly for the most likely outcomes.

> **Comments:**
> **username_0**: So the smart contracts are structured in a way, that the cheater has to pay all the transaction fees? What if the fees have singificantly risen since we both agreed on the contract?  
> **username_1**: The transaction fees are paid out of the channel funds, which are initially provided by the channel funder when the channel is created. On a unilateral close, the cost of the commitment transaction is above regardless of whether it was cheating or not, the only difference being that the claimant of a penalty transaction uses signature||revocation_key versus signature||payment_hash as the witness for their to_local output, and their witness for the htlc transactions is signature||1.  
> **username_0**: Do I understand it correctly: 100% of channel funds are on my side and there are a lot of htlcs associated with the channel. If my peer decides to cheat, he has almost nothing to lose, ecxept for a tiny amount of fees, but I have to pay a huge fee on a big transaction to prove him wrong, otherwise I lose all of the money that is in the channel?  
> **username_1**: The fee is paid regardless of whether you prove him wrong or not. You will never lose *all* of the money in the channel, but at worst, you may lose the to_remote amount or the amounts of any timed out htlcs of the revoked commitment the cheater broadcasts if you don't issue the penalty. The fee is paid by the channel funder. The fundee has no obligation to cooperate with you except the funds on their side of the channel which they might be able to gain if they do cooperate. There is a `channel_reserve` for this purpose, which ensures that there is a minimum amount kept by the fundee  
> **username_1**: There is also a `push_amount` on channel open, which establishes that the fundee at least has some funds if they cooperate. There is an incentive for them to accept channels because they stand to gain from it. Also, if they don't keep enough funds on their side of the channel, their output will be truncated and they will gain nothing, unless they successfully cheat. Since the fundee cheating is always possible, the funder needs to account for the possibility and set a sufficiently low `max_htcls_in_flight` that they can afford to pay if the other party is uncooperative.  
> **username_0**: I wanted to say: I would lose money, if I decided not to challenge his fraudulent transaction.  
> **username_0**: Transactions are larger if there is a dispute, right? So if the cheater has no money on his side, he can attempt to cheat, risk nothing and harm me, as I have to issue a larger transaction that I would have if he cooperated.  
> **username_1**: Yes, the commitment transaction is larger than the mutual close transaction. The idea of the `channel_reserve` is to make it so that a peer never has no money on their side of the channel, and therefore, attempting to cheat would be throwing away the money they do have. On the other hand, they have an incentive to keep the channel open because it provides them with inbound capacity for receiving payments.  
> **username_0**: The channel_reserve system is a good idea, but it only works once the other side has money on their side. Do you know if this value is set by default?  
> **username_1**: I'm not aware of what each client sets their `channel_reserve` to by default. It should be user configurable. The purpose of the `push_msat` in the channel opening is to provide the other side with some money. The won't attempt to cheat unless that have had at least some money at some point in the past (ie, there is a revoked commitment which would award them some of the channel funds). If they have never had funds, they stand to gain nothing by closing the channel anyway.  
> **username_2**: @username_0: In the future, please be sure to either include follow-up questions into the question, or to ask follow-up questions as a new topic so that they're also added to our question and answer body.  
> **username_2**: @username_1: When you answer follow-up questions, it would be preferable to collect the gist of the answers in your answer post for the same reason. :)  

---

