Opening LN channel with zero balance?

[pawel7777]

As in subject: will Lightning Network allow opening channels with zero funds and without initial 'deposit' transaction (by just generating address and associating it with the channel)?

ie. If I wanted to send btc to other person (new to bitcoin) would that person need to have any own funds beforehand (on-chain)?

I'm guessing it's possible, but would like to confirm this with someone more knowledgeable.

[1715272727]

1715272727

[1715272727]

1715272727

[Quickseller]

When a LN channel is opened the total amount in a channel is sent to a 2-of-2 multisig address when each party has one of the two keys necessary to spend the BTC.

If someone had settled funds, then nothing from a technical standpoint would stop him from sending his BTC to a new LN channel with no when you have an opening "balance" of 0.

From an economic standpoint, this would make little sense because the person with settled funds would have to cover the entire tx fee (which is likely to be very expensive), and would have slightly less security because the other party to the LN channel would have no "deposit" they would lose in the event that he tried to broadcast an "old" transaction to close the LN channel.

[stdset]

Alice buys a car from a car dealer Bob.
She has yet to join LN so she opens a channel with Bob contributing a significant sum (price of the car), Bob doesn't contribute any funds to the channel. Entire channel balance immediately transferred to Bob with the first commitment transaction.
Alice plans to use this channel later to receive salary from her employer.

[achow101]

Alice buys a car from a car dealer Bob.
She has yet to join LN so she opens a channel with Bob contributing a significant sum (price of the car), Bob doesn't contribute any funds to the channel. Entire channel balance immediately transferred to Bob with the first commitment transaction.
Alice plans to use this channel later to receive salary from her employer.

It would be far more efficient for Alice to simply make an on chain payment for the car, and then open up a direct channel with her employer. This would reduce the number of transactions that Alice would need to make in order for her to send and receive her payments.

[stdset]

Alice buys a car from a car dealer Bob.
She has yet to join LN so she opens a channel with Bob contributing a significant sum (price of the car), Bob doesn't contribute any funds to the channel. Entire channel balance immediately transferred to Bob with the first commitment transaction.
Alice plans to use this channel later to receive salary from her employer.

It would be far more efficient for Alice to simply make an on chain payment for the car, and then open up a direct channel with her employer. This would reduce the number of transactions that Alice would need to make in order for her to send and receive her payments.

My scenario, onchain txses: channel opening.
Your scenario, onchain txses: car purchase, channel opening.
Possible drawbacks in my scenario:
1) Alice can't pay for anything with the new channel before she receives the first (after the purchase) salary.
2) If Bob doesn't offer intermediary services or if he charges incompetitive fee for conducting payments, it's better to open a channel not with Bob, but with a competitive hub and route the payment to Bob through the hub. If Bob's channel capacity with the network isn't enough, he can open another channel with a hub.
So, what do you mean?

[achow101]

My scenario, onchain txses: channel opening.
Your scenario, onchain txses: car purchase, channel opening.
Possible drawbacks in my scenario:
1) Alice can't pay for anything with the new channel before she receives the first (after the purchase) salary.
2) If Bob doesn't offer intermediary services or if he charges incompetitive fee for conducting payments, it's better to open a channel not with Bob, but with a competitive hub and route the payment to Bob through the hub. If Bob's channel capacity with the network isn't enough, he can open another channel with a hub.
So, what do you mean?

Over the long term, there will be more on chain transactions and more costs with your scenario.

In the US, the average car is ~$25,000 and the median household income is ~$50,000 per year.

Under your scenario:
Alice opens the channel with the Car dealership (1 on chain tx). In order for her employer to pay Alice through the car dealer, they would need to have a payment channel with more than $50,000 to pay Alice for the year (which I find unlikely), or they will need to load their payment channel to match Alice's salary (another on chain tx). Now in order for Alice to receive her entire $50,000 salary, she (or the car dealer) will need to close a payment channel (another on chain tx), load up Alice's channel (another on chain tx), and probably open up another channel with whoever they closed with (another on chain tx) In one year, Alice will have made or required to be made 5 on chain txs. Furthermore, the car dealer is likely to charge a fee for being a third party between Alice and the employer.

