3

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?

Grunzwanzling
  • 163
  • 6

1 Answers1

2

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, 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.

Mark H
  • 3,304
  • 2
  • 7
  • 14
  • 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 Mar 03 '19 at 17:31
  • 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 Mar 03 '19 at 18:00
  • 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 Mar 03 '19 at 18:07
  • 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 – Mark H Mar 03 '19 at 18:16
  • 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. – Mark H Mar 03 '19 at 18:19
  • I wanted to say: I would lose money, if I decided not to challenge his fraudulent transaction. – Grunzwanzling Mar 03 '19 at 18:21
  • 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 Mar 03 '19 at 18:23
  • 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 Mar 03 '19 at 18:26
  • 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 Mar 03 '19 at 18:43
  • 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. – Mark H Mar 03 '19 at 18:56
  • @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 Apr 29 '19 at 02:29
  • @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 Apr 29 '19 at 02:30