why the Lightning Network channel can't Increase balance？

[SmartMeshFoundation]

if A and B have a Lightning Network channel，A has put some balance to this channel,when A translate some time with B, the balance of A is will be spend all, at this time the channel will be closed ,so why Lightning Network channel did not support increase balance to this existing channel，then A and B can continue use this channel for translate？

[rustyrussell]

SmartMesh <notifications@github.com> writes:

if A and B have a Lightning Network channel，A has put some balance to this channel,when A translate some time with B, the balance of A is will be spend all, at this time the channel will be closed ,so why Lightning Network channel did not support increase balance to this existing channel，then A and B can continue use this channel for translate？

It will. We call it splice in (and splice out is similar). It's just not in the 1.0 version, for simplicity. Cheers, Rusty.

[ZmnSCPxj]

I would also like to point out, that if A depletes its end of the channel, B will own (most of) the funds, and can send back to A. This means that it is still possible for another party, or B itself, to use the same channel to pay A, or to pay some other party via routing through A.

Thus there is no real need for A to close the channel. Rather, it would be better for A to open a new channel to yet another network participant C, as that is now an opportunity for A to earn routing fees from B->A->C.

So splice-in and possibly splice-out are, strictly speaking, unnecessary.

[rustyrussell]

"ZmnSCPxj, ZmnSCPxj jxPCSmnZ" <notifications@github.com> writes:

I would also like to point out, that if A depletes its end of the channel, B will own (most of) the funds, and can send back to A. This means that it is still possible for another party, or B itself, to use the same channel to pay A, or to pay some other party via routing through A. Thus there is no real need for A to close the channel. Rather, it would be better for A to open a new channel to yet another network participant C, as that is now an opportunity for A to earn routing fees from B->A->C. So splice-in and possibly splice-out are, strictly speaking, unnecessary.

True for splice-in. But you still want splice-out: that lets you make normal bitcoin payments straight from your lightning wallet. Cheers, Rusty.

[ZmnSCPxj]

"ZmnSCPxj, ZmnSCPxj jxPCSmnZ" ***@***.***> writes: > I would also like to point out, that if A depletes its end of the channel, B will own (most of) the funds, and can send back to A. This means that it is still possible for another party, or B itself, to use the same channel to pay A, or to pay some other party via routing through A. > > Thus there is no real need for A to close the channel. Rather, it would be better for A to open a new channel to yet another network participant C, as that is now an opportunity for A to earn routing fees from B->A->C. > > So splice-in and possibly splice-out are, strictly speaking, unnecessary. True for splice-in. But you still want splice-out: that lets you make normal bitcoin payments straight from your lightning wallet.

Ah, indeed, I had not thought of that. That would be quite a significant convenience.

[Richard87]

What do you mean by sending back to A?

What if we have a Merchant (M), a Customer (C) and a Node (N), and the merchant will never send out any money (maybe 1-2% in refunds)

Then we need 2 channels, Cx <=> N and N <=> M, if the capacity is 10 BTC on each channel, and the merchant charges 10 customers 1 BTC each, then on the channels Cx<=>N, N will own 10 BTC, and on the channel N<=>M M will own 10 BTC.

if I understand this correctly, now the trading stops since N can't send more money to M unless N recreates all his channels on the blockchain and moves the funds to the N<=>M channel?

Is there any BOLT Specification, or is this the issue that should solve this problem?

[ZmnSCPxj]

It is unrealistic to think, that the merchant will never send out any money.

The merchant, presumably, has its own employees, subcontractors, shareholders, and suppliers. The customer of one merchant, is the employee or shareholder of another merchant, else, how do you think, the customer gets its money? Even if, the merchant has to pay in non-bitcoin assets due to existing laws, presumably it must use some broker or exchange, and if an employee or shareholder is paid in non-bitcoin assets, presumably it also must use some broker or exchange. Even if those brokers or exchanges are not the same between them, then surely some arbitrageur must arise who connects multiple exchanges, and skims off any difference between them.

So perhaps a graph like Cx <=> E1 <=> Arbitrageur <=> E2 <=> M <= back to Cx

When a circle is thus formed, then it becomes possible to pay oneself, by spending funds in one channel, to pay oneself in another channel. Thus the customer Cx, who has been spending funds in the Cx <=> M direct channel, converts some of its non-bitcoin salary into bitcoin via E1 and receives it via the Cx <=> E1 channel, and can route it to the Cx <=> M channel via the Cx <=> E1 <=> Arbitrageur <=> E2 <=> M <=> Cx.

