<blockquote>
  <p>It's possible that a node in the middle either either intentionally or unintentionally does not pay the next node down the line. The recourse is for the node that did not get paid to broadcast the transaction to the blockchain (and close the channel?).</p>
</blockquote>

<p>No, that's not accurate. If a node in the middle of a multi-hop payment rejects a payment request, the sender simply makes another attempt along a different route omitting this node. On the other hand, if the payment contract is already established, the node is already cryptographically committed to pay. It's impossible at that point for them not to pay. A forwarding node can merely fail to collect the reimbursement for what they've already forwarded.<br>
If a node continuously fails to forward payments, their channel partner is still free to close the channel of course, but this is for different reasons.</p>

<blockquote>
  <p>Who pays the fees for for that transaction? What happens if the fee is significantly larger than the amount of money the node would gain by broadcasting the transactions?</p>
</blockquote>

<p>The fee for Lightning payments is paid by the sender. They must include sufficient funds to pay fees to all nodes along the route. If the fee for closing a channel is higher than the channel's capacity, it probably makes more sense to leave it open until fees get lower.</p>

CC BY-SA 3.0
2018-04-25T19:22:47.113Z
"The node is already cryptographically committed to pay. It's impossible at that point for them not to pay."

Sure, but if the amount of the transaction is higher than the current BTC fees it would cost the node that did not get paid more than the amount sent to force the transaction than they would receive by doing so.
Anthony
CC BY-SA 3.0
2018-04-25T23:35:20.900Z
@Anthony: The recipient of the payment can use the preimage to claim the committed funds from the HTLC. Then initiate the unilateral close. I don't understand your interjection. https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#htlc-output-handling-local-commitment-remote-offers
Murch
CC BY-SA 4.0
2018-10-30T04:43:46.547Z
you say, "If the fee for closing a channel is higher than the channel's capacity, it probably makes more sense to leave it open until fees get lower.", but what if that never happens? miner fees are expected to go up over time as coinbase tx values go down. what happens if the channel can never settle?
mulllhausen
CC BY-SA 3.0
2018-04-20T22:47:48.687Z
2018-04-20T22:47:48.687Z
Murch
<p>A network fee in Bitcoin is simply the leftover between sum of the inputs and the sum of the outputs.  The lightning network can be viewed as a protocol for updating the value split between the outputs.  Therefore, any closing transaction that is broadcast will already have the fee set in place.</p>

<p>If Alice has a channel open with Bob, and for whatever reason wants to broadcast her transaction to close the channel, she is intentionally agreeing to only receive the funds that transaction <em>explicitly</em> allocates to her.  The fee has already been built in, and like the rest of the transaction, cannot be changed.</p>

<p>There is a <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees" rel="nofollow noreferrer">section of fees in the protocol specification</a> if you would like to read more.</p>

CC BY-SA 3.0
2017-12-27T19:02:06.980Z
It sounds like you are talking about fees paid to LN hubs? I am specifically talking about fees paid to bitcoin miners for including the transaction in the BTC blockchain.
Anthony
CC BY-SA 3.0
2017-12-27T19:07:05.667Z
@Anthony, no, I'm talking about transactions on the blockchain.  A transaction on the lightning network is just an update to the potential closing transactions held by the channel owners.  These closing transactions must include a fee, otherwise there is no threat that they may be broadcast to the Bitcoin network.  I'm no expert, but I'd assume those fees would need to be recalculated when the closing transactions are updated, but once they are, they are set in stone.
Jestin
CC BY-SA 3.0
2017-12-27T18:15:53.730Z
2017-12-27T18:15:53.730Z
Jestin
<p>I've been educating myself on how the Lightning Network protocol works, and I have some questions.</p>

<p>Let's say that a user sends a small payment to someone and it makes multiple hops through the network before reaching the recipient. The payment then propagates backward through the chain until it reaches the payer, and everything settles out.</p>

<p>It's possible that a node in the middle either either intentionally or unintentionally does not pay the next node down the line. The recourse is for the node that did not get paid to broadcast the transaction to the blockchain (and close the channel?).</p>

<p>Who pays the fees for for that transaction? What happens if the fee is significantly larger than the amount of money the node would gain by broadcasting the transactions?</p>