Under my scenario:
Alice sends 1 on chain transaction for the car. She opens a payment channel with her employer, who loads into the channel however much they expect to pay her that year, so $50,000 (another on chain transaction). At the end of the year, the channel is loaded with her next year's salary (another on chain transaction). In total, she makes only 3 on chain transactions, and does not need to pay a third party for being a hub. Like with the Car dealer, Alice can buy things by using her employer as a hub, but because the channel already has her entire yearly salary there, no on chain txs need to be made to load any more money into that channel (unless she is spending from here savings).


Lightning is fairly useless for big one time purchases. It is far more efficient to use just a normal on chain transaction to make a big purchase like a car or a house.

A far more likely scenario for one party to put in 0 funds into a channel is for an employer to be paying an employee.

[stdset]

Over the long term, there will be more on chain transactions and more costs with your scenario.

In the US, the average car is ~$25,000 and the median household income is ~$50,000 per year.

Under your scenario:
Alice opens the channel with the Car dealership (1 on chain tx). In order for her employer to pay Alice through the car dealer, they would need to have a payment channel with more than $50,000 to pay Alice for the year (which I find unlikely), or they will need to load their payment channel to match Alice's salary (another on chain tx). Now in order for Alice to receive her entire $50,000 salary, she (or the car dealer) will need to close a payment channel (another on chain tx), load up Alice's channel (another on chain tx), and probably open up another channel with whoever they closed with (another on chain tx) In one year, Alice will have made or required to be made 5 on chain txs. Furthermore, the car dealer is likely to charge a fee for being a third party between Alice and the employer.

Under my scenario:
Alice sends 1 on chain transaction for the car. She opens a payment channel with her employer, who loads into the channel however much they expect to pay her that year, so $50,000 (another on chain transaction). At the end of the year, the channel is loaded with her next year's salary (another on chain transaction). In total, she makes only 3 on chain transactions, and does not need to pay a third party for being a hub. Like with the Car dealer, Alice can buy things by using her employer as a hub, but because the channel already has her entire yearly salary there, no on chain txs need to be made to load any more money into that channel (unless she is spending from here savings).


Lightning is fairly useless for big one time purchases. It is far more efficient to use just a normal on chain transaction to make a big purchase like a car or a house.

A far more likely scenario for one party to put in 0 funds into a channel is for an employer to be paying an employee.

Alice's employer not only pays salaries, he also receives payments. So there's no need to load entire yearly salary to a personal channel with Alice. There's even no need to have a separate channel for Alice. It's much better to have a channel with a hub, pay salaries through that channel and receive payments through the same channel. Alice can receive many monthly salaries through a channel created with a car purchase, it has very high receiving capacity, it will save many onchain txses.

[Quickseller]

Alice buys a car from a car dealer Bob.
She has yet to join LN so she opens a channel with Bob contributing a significant sum (price of the car), Bob doesn't contribute any funds to the channel. Entire channel balance immediately transferred to Bob with the first commitment transaction.

This would probably not be a good idea for either party. Both parties would need to pay higher fees than if they had covered the tx fee for an on-chain transaction. There is also no guarantee that either party will facilitate LN transfers in the futures and be willing to pay/accept what the other party deems to be a reasonable LN fee.

It would also not be unreasonable to expect you to receive a LN payment via this channel, and subsequently spend the majority of said payment in a subsequent LN transaction. If this were to happen, then you could attempt to broadcast a settlement transaction that is not the most recent, that would result in you receiving more BTC than what you and the dealership have most recently agreed to -- in this situation, the dealership should normally be able recover then entire balance within the channel before you can spend the portion spent to you, however doing so would incur an additional tx fee that the dealership would need to bear in it's entirety in order to claim an amount that they are due anyway....and you are not risking very much/anything when you attempt to steal these funds (at most a nominal amount).  

Alice plans to use this channel later to receive salary from her employer.

If you do this, then the dealership might see that your portion of the LN channel is receiving the exact same amount on a very regular basis, they might be able to reasonably conclude the amount of your bi-weekly (or whatever frequency) paycheck, harming your privacy (the exact information they will know is that the balance of your channel is increasing every other Friday by the same amount, they will not have proof if you are receiving this payment, or if you are acting as an intermediary. They will also know the  channel that is sending the payment to you, they wont know if that channel is sending the payment directly or if they are acting as an intermediary).

