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?
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.
@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 – 2019-04-29T02:29:55.473
@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 – 2019-04-29T02:30:49.893
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 – 2019-03-03T17:31:30.400
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 – 2019-03-03T18:00:54.723
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 – 2019-03-03T18:07:56.863
1The 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_reservefor this purpose, which ensures that there is a minimum amount kept by the fundee – Mark H – 2019-03-03T18:16:26.7101There is also a
push_amounton 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 lowmax_htcls_in_flightthat they can afford to pay if the other party is uncooperative. – Mark H – 2019-03-03T18:19:52.040I wanted to say: I would lose money, if I decided not to challenge his fraudulent transaction. – Grunzwanzling – 2019-03-03T18:21:28.913
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 – 2019-03-03T18:23:26.163
Yes, the commitment transaction is larger than the mutual close transaction. The idea of the
channel_reserveis 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 – 2019-03-03T18:26:38.113The 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 – 2019-03-03T18:43:48.793
1I'm not aware of what each client sets their
channel_reserveto by default. It should be user configurable. The purpose of thepush_msatin 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 – 2019-03-03T18:56:40.537