<p>You are correct that small payments would be a liability in the case of uncooperative nodes in a channel.  I also believe you are correct that when the values get small enough, the trust-less nature of a channel breaks down.  Although a 1 satoshi transaction is possible, at some point the cost of the transaction that closes the channel is higher than the value transmitted over the channel.  You couldn't open and close a channel just to send a single satoshi, even if both nodes were cooperative.</p>

<p>What the LN really does is create a network similar to the existing network of <a href="http://www.investopedia.com/terms/c/correspondent-bank.asp" rel="noreferrer">correspondent banks</a> in the legacy financial infrastructure.  With every correspondent banking relationship (payment channel, in the LN), there are risks and liabilities involved.  These risks are mitigated by charging fees to use the channels, which is exactly what the Lightning Network will do.</p>

<p>I don't see this as a show stopper for the implementation of the Lightning Network, but it will be a factor in what drives the fees for using a channel.  This dynamic may also play a role in how the nodes split the money that is originally locked to create the channel.  Less established nodes may have to contribute a higher percentage than those nodes that have been deemed trustworthy.  I'm speculating here, but this is one potential way to mitigate risks.</p>

<p>Just like with Bitcoin, the system should work so long as there are more honest nodes than dishonest nodes.  In this case, however, dishonest nodes must attain enough <em>money</em> to disrupt the network as opposed to <em>hashing power</em>.</p>

CC BY-SA 3.0
2016-07-26T19:10:30.580Z
It's not really just a problem where you might have to pay more in fees, you literally can't broadcast your guarantee of payment transaction in the case that something goes wrong, because it won't propagate and you won't be able to recover your funds out of the channel. You wouldn't even be able to get your original funds in the channel back, because it's part of the same transaction. Thus, you have to avoid extremely small payments altogether. So they're not really micro-transactions, they're milli-transactions (amounts can go down to 0.001 but not down to 0.000001).
morsecoder
CC BY-SA 3.0
2016-07-26T19:15:17.530Z
That's how I see it too.  It allows for smaller transactions than on the Bitcoin mainchain, but not down to Satoshis.  Only if you somehow introduce trust into a node/path could you go down that low.  By the way, this was a great question!  I wish I could give it another upvote!
Jestin
CC BY-SA 3.0
2016-07-26T19:32:37.263Z
Haha, thanks! The interesting thing is that if you were just doing a bi-directional payment channel directly without HTLC outputs, you could send down to 1 satoshi trustless-ly, because in that case it's just a matter of updating balances (Alice: 0.5, BoB: 0.5 -> Alice 0.49999999, Bob: 0.50000001). But when the amounts have to be their own HTLC output, it breaks down.
morsecoder
CC BY-SA 3.0
2016-07-26T04:49:52.623Z
2016-07-26T04:49:52.623Z
Jestin
<p>Reading through the <a href="https://lightning.network/lightning-network-paper.pdf" rel="noreferrer">Lightning Network Paper</a>, it seems that amounts sent through an intermediate node use the Hash Timelocked Output construction. The thing I'm concerned about with HTLCs is that they actually require their own output. Simultaneously, the transactions they are in must also be broadcast-able if the other party goes offline or become uncooperative.</p>

<p>So, let's look at a scenario where Alice wants to send 1 satoshi to Carol, through Bob, with whom Alice and Carol both already have payment channels open. Alice sends bob a new commitment transaction with 1 satoshi deducted from her balance and a new HTLC output for 1 satoshi. Bob sends the same type of channel update transactions to Carol. The problem is, though, that HLTC output would be considered dust if it ever did actually need to be broadcasted! So this cannot be considered a valid guarantee of payment, since the transaction would not even propagate on the network.</p>

<p>Is that a problem? Part of the excitement over the LN is that you can send really small amounts, but it seems to me that you can't actually send smaller amounts than you could in a real bitcoin transaction, because you have to be able to broadcast the transactions if the other party doesn't cooperate or goes offline.</p>

<dust><lightning-network>
Can you send amounts that would typically be considered 'dust' through the Lightning Network?
morsecoder
# Can you send amounts that would typically be considered 'dust' through the Lightning Network?

(Asked by: username_0 on 2016-07-26)

Reading through the [Lightning Network Paper](https://lightning.network/lightning-network-paper.pdf), it seems that amounts sent through an intermediate node use the Hash Timelocked Output construction. The thing I'm concerned about with HTLCs is that they actually require their own output. Simultaneously, the transactions they are in must also be broadcast-able if the other party goes offline or become uncooperative.

So, let's look at a scenario where Alice wants to send 1 satoshi to Carol, through Bob, with whom Alice and Carol both already have payment channels open. Alice sends bob a new commitment transaction with 1 satoshi deducted from her balance and a new HTLC output for 1 satoshi. Bob sends the same type of channel update transactions to Carol. The problem is, though, that HLTC output would be considered dust if it ever did actually need to be broadcasted! So this cannot be considered a valid guarantee of payment, since the transaction would not even propagate on the network.

Is that a problem? Part of the excitement over the LN is that you can send really small amounts, but it seems to me that you can't actually send smaller amounts than you could in a real bitcoin transaction, because you have to be able to broadcast the transactions if the other party doesn't cooperate or goes offline.

**Tags:** dust, lightning-network


---

## 1 answers

### Answer by username_1 on 2016-07-26. Score: 5

You are correct that small payments would be a liability in the case of uncooperative nodes in a channel. I also believe you are correct that when the values get small enough, the trust-less nature of a channel breaks down. Although a 1 satoshi transaction is possible, at some point the cost of the transaction that closes the channel is higher than the value transmitted over the channel. You couldn't open and close a channel just to send a single satoshi, even if both nodes were cooperative.

What the LN really does is create a network similar to the existing network of [correspondent banks](http://www.investopedia.com/terms/c/correspondent-bank.asp) in the legacy financial infrastructure. With every correspondent banking relationship (payment channel, in the LN), there are risks and liabilities involved. These risks are mitigated by charging fees to use the channels, which is exactly what the Lightning Network will do.

I don't see this as a show stopper for the implementation of the Lightning Network, but it will be a factor in what drives the fees for using a channel. This dynamic may also play a role in how the nodes split the money that is originally locked to create the channel. Less established nodes may have to contribute a higher percentage than those nodes that have been deemed trustworthy. I'm speculating here, but this is one potential way to mitigate risks.

Just like with Bitcoin, the system should work so long as there are more honest nodes than dishonest nodes. In this case, however, dishonest nodes must attain enough *money* to disrupt the network as opposed to *hashing power*.

> **Comments:**
> **username_0**: It's not really just a problem where you might have to pay more in fees, you literally can't broadcast your guarantee of payment transaction in the case that something goes wrong, because it won't propagate and you won't be able to recover your funds out of the channel. You wouldn't even be able to get your original funds in the channel back, because it's part of the same transaction. Thus, you have to avoid extremely small payments altogether. So they're not really micro-transactions, they're milli-transactions (amounts can go down to 0.001 but not down to 0.000001).  
> **username_1**: That's how I see it too.  It allows for smaller transactions than on the Bitcoin mainchain, but not down to Satoshis.  Only if you somehow introduce trust into a node/path could you go down that low.  By the way, this was a great question!  I wish I could give it another upvote!  
> **username_0**: Haha, thanks! The interesting thing is that if you were just doing a bi-directional payment channel directly without HTLC outputs, you could send down to 1 satoshi trustless-ly, because in that case it's just a matter of updating balances (Alice: 0.5, BoB: 0.5 -> Alice 0.49999999, Bob: 0.50000001). But when the amounts have to be their own HTLC output, it breaks down.  

---