Also, if you only have one LN channel open, then you will need to accept whatever LN fee the dealership is charging (they can change the LN fee at anytime without notice), or else close/settle the LN channel, delaying your access to your money AND be forced to pay a very high tx fee.

[stdset]

There is also no guarantee that either party will facilitate LN transfers in the futures and be willing to pay/accept what the other party deems to be a reasonable LN fee.

If Bob doesn't offer intermediary services or if he charges incompetitive fee for conducting payments, it's better to open a channel not with Bob, but with a competitive hub and route the payment to Bob through the hub. If Bob's channel capacity with the network isn't enough, he can open another channel with a hub.

then you could attempt to broadcast a settlement transaction that is not the most recent, that would result in you receiving more BTC than what you and the dealership have most recently agreed to -- in this situation, the dealership should normally be able recover then entire balance within the channel before you can spend the portion spent to you, however doing so would incur an additional tx fee that the dealership would need to bear in it's entirety in order to claim an amount that they are due anyway....and you are not risking very much/anything when you attempt to steal these funds (at most a nominal amount). 

Again, if the dealership doesn't offer LN intermediary services, they can use their respective hubs. Also, if one party tries to cheat and broadcasts an obsolete commitment tx, another party can take all channel funds, that will probably not only cover all necessary fees, but much more. Also, since all parties know, that broadcasting obsolete commitment txes is disadvantageous, they won't even attempt doing so.

[Quickseller]

There is also no guarantee that either party will facilitate LN transfers in the futures and be willing to pay/accept what the other party deems to be a reasonable LN fee.

If Bob doesn't offer intermediary services or if he charges incompetitive fee for conducting payments, it's better to open a channel not with Bob, but with a competitive hub and route the payment to Bob through the hub. If Bob's channel capacity with the network isn't enough, he can open another channel with a hub.

then you could attempt to broadcast a settlement transaction that is not the most recent, that would result in you receiving more BTC than what you and the dealership have most recently agreed to -- in this situation, the dealership should normally be able recover then entire balance within the channel before you can spend the portion spent to you, however doing so would incur an additional tx fee that the dealership would need to bear in it's entirety in order to claim an amount that they are due anyway....and you are not risking very much/anything when you attempt to steal these funds (at most a nominal amount). 

Again, if the dealership doesn't offer LN intermediary services, they can use their respective hubs. Also, if one party tries to cheat and broadcasts an obsolete commitment tx, another party can take all channel funds, that will probably not only cover all necessary fees, but much more. Also, since all parties know, that broadcasting obsolete commitment txes is disadvantageous, they won't even attempt doing so.

1 - if I have a LN channel open with the dealership, and the dealership does not offer intermediary services, then the only use of that LN channel is to transact with that dealership. If the dealership is connected to a LN hub that I am not connected to, then I cannot transaction with that LN hub without the cooperation of the dealership, or I would need to route payments via other means to that LN hub via other cooperating LN channels.

2 - Say for example that you buy a $25,000 car from a local car dealership. You open a LN channel in which you send $25,000 and the dealership sends $0.00, and you subsequently sign transactions changing the balance of the LN channel so that the dealership has $25,000 and you have $0.00 -- now the car is paid for. The following Friday, you get paid by your employer via the LN channel you have open with the car dealership, and you get paid $3,000, now the balance of the LN channel is you have $3,000 and the dealership has $22,000. You subsequently use that same LN channel to pay $1,500 to your landlord, and $1,490 towards your other monthly expenses -- now the LN channel has a balance of $10 for you, and $24,990 for the dealership. If you were to broadcast a closing transaction that resulted in you receiving $3,000, then the dealership would be able to claim the full $25,000 in the LN channel, however the tx fee would likely be greater than $10, so they are loosing money by doing this, and there is the potential that for whatever reason, the dealership does not realize that you broadcast an old closing transaction and/or the dealership is not able to claim the entire balance in the LN channel because of on-chain transaction backlogs, so there is no financial risk to you broadcasting an old transaction, because after tx fees, you would have gotten nothing after the channel is closed anyway.   

[stdset]

