<blockquote>
  <p>A must pay fee like in onchain transaction. So there is no reason to use lightning when A need to pay some coins to different recepients?</p>
</blockquote>

<p>Yes, when opening or closing a channel, on-chain transactions occur and thus fees must be paid. However, the interesting thing about the lightning network (LN) is that those two on-chain transactions can now account for a whole bunch of transactions to <em>anyone else connected to the LN</em>. Even further, the closing of a channel can also be the opening of a new channel, so this reduces the onchain payments to ~just one per channel. So rather than having one on-chain fee per transaction, you can pay one on-chain fee for potentially a huge number of transactions.</p>

<blockquote>
  <p>I hear lightning can do decentralized exchange. Can someone give an example how it will work with less fees (or zero fee if it possible)?</p>
</blockquote>

<p>An exchange service could be built on top of the LN. Such a service could allow users to atomically swap coins that exist in a payment channel, without a custodial service involved. The exchange service simply plays 'matchmaker' for buyers and sellers. A quick google search shows me this service, called <a href="https://sparkswap.com/docs/getting-started" rel="nofollow noreferrer">SparkSwap</a>, as an example <em>(disclaimer: I have never used SparkSwap, and have no affiliation with them, I literally just found them in a google search and their service seems like a relevant example)</em></p>

<p>Note that a LN exchange is best suited for trading between LN network and on-chain BTC, or between different cryptocurrencies. Not BTC &lt;-> Fiat $$. </p>

<blockquote>
  <p>Another example: if A trade BTC with B,C,D,E.... And A got +0.01BTC for each trade, then B need to pay 0.01 BTC, C pay 0.01BTC..... There is a lot onchain inputs, so a lot of fees (after channel close)</p>
</blockquote>

<p>I'm not sure exactly what you mean here, but in general: receiving or sending payments on the LN will not lead to more fees when closing your LN channel. You can open a channel and then send 1 transaction, or send/receive 1000 transactions (within the channel capacity), and the channel closing fee will be the same.</p>

CC BY-SA 4.0
2018-10-17T21:43:52.347Z
2018-10-17T21:43:52.347Z
chytrik
<p>I really have no idea how to aks it right. Let me give an example:
We have a some peoples A,B,C,D.... And A makes transaction to B, then A need to pay to C, then send some coins to D, etc... After closing channel A must pay fee like in onchain transaction. So there is no reason to use lightning when A need to pay some coins to different recepients? 
I hear lightning can do decentralized exchange. Can someone give an example how it will work with less fees (or zero fee if it possible)? </p>

<p>Another example: if A trade BTC with B,C,D,E.... And A got +0.01BTC for each trade, then B need to pay 0.01 BTC, C pay 0.01BTC..... There is a lot onchain inputs, so a lot of fees (after channel close)</p>

<p>Sorry for my English</p>

<bitcoin-core-development><lightning-network>
Lightning Network: what about tx fragmentation?
Andrew
# Lightning Network: what about tx fragmentation?

(Asked by: username_0 on 2018-10-17)

I really have no idea how to aks it right. Let me give an example:
We have a some peoples A,B,C,D.... And A makes transaction to B, then A need to pay to C, then send some coins to D, etc... After closing channel A must pay fee like in onchain transaction. So there is no reason to use lightning when A need to pay some coins to different recepients?
I hear lightning can do decentralized exchange. Can someone give an example how it will work with less fees (or zero fee if it possible)?

Another example: if A trade BTC with B,C,D,E.... And A got +0.01BTC for each trade, then B need to pay 0.01 BTC, C pay 0.01BTC..... There is a lot onchain inputs, so a lot of fees (after channel close)

Sorry for my English

**Tags:** bitcoin-core-development, lightning-network


---

## 1 answers

### Answer by username_1 on 2018-10-17. Score: 2

> A must pay fee like in onchain transaction. So there is no reason to use lightning when A need to pay some coins to different recepients?

Yes, when opening or closing a channel, on-chain transactions occur and thus fees must be paid. However, the interesting thing about the lightning network (LN) is that those two on-chain transactions can now account for a whole bunch of transactions to *anyone else connected to the LN*. Even further, the closing of a channel can also be the opening of a new channel, so this reduces the onchain payments to ~just one per channel. So rather than having one on-chain fee per transaction, you can pay one on-chain fee for potentially a huge number of transactions.

> I hear lightning can do decentralized exchange. Can someone give an example how it will work with less fees (or zero fee if it possible)?

An exchange service could be built on top of the LN. Such a service could allow users to atomically swap coins that exist in a payment channel, without a custodial service involved. The exchange service simply plays 'matchmaker' for buyers and sellers. A quick google search shows me this service, called [SparkSwap](https://sparkswap.com/docs/getting-started), as an example *(disclaimer: I have never used SparkSwap, and have no affiliation with them, I literally just found them in a google search and their service seems like a relevant example)*

Note that a LN exchange is best suited for trading between LN network and on-chain BTC, or between different cryptocurrencies. Not BTC <-> Fiat $$.

> Another example: if A trade BTC with B,C,D,E.... And A got +0.01BTC for each trade, then B need to pay 0.01 BTC, C pay 0.01BTC..... There is a lot onchain inputs, so a lot of fees (after channel close)

I'm not sure exactly what you mean here, but in general: receiving or sending payments on the LN will not lead to more fees when closing your LN channel. You can open a channel and then send 1 transaction, or send/receive 1000 transactions (within the channel capacity), and the channel closing fee will be the same.


---