[Richard87]

Yes ofcourse, in the long term. In the short-term I believe that when merchant starts to accept Bitcoin/LN transactions, they will want to settle their channels once a week/day/transaction/as-soon-as-possible to fiat because of the volatility.

But that means that the node must have enough funds in the channel to cover all incoming transactions until the merchant decide to settle it, and once pr day might be alot of bitcoin for a node to invest in a channel.

Also, your scenario won't be possible before bitcoin is mainstream, and that won't happen before we get way lower fees, that I believe LN will solve, but unless the system won't work before it's mainstream and money is flowing in both direction, I believe it will take an extremely long time to get there...

Can we call it splice-cross or something, to support N to move funds from the Cx <=> N channel to the N <=> M channel without touching the blockchain?

Could Revive(https://eprint.iacr.org/2017/823.pdf) solve the challenge?

[ZmnSCPxj]

Revive requires a cycle (section 3.2.4 of paper you linked).

It is far easier to implement by just paying yourself (as I described above) over the cyclical channels rather than adding a new protocol that other node software have to reimplement.

My scenario only requires that exchanges work over Lightning, which I am sure will happen reasonably quickly. Converting coins to fiat because of volatility is SLOW if you do it once a week, but consider the implications if it is done on Lightning within seconds. Much less volatiility risk.

[Richard87]

Ahh, I understand, that would work :) Thanks for your time explaining it, supricingly simple and efficient :D

[johnsonhzhang]

@rustyrussell @ZmnSCPxj There's another way to increase or decrease the channel capacity, which requires only one transaction. https://github.com/litexnetwork/papers/blob/master/FundCasc.pdf

If A want to add 0.5 BTC to the channel, he can propose to create a new funding transaction which spent the old funding and another UTXO from A. The new Funding transaction can be created by following steps.

1. Creating a new Funding Transaction
2. Creating a pair of new Commitment Transactions (C2a and C2b), containing the corresponding RD2a and RD2b
3. Signing the new Commitment Transactions
4. Exchanging signatures for new Commitment Transactions
5. Signing a new Funding Transaction
6. Exchanging signatures for the new Funding Transaction
7. Broadcasting the new Funding Transaction

[ZmnSCPxj]

@johnsonhzhang please note that the one-transaction case splice-in for FundCasc you either have to wait for the new funding transaction to confirm, and thus cannot use the channel until the new funding tx confirms.

If you do not wait for the new funding transaction to confirm before allowing new channel updates, the following attack is possible on splice-in, observing that the "Tx from A" is spendable using only a signature from A.

1. Complete the protocol and wait for the new funding transaction to be signed.
2. Update the channel, which invalidates the previous commitment transactions.
3. Have A double-spend the "Tx from A" with higher feerate, RBFing the new funding transaction. Note that Peter Todd has claimed that a "sizeable minority" of miners now use a full-RBF policy (i.e. RBF is imposed on all transactions, not just those that signal opt-in for RBF).

The above results in the commitment transaction that spends from the new funding transaction being invalidated, since the new funding transaction is now invalid (it has been replaced out). The only remaining valid commitment transactions are those that spent from the old funding transaction, which is old state.

(it gets worse if you went through a step where you exchanged revocation keys for the old commitment transactions that spend from the old funding transaction: you now enable A to lock up the channel by double-spending the new funding transaction. Your old commitments cannot be used because they are revoked, and your new commitments cannot be used because they spend the new funding transaction that got RBFed away by A).

So you need two transactions if you want continuous use of the channel. In effect, A creates an "intermediate new" funding transaction, gets a revocable backout transaction from B spending the intermediate new funding transaction, then waits for the "intermediate new" transaction to confirm. Then they create a new funding transaction that spends both the old and intermediate new funding transaction. They create commitment transactions rooted from the new funding transaction, then exchange revocations from the old commitment transactions rooted from the old funding transaction and the revocation for the revocable backout. The only time that channel updates are not possible is while A and B are exchanging signatures for the new commitment transactions rooted from the new commitment transactions, until the revocation of the old commitment transactions and the revocable backout, which is expected to be quicker than confirmations of transactions.