1 - if I have a LN channel open with the dealership, and the dealership does not offer intermediary services, then the only use of that LN channel is to transact with that dealership. If the dealership is connected to a LN hub that I am not connected to, then I cannot transaction with that LN hub without the cooperation of the dealership, or I would need to route payments via other means to that LN hub via other cooperating LN channels.

That's why I suggest opening a channel not with the dealership, but with a hub, in this case.

then the dealership would be able to claim the full $25,000 in the LN channel, however the tx fee would likely be greater than $10, so they are loosing money by doing this, and there is the potential that for whatever reason, the dealership does not realize that you broadcast an old closing transaction and/or the dealership is not able to claim the entire balance in the LN channel because of on-chain transaction backlogs, so there is no financial risk to you broadcasting an old transaction, because after tx fees, you would have gotten nothing after the channel is closed anyway.   

If tx fees are so significant, the dealership, as well as other intermediaries should abstain from completely emptying balances of their counterparties in their respective channels. Always leave enough in a channel to cover possible onchain fees. Also if onchain fees are so high, it's an additional incentive to use LN.
Every LN participant and especially intermediaries, should be online often enough to check for old commitment txes, before their outputs become spendable for their counterparties. Transactions backlog may be a problem. But provided that enough funds are left in a channel, it should be possible to offer miners enough fee to get ahead of queue without suffering even a small loss. Also there are solutions proposed for fast dynamic blocksize: https://bitcointalk.org/index.php?topic=1713807.0

[dinofelis]

1 - if I have a LN channel open with the dealership, and the dealership does not offer intermediary services, then the only use of that LN channel is to transact with that dealership. If the dealership is connected to a LN hub that I am not connected to, then I cannot transaction with that LN hub without the cooperation of the dealership, or I would need to route payments via other means to that LN hub via other cooperating LN channels.

That's why I suggest opening a channel not with the dealership, but with a hub, in this case.

This is why LN is banking.  A few big hubs are the banks.  Everyone will want to connect to them, and they set their conditions.

[stdset]

1 - if I have a LN channel open with the dealership, and the dealership does not offer intermediary services, then the only use of that LN channel is to transact with that dealership. If the dealership is connected to a LN hub that I am not connected to, then I cannot transaction with that LN hub without the cooperation of the dealership, or I would need to route payments via other means to that LN hub via other cooperating LN channels.

That's why I suggest opening a channel not with the dealership, but with a hub, in this case.

This is why LN is banking.  A few big hubs are the banks.  Everyone will want to connect to them, and they set their conditions.

That's may be true to some extent. In the sense that hubs and spokes architecture is simpler and cheaper than mesh-like. But what power will hubs have? Rising fees? There will always be enough competition to keep fees low. What else?

[dwieyani]

zero balance what is the reason why I do not understand please love feedback for me.
whether this channel LN zero balance?

[fathur.aza]

do not let all no problem if they are less guarantees about LN.

[Carlton Banks]

1 - if I have a LN channel open with the dealership, and the dealership does not offer intermediary services, then the only use of that LN channel is to transact with that dealership. If the dealership is connected to a LN hub that I am not connected to, then I cannot transaction with that LN hub without the cooperation of the dealership, or I would need to route payments via other means to that LN hub via other cooperating LN channels.

That's why I suggest opening a channel not with the dealership, but with a hub, in this case.

This is why LN is banking.  A few big hubs are the banks.  Everyone will want to connect to them, and they set their conditions.

Except one crucial difference.

Not just anyone can open a bank, there are very significant real-world political obstacles to get past, very few genuinely new banks open as a result.

Lightning can behave like banking, but because people have the freedom to open their own banks (really more like a mixture of a bank and a VISA/Amex type payment processor), they will do that.

Some people will try, and fail. Regular everyday people paying each other small amounts through channels might decide the price is too high. Or, they might decide that price is worth it, for the enhanced privacy of doing business in a private channel.

But even small businesses will be able to compete on costs with channels. Maybe an ecosystem of small payment processors might arise, servicing a small geographical area (for instance, a landowner leasing shop units would do well to make using their channel a part of the contract for all the shop leases they offer).

Or maybe the economics will be such that very small shops can afford to run their own channel. If a small shop has goods of sufficient quality, the clientele may prefer to pay the higher channel fees in order to get the high quality product that our small shop sells.



