Topic: How Does the Lightning Network Address Potential Issues in Standard HTLC Protoco (Read 167 times)

My understanding is that what you describe -- the penalty process -- does only happen if someone broadcasts an old HTLC. It is not necessary to broadcast the complete HTLC set since the channel was opened, only the last commitment transaction which contains the (last) HTLC.

At any payment a new commitment transaction is exchanged between the channel parties, and in the case it's part of a "routing" process involucrating another user, it contains an HTLC. If not, i.e. if it's an "internal" payment between both parties of the channel only, then the contract it contains should normally only contain a timelock (no hashlock) to give the counterparty time to punish you if you misbehave. The HTLC is only necessary to communicate with the "outside world" (other Lightning participants).

As far as I understand this is not really the case. The commitment transactions always spend the same UTXO from the Funding Transaction. The "invalidation" instead occurs because the channel parties sign a so called "Breach Remedy Transaction", i.e. an additional output for the previous commitment transaction, which allows the a party to get the whole channel's funds in the case the other party tries to publish this commitment transaction.

If I understood your post wrong, please correct me

No transaction is broadcasted unless both parties have signed the commitment transaction. This question can also be rephrased as "How does Bob ensures Alice will pay him if he routes her payment to Charlie?", and the answer is that there's a property called "atomicity", in which a payment is either paid by all parties, or by none. Alice's condition for Bob to claim her payment is to find the pre-image in Charlie's hash. Alice can't go offline and let Bob pay for her, because if Bob knows Charlie's secret, he satisfies Alice's condition in the script she already has signed.

And I hear that in the case that not all of the HTLCs are broadcasted in the event of a conflict, there is another set of transactions that are created for each LN payment that will allow the counterparty to 'seize' all the funds in the channel by utilizing some value revealed in the HTLC when it is broadcasted that allows them to sign the take-all transaction.

It is quickly invalidated when another LN payment is made as a new, unbroadcasted UTXO is created from the previous (also unbroadcasted) UTXO such that if the old one is broadcasted then the new one can be broadcasted quickly to invalidate it. And obviously the new UTXO cannot be broadcasted first since the prevout is missing from the mempool's UTXO set.

Is this correct?

Just clarifying this a bit more:

When you create a Lightning channel, you still don't broadcast a HTLC transaction to the Bitcoin network. This means the HTLC will not be confirmed on-chain when the channel is created.

Instead, both parties create a multisig transaction, called the Funding Transaction, with the funds to be used in the channel, and broadcast it on-chain.

One of the keys to understand the LN workings is that before the Funding Transaction is broadcast, a set of commitment transactions is exchanged off-chain -- without broadcasting -- between the channel partners, which allow both partners to send their funds back to another address owned by them, and contains the outputs of the Funding Transaction as inputs. This ensures that both partners always have the option to close the channel if the other party doesn't cooperate anymore.

In contrast, the HTLCs are created when a payment is made and the "state" of the channel is changed (including "routings through the channel"). With each payment a new set of HTLCs is exchanged, invalidating the previous set. But they are only exchanged by the channel partners, like the commitment transactions.

HTLCs only need to be broadcast to the Bitcoin network in the case of a conflict.

I personally found it relatively easy to understand reading the original white paper, but the ebook linked by ABCbits may be much better for a deeper understanding.

Thanks a lot

I don't create any illustration about Bitcoin. But if you're looking to learn about LN, you may want to start by reading book Mastering the Lightning Network which is available for free and legal on https://github.com/lnbook/lnbook.

Thanks a lot for explanation. By the way is there any platform where I can see all your illustrations on bitcoin topics ? I have found out only X but it isn't the best platform to investigate anything.

On-chain fees refers to on-chain TX fee when you open or close LN channel. LN fees refers to fee when you send Bitcoin to someone else through routing.


In normal case (no cheating attempt or someone offline for long time), usually it's when you open and close channel.

   Clarification on Fees: Could you clarify the difference between Lightning Network fees and on-chain fees? Shouldn't they be similar since both involve transaction costs?

Timing of HTLC Transactions: At what point is the HTLC transaction broadcasted on the network? Is it created during the initial setup of the payment channel, or only when the contract is executed?

Are you referring to Lightning fees or to on-chain fees? Your question is not totally clear to me ...

If you refer to the creation of a new payment channel, the channel is created via a multisig transaction, so both parties will contribute their fees. The process is atomic, so if one party doesn't cooperate, the contract will not be created on chain and no fees will be wasted.

Or do you refer to the attacks which can make one person lose Lightning fees to an attacker, for example "fee sniping" (see explanations in this article)? These fees are anyway very low and there is ongoing investigation about still remaining feasible attacks. There are also some threads in this subforum about some common attacks, for example for the so-called Wormhole attack.

And here is a list of many important Lightning threads on Bitcointalk up to 2023. Unfortunately the OP doesn't seem to be updated anymore.

In the standard HTLC protocol, the first person creates an HTLC, and the second person verifies the details and creates their HTLC as well. However, this poses a problem where the second person can potentially harm the first by not continuing the process, which forces the first user to incur fees for creating the HTLC. How does the Lightning Network address this issue to prevent such exploitation?