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 <[email protected]> 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" <[email protected]> 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.

[johnsonhzhang]

@ZmnSCPxj Thanks for your reply. You have mentioned asynchronous splice-in which need two on-chain transactions. However, we prefer synchronous splice-in which costs less fee, even though it requires channel suspension and wait time for new funding transaction to be confirmed on chain.
In most scenarios, lightning nodes can have more than three live channels, and suspending one of them will not make too much of an impact.

[cfromknecht]

@ZmnSCPxj @johnsonhzhang Good evening! AFAIA, it is possible to do asynchronous splicing using one transaction, without the need to suspend a channel.

Say A and B have an existing funding output F_old and commitment states C_ia and C_ib. When A wishes to perform the splice, they create transactions as shown in the diagram by @johnsonhzhang, where the state of C_ia and C_ib are copied over to C_0a' and C_0b', with the additional funds (minus fees) added to A's commitment output of C_0a' and C_0b'.

The trick to continue using the old channel while F_new confirms is to then update both channels in tandem. The caveat is that the updates must be valid on both channels, which means inherently that the new funds added cannot be touched until F_new receives a sufficient number of confirmations.

Note that even if A double spends her input to F_new, the old channel has only been updated according to its active channel policy and the most recent state is still valid. If F_new does confirm, then any updates applied to the old channel are atomically carried over as if they had always been made on the new channel.

After sufficient confirmation, the parties then discard any state relating to the old channel. A and B then proceed in only updating the new channel, with the spliced-in funds now available.

[johnsonhzhang]

@cfromknecht It's a very good way to do asynchronous splicing. I like it despite it will increase the complexity of implementation.

[ZmnSCPxj]

The trick to continue using the old channel while F_new confirms is to then update both channels in tandem. The caveat is that the updates must be valid on both channels, which means inherently that the new funds added cannot be touched until F_new receives a sufficient number of confirmations.

While nice, it greatly increases complexity:

1. We need to use the old capacities, not the new capacities, since the on-mempool transaction might get RBFed away and so on.
2. Speaking of replacement, the new funding transaction might not confirm due to various reasons. We need to define what happens if the funding transaction has not been confirmed after say 2016 blocks. This is a potential DoS vector, since one side could make a new funding transaction spending their funds, then RBF it away, and the other side will keep expecting the new funding transaction to be confirmed at some point.
3. Again speaking of replacement, do we need to support special protocol support for RBF? So if a funding transaction is not getting confirmed and we want to speed it up for some reason, it would be good to have some capability to RBF it, which requires both sides to agree and sign a new funding transaction. (this is not needed for funding a new channel rather than splicing in again, since the funding side can simply send a new open_channel and whichever funding transaction actually confirms is what we end up using)
4. While waiting for an existing splice-in to confirm, can we ask for a new splice-in? If we can, then we end up having to update 3 commitment transactions. And so on. Probably better to just allow a single splice in at a time.

The complexities make me wonder if we are just overdesigning this. An alternative is to simply open a new channel elsewhere, and if absolutely necessary then move funds from the new channel to the old channel you want to replenish.

[cdecker]

Conner Fromknecht <[email protected]> writes:

@ZmnSCPxj @johnsonhzhang Good evening! AFAIA, it is possible to do asynchronous splicing using one transaction, without the need to suspend a channel. Say A and B have an existing funding output F_old and commitment states C_ia and C_ib. When A wishes to perform the splice, they create transactions as shown in the diagram by @johnsonhzhang, where the state of C_ia and C_ib are copied over to C_0a' and C_0b', with the additional funds (minus fees) added to A's commitment output of C_0a'. The trick to continue using the old channel while F_new confirms is to then update _both_ channels in tandem. The caveat is that the updates must be valid on both channels, which means inherently that the new funds added cannot be touched until F_new receives a sufficient number of confirmations. Note that even if A double spends her input to F_new, the old channel has only been updated according to its active channel policy and the most recent state is still valid. If F_new does confirm, then any updates applied to the old channel are atomically carried over as if they had always been made on the new channel. After sufficient confirmation, the parties then discard any state relating to the old channel. A and B then proceed in only updating the new channel, with the spliced-in funds now available.

That's a great idea, I love it. Just to give the usual plug about eltoo: with eltoo we can greatly simplify the state tracking required for this scheme, since we'd only need to keep track of a single transaction set for each splice-operation, and the reactions can run completely in parallel without any interaction :-)

[t-bast]

This is covered by splicing (see #1160).