So no, dino, it's not "just like banking". It resembles it in some ways, but in fact it resembles Hayek's "free banking concept " most of all. Now do be quiet, people are interested in having a productive conversation about Lightning.

[goregrind]

Except one crucial difference.

The strongest point of Bitcoin is its decentralization and this is why the scaling debate is such a big issue.
Why is it that we're now ok with centralization ? If lightning leads to a few centralized hubs then we need
to design it in such a way that this won't cause issues further down the road.
We're taking this too lightly.

[stdset]

The strongest point of Bitcoin is its decentralization and this is why the scaling debate is such a big issue.
Why is it that we're now ok with centralization ? If lightning leads to a few centralized hubs then we need
to design it in such a way that this won't cause issues further down the road.

What do you mean by 'few'? More than likely LN hubs will be orders of magnitude more numerous than mining pools are now.

[pinkflower]

The explanations have gotten way too complicated for what pawel777 was asking. Im interested in the answer too. Allow me to rephrase the question. In LN, do we need some kind of show money to open a channel? Is it possible to only open a channel now without the show money for future use if I already have the show money?

[achow101]

The explanations have gotten way too complicated for what pawel777 was asking. Im interested in the answer too. Allow me to rephrase the question. In LN, do we need some kind of show money to open a channel? Is it possible to only open a channel now without the show money for future use if I already have the show money?

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Edit: You can open a channel where only one party funds it. I read this part of the spec incorrectly. See https://bitcointalk.org/index.php?topic=1848861.msg18444685#msg18444685

[cr1776]

Except one crucial difference.

The strongest point of Bitcoin is its decentralization and this is why the scaling debate is such a big issue.
Why is it that we're now ok with centralization ? If lightning leads to a few centralized hubs then we need
to design it in such a way that this won't cause issues further down the road.
We're taking this too lightly.

I can spin up a lightning daemon on one of my existing web servers quite quickly.  And I could add bitcoind to it easily if it wasn't already on a particular machine.  The barriers to entry are low.  The cost on an existing server is negligible, but it can bring in revenue.  It may be that this increases the number of bitcoin nodes because of this.

Very likely the numbers will be higher than the existing number of mining pools since p2pool hasn't been getting much love.  Centralized mining is a huge concern.

[goregrind]

I can spin up a lightning daemon on one of my existing web servers quite quickly.  And I could add bitcoind to it easily if it wasn't already on a particular machine.  The barriers to entry are low.  The cost on an existing server is negligible, but it can bring in revenue.  It may be that this increases the number of bitcoin nodes because of this.

Whats the point of you being able to run a lightning node if no payments will be routed through it ?
Just because you can run a node doesn't mean it will be used. You will have to compete with the bigger hubs on fees and uptime.
The best lightning setup is with one central hub.

[cr1776]

I can spin up a lightning daemon on one of my existing web servers quite quickly.  And I could add bitcoind to it easily if it wasn't already on a particular machine.  The barriers to entry are low.  The cost on an existing server is negligible, but it can bring in revenue.  It may be that this increases the number of bitcoin nodes because of this.

Whats the point of you being able to run a lightning node if no payments will be routed through it ?
Just because you can run a node doesn't mean it will be used. You will have to compete with the bigger hubs on fees and uptime.
The best lightning setup is with one central hub.

What is your definition of "bigger hubs"?

My cost is essentially zero, so my fees would be low (or zero if I wanted).  My web servers are well connected, good memory, reasonably high CPU power, high bandwidth, low latency, extremely high uptime nodes.  The web sites have been online continuously since 1993 or 1994 (depending on the web site).  Why wouldn't payments be routed through any one I decided to set up?

I don't see "bigger hubs" being a relevant factor - or even a useful description - as to why these "bigger hubs" would be more attractive than one I spun up on a different server.  What would they offer that someone couldn't duplicate quite easily? :-)

[DooMAD]

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Does that not limit the utility somewhat?  If it's going to help with scaling, surely it needs as many use cases as possible?  If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential.  All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain.  Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with?  It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution.  It should still be available as an option, certainly, but it's not the complete answer.

[goregrind]

I don't see "bigger hubs" being a relevant factor - or even a useful description - as to why these "bigger hubs" would be more attractive than one I spun up on a different server.  What would they offer that someone couldn't duplicate quite easily? :-)