<p>This seems like it could potentially be a large attack vector. Is there something I am misunderstanding?</p>

<transaction-fees><lightning-network><ln-closing-channels>
When running a Lightning Network hub, who pays the fees when a transaction has to be broadcast to the blockchain?
Anthony
# When running a Lightning Network hub, who pays the fees when a transaction has to be broadcast to the blockchain?

(Asked by: username_0 on 2017-12-27)

I've been educating myself on how the Lightning Network protocol works, and I have some questions.

Let's say that a user sends a small payment to someone and it makes multiple hops through the network before reaching the recipient. The payment then propagates backward through the chain until it reaches the payer, and everything settles out.

It's possible that a node in the middle either either intentionally or unintentionally does not pay the next node down the line. The recourse is for the node that did not get paid to broadcast the transaction to the blockchain (and close the channel?).

Who pays the fees for for that transaction? What happens if the fee is significantly larger than the amount of money the node would gain by broadcasting the transactions?

This seems like it could potentially be a large attack vector. Is there something I am misunderstanding?

**Tags:** transaction-fees, lightning-network, ln-closing-channels


---

## 2 answers

### Answer by username_1 on 2018-04-20. Score: 2

> It's possible that a node in the middle either either intentionally or unintentionally does not pay the next node down the line. The recourse is for the node that did not get paid to broadcast the transaction to the blockchain (and close the channel?).

No, that's not accurate. If a node in the middle of a multi-hop payment rejects a payment request, the sender simply makes another attempt along a different route omitting this node. On the other hand, if the payment contract is already established, the node is already cryptographically committed to pay. It's impossible at that point for them not to pay. A forwarding node can merely fail to collect the reimbursement for what they've already forwarded.  
If a node continuously fails to forward payments, their channel partner is still free to close the channel of course, but this is for different reasons.

> Who pays the fees for for that transaction? What happens if the fee is significantly larger than the amount of money the node would gain by broadcasting the transactions?

The fee for Lightning payments is paid by the sender. They must include sufficient funds to pay fees to all nodes along the route. If the fee for closing a channel is higher than the channel's capacity, it probably makes more sense to leave it open until fees get lower.

> **Comments:**
> **username_0**: "The node is already cryptographically committed to pay. It's impossible at that point for them not to pay."  Sure, but if the amount of the transaction is higher than the current BTC fees it would cost the node that did not get paid more than the amount sent to force the transaction than they would receive by doing so.  
> **username_1**: @username_0: The recipient of the payment can use the preimage to claim the committed funds from the HTLC. Then initiate the unilateral close. I don't understand your interjection. https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md#htlc-output-handling-local-commitment-remote-offers  
> **username_2**: you say, "If the fee for closing a channel is higher than the channel's capacity, it probably makes more sense to leave it open until fees get lower.", but what if that never happens? miner fees are expected to go up over time as coinbase tx values go down. what happens if the channel can never settle?  

---

### Answer by username_3 on 2017-12-27. Score: 1

A network fee in Bitcoin is simply the leftover between sum of the inputs and the sum of the outputs. The lightning network can be viewed as a protocol for updating the value split between the outputs. Therefore, any closing transaction that is broadcast will already have the fee set in place.

If Alice has a channel open with Bob, and for whatever reason wants to broadcast her transaction to close the channel, she is intentionally agreeing to only receive the funds that transaction *explicitly* allocates to her. The fee has already been built in, and like the rest of the transaction, cannot be changed.

There is a [section of fees in the protocol specification](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#fees) if you would like to read more.

> **Comments:**
> **username_0**: It sounds like you are talking about fees paid to LN hubs? I am specifically talking about fees paid to bitcoin miners for including the transaction in the BTC blockchain.  
> **username_3**: @username_0, no, I'm talking about transactions on the blockchain.  A transaction on the lightning network is just an update to the potential closing transactions held by the channel owners.  These closing transactions must include a fee, otherwise there is no threat that they may be broadcast to the Bitcoin network.  I'm no expert, but I'd assume those fees would need to be recalculated when the closing transactions are updated, but once they are, they are set in stone.  

---

