<p>I think these are two questions. </p>

<p>1.) Why charge with lightning in real time instead of once? I guess the main reason would be the convenience for the consumer. It is much nicer if I don't continue to watch the video that I don't have to pay the full price. </p>

<p>2.) Why using lightning instead of an on chain transaction? I guess the main reason is that on chain transactions are slow and with the higher adoption of bitcoin also more expensive. This means that it will just be cheeper and faster to accept payments via the lightning network which goes in the direction of the guess you made. There is another advantage which is that your lightning channel can be reused over and over again. </p>

CC BY-SA 4.0
2019-01-04T22:08:29.337Z
Good points although perhaps I wasn't clear enough in my question; that the comparison is between a continually updated LN channel and a one-off on-chain TX for the duration watched, not the whole video. Also on your point 2, an LN channel will always require N confirmations on the main chain just to open the channel. Having said that i suppose as ypu say, this is offset by one long running channel
theruss
CC BY-SA 4.0
2019-01-04T22:10:19.443Z
This rather begs the question: what is the utility of a long running channel in the context of my question? I order to fulfil an LN invoice, the channel would need to be closed anway would it not?
theruss
CC BY-SA 4.0
2019-01-04T22:38:28.670Z
no the point is that the channel does not have to be closed. it can stay open. that is the point of the Lightning Network. We open channels and use them hopefully forever (:
Rene Pickhardt
CC BY-SA 4.0
2019-01-04T23:45:41.230Z
Brilliant. A channel not needing to be closed is a key piece I was missing. Missed because I was blinkered by my own 2-entity scenario.
theruss
CC BY-SA 4.0
2019-01-04T21:32:56.130Z
2019-01-04T21:32:56.130Z
Rene Pickhardt
<p>I'm trying to understand software orientated payment use-cases for Lightning payments.</p>

<p>Given a web app that accepted BTC payments charged in Satoshi for a service - watching videos for example; why might it be advantageous to use LN to continually generate new invoices (per second of viewing time), instead of simply timing the overall viewing time and invoicing once at the end via a standard on-chain TX?</p>

<p>The only advantage I see atm is a hedge against on-chain fee prices, by opening a "long running" channel.</p>

CC BY-SA 4.0
2019-01-04T21:11:39.380Z
That is the main advantage, and it really depends on the application whether batching invoices fits the user experience.
JBaczuk
<lightning-network><payment>
Why would apps use Lightning over an on-chain TX?
theruss
# Why would apps use Lightning over an on-chain TX?

(Asked by: username_0 on 2019-01-04)

I'm trying to understand software orientated payment use-cases for Lightning payments.

Given a web app that accepted BTC payments charged in Satoshi for a service - watching videos for example; why might it be advantageous to use LN to continually generate new invoices (per second of viewing time), instead of simply timing the overall viewing time and invoicing once at the end via a standard on-chain TX?

The only advantage I see atm is a hedge against on-chain fee prices, by opening a "long running" channel.

**Tags:** lightning-network, payment

> **Comments:**
> **username_1**: That is the main advantage, and it really depends on the application whether batching invoices fits the user experience.  

---

## 1 answers

### Answer by username_2 on 2019-01-04. Score: 3 | Accepted answer

I think these are two questions.

1.) Why charge with lightning in real time instead of once? I guess the main reason would be the convenience for the consumer. It is much nicer if I don't continue to watch the video that I don't have to pay the full price.

2.) Why using lightning instead of an on chain transaction? I guess the main reason is that on chain transactions are slow and with the higher adoption of bitcoin also more expensive. This means that it will just be cheeper and faster to accept payments via the lightning network which goes in the direction of the guess you made. There is another advantage which is that your lightning channel can be reused over and over again.

> **Comments:**
> **username_0**: Good points although perhaps I wasn't clear enough in my question; that the comparison is between a continually updated LN channel and a one-off on-chain TX for the duration watched, not the whole video. Also on your point 2, an LN channel will always require N confirmations on the main chain just to open the channel. Having said that i suppose as ypu say, this is offset by one long running channel  
> **username_0**: This rather begs the question: what is the utility of a long running channel in the context of my question? I order to fulfil an LN invoice, the channel would need to be closed anway would it not?  
> **username_2**: no the point is that the channel does not have to be closed. it can stay open. that is the point of the Lightning Network. We open channels and use them hopefully forever (:  
> **username_0**: Brilliant. A channel not needing to be closed is a key piece I was missing. Missed because I was blinkered by my own 2-entity scenario.  

---