Suppose that everyone has an open channel to amazon. Given this everyone can pay everyone through amazon with just one channel open.
You can spawn as many nodes as you want theres nothing you can do to get any payments routed through your node because X-Amazon-Y will always be the shortest path. The more connected your node is the more useful it is so new nodes have no use.

[Carlton Banks]

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Does that not limit the utility somewhat?  If it's going to help with scaling, surely it needs as many use cases as possible?  If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential.  All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain.  Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with?  It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution.  It should still be available as an option, certainly, but it's not the complete answer.

DooMAD, where are you getting all of this from?


You often display fear and uncertainty in respect of Lightning and how it will work.


Here's my suggestion to you: if you could take the time to read about how Lightning does work, you would be less afraid. It's easy to be afraid when your knowledge of a new subject is incomplete, but you seem determined not to plug the hole in your learning.

And please, stop parroting this "available as an option, certainly, but it's not the complete answer" line. It only serves to show how willfully ignorant you are in respect of Lightning: no-one in favour of Lightning believes it, and so no Lightning proponent has ever expressed that desire. It's all in your imagination, you are very paranoid about the Lightning network, aren't you?  

Calm down, knowledge and learning are your friends, not your enemies.

[DooMAD]

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Does that not limit the utility somewhat?  If it's going to help with scaling, surely it needs as many use cases as possible?  If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential.  All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain.  Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with?  It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution.  It should still be available as an option, certainly, but it's not the complete answer.

DooMAD, where are you getting all of this from?


You often display fear and uncertainty in respect of Lightning and how it will work.


Here's my suggestion to you: if you could take the time to read about how Lightning does work, you would be less afraid. It's easy to be afraid when your knowledge of a new subject is incomplete, but you seem determined not to plug the hole in your learning.

And please, stop parroting this "available as an option, certainly, but it's not the complete answer" line. It only serves to show how willfully ignorant you are in respect of Lightning: no-one in favour of Lightning believes it, and so no Lightning proponent has ever expressed that desire. It's all in your imagination, you are very paranoid about the Lightning network, aren't you?  

Calm down, knowledge and learning are your friends, not your enemies.

If there's uncertainty about how it will work, it probably doesn't help when you tell people there are at least five different variations of it.  I take it I should be an expert on every single one before I'm permitted to ask simple questions amid your omniscient presence?  Or maybe you could be a touch less condescending and just explain why it's fine to work the way achow101 describes?  Maybe try not treating everyone as a hostile combatant and just have a conversation like a normal person would.  That would be refreshing.  If you recall, my suggestion to you was to work on that not-so-winning personality of yours.  You'll find people far more receptive to a sales pitch if they actually like you.

I read the original lightning whitepaper and don't recall the part where both parties are mandated to lock funds, just that the total balance had to be locked and funds could be transferred from one party to another in the multisig channel.  I'm sure I'll get around to reading it again at some point, but the impression I got was that Bob could put in the total sum and that Alice could put in zero and that Bob could transfer the total to Alice.  If Alice has sold an item to Bob for the amount Bob is paying Alice, why does Alice also have to lock funds up "so there is an incentive for both parties to not scam the other person" as Achow101 said?

[achow101]

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Does that not limit the utility somewhat?  If it's going to help with scaling, surely it needs as many use cases as possible?  If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential.  All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain.  Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with?  It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution.  It should still be available as an option, certainly, but it's not the complete answer.

Actually, I read that part of the spec incorrectly.

From the spec:

The channel reserve is specified by the peer's channel-reserve-satoshis; 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially this reserve may not be met, as only one side has funds, but the protocol ensures that progress is always toward it being met, and once met it is maintained.

So you can have a channel where one party puts in 0 funds, but once that party's balance is greater than the channel-reserve-satoshis, their balance cannot go below that minimum so that they always have something to lose if they try to broadcast an older commitment.

[DooMAD]

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Does that not limit the utility somewhat?  If it's going to help with scaling, surely it needs as many use cases as possible?  If you have to lock up old funds just to receive new funds, it could put some people off and conceivably limit Lightning's scaling potential.  All it might take is a few bad experiences or some lost funds and suddenly people are back to putting every tiny transaction on the main chain.  Would a merchant have to lock up an amount of their own funds for every single customer they have a channel with?  It needs to work securely with one party putting nothing in, or IMO it's not a true scaling solution.  It should still be available as an option, certainly, but it's not the complete answer.

Actually, I read that part of the spec incorrectly.

From the spec:

The channel reserve is specified by the peer's channel-reserve-satoshis; 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially this reserve may not be met, as only one side has funds, but the protocol ensures that progress is always toward it being met, and once met it is maintained.

So you can have a channel where one party puts in 0 funds, but once that party's balance is greater than the channel-reserve-satoshis, their balance cannot go below that minimum so that they always have something to lose if they try to broadcast an older commitment.

Thank you, achow101.  That assuages my concerns.  I just wish everyone could be as helpful in resolving such moments of uncertainty.

[pinkflower]

The explanations have gotten way too complicated for what pawel777 was asking. Im interested in the answer too. Allow me to rephrase the question. In LN, do we need some kind of show money to open a channel? Is it possible to only open a channel now without the show money for future use if I already have the show money?

With the current lightning spec document, both parties need to put in some amount of money so that both parties have something to lose so there is an incentive for both parties to not scam the other person.

Edit: You can open a channel where only one party funds it. I read this part of the spec incorrectly. See https://bitcointalk.org/index.php?topic=1848861.msg18444685#msg18444685

Thank you for the the simplified post. It makes more sense to me now. Another thing I would want to know is if I open a channel to someone I dont want to have a direct channel to, can I open a channel with another user who I know has a payment channel open to the one I dont want direct channel to, without him needing to acknowledge anything? Since theres no need for the other party to have BTC locked does he still need to approve for me to connect to him or does it happen automatically?

[pawel7777]

...
Edit: You can open a channel where only one party funds it. I read this part of the spec incorrectly. See https://bitcointalk.org/index.php?topic=1848861.msg18444685#msg18444685

Thanks achow, that's all I was asking.

To push the discussion a bit further, is it possible (when LN reaches its full potential) for the average user to use LN without ever performing on-chain transactions?

If: 1) LN are secure and fraud resistant; 2) you don't need to engage any funds to open channel; 3) you can connect to pretty much every other user or service via hub; 4) channels can stay open indefinitely (according to the wiki page) - Then it seems perfectly plausible to be able to buy/sell for fiat and perform all kind of transactions directly on LN without ever touching the blockchain.

Is there anything that enforces users (or even businesses) to settle on-chain?

[achow101]

Thank you for the the simplified post. It makes more sense to me now. Another thing I would want to know is if I open a channel to someone I dont want to have a direct channel to, can I open a channel with another user who I know has a payment channel open to the one I dont want direct channel to, without him needing to acknowledge anything? Since theres no need for the other party to have BTC locked does he still need to approve for me to connect to him or does it happen automatically?

Your question is a bit hard to understand. So you basically want someone to pay you without them knowing that they are paying you? Or do you mean routing payments through a hub without the hub knowing that you are routing payments through him?

Either way, I don't think it is possible because each hub in the route will need to create an HTLC and change the balance of each channel involved in the payment, so they will know that a payment is being routed through them.

Thanks achow, that's all I was asking.

To push the discussion a bit further, is it possible (when LN reaches its full potential) for the average user to use LN without ever performing on-chain transactions?

If: 1) LN are secure and fraud resistant; 2) you don't need to engage any funds to open channel; 3) you can connect to pretty much every other user or service via hub; 4) channels can stay open indefinitely (according to the wiki page) - Then it seems perfectly plausible to be able to buy/sell for fiat and perform all kind of transactions directly on LN without ever touching the blockchain.

Is there anything that enforces users (or even businesses) to settle on-chain?

In theory, yes. In practice, maybe not.

[Andre_Goldman]

When a LN channel is opened the total amount in a channel is sent to a 2-of-2 multisig address when each party has one of the two keys necessary to spend the BTC.

I'm so slow to get the idea...   

... actually I'm thinking if it would be 'Self-enforcing protocol' ...

I swear ... I even open a book in order to understand the protocol ...



ps-> Are we going to stick to the Classical crypto 'Dramatis Personae'