LN routed transaction settlement

[sjefdeklerk]

Let's say 3 users have 2 payment channels: User A has a channel (1) with user B and user B has a channel (2) with user C. All users deposit 1 BTC into their channel. Now user A wants to pay 1 BTC to user C, routing via B. After this channel (2) gets closed. Now how do the final on-chain transactions look ?

I'm confused here. It almost can't be that channel (2) now moves 2 BTC to user C and 1 to user B, because the ledger only registered the channel as having 2 BTC in it. But the alternative would be that transactions from channel (1) into (2) would take place. But I can also not imagine this to happen, because then tons of closing transactions would be needed if I'd have routed to several other people, resulting in huge closing fees. Also it would force an on-chain transaction from channel 1 to channel 2 while channel 1 is still open.

Anybody?

[achow101]

When routing payments, the commitment transactions are updated to reflect the routing. So for Channel 1, A's balance will be 0 BTC and B's will be 2 BTC. For Channel 2, B's balance will be 0 BTC and C's will be 2 BTC. If the commitments are broadcast, A will have 1 less BTC, B will have the same amount, just different outputs, and C will have 1 more BTC. All that happened is that 1 BTC moved from A to B on Channel 1 and 1 BTC moved from B to C on Channel 2.

To guarantee the money transfer, there are actually new outputs created called HTLC outputs. These HTLCs guarantee that all parties will get their money or the route will timeout and the original owners will get their money if the commitments are broadcast. What will usually happen is that the HTLCs are settled off chain once the route is complete but commitments are not actually broadcast. So the values of the respective outputs are merged.

[sjefdeklerk]

Thanks for your answer, as always much appreciated. Some questions though:

When routing payments, the commitment transactions are updated to reflect the routing. So for Channel 1, A's balance will be 0 BTC and B's will be 2 BTC. For Channel 2, B's balance will be 0 BTC and C's will be 2 BTC. If the commitments are broadcast, A will have 1 less BTC, B will have the same amount, just different outputs, and C will have 1 more BTC. All that happened is that 1 BTC moved from A to B on Channel 1 and 1 BTC moved from B to C on Channel 2.

That makes a lot of sense from a logical point of view. However what does sound weird is that B didn't do any transactions himself and now is out of money on channel 2! If he wants to make a payment in channel 2 he actually needs to fund it again. So if you're not doing a payment yourself but are part of a route, then it's possible money transfers from your one payment channel to your other payment channel. Hmm...

To guarantee the money transfer, there are actually new outputs created called HTLC outputs. These HTLCs guarantee that all parties will get their money or the route will timeout and the original owners will get their money if the commitments are broadcast.

Right

What will usually happen is that the HTLCs are settled off chain once the route is complete but commitments are not actually broadcast. So the values of the respective outputs are merged.

This I dont follow, do you have an example maybe? I'm not sure what you're trying to say here.

Thanks !

[achow101]

That makes a lot of sense from a logical point of view. However what does sound weird is that B didn't do any transactions himself and now is out of money on channel 2! If he wants to make a payment in channel 2 he actually needs to fund it again. So if you're not doing a payment yourself but are part of a route, then it's possible money transfers from your one payment channel to your other payment channel. Hmm...

B is likely to be chosen for a transaction that goes in the opposite direction, so over a long period of time, his balance will even itself out as C will send back to A (or be part of a route that includes C -> B -> A).

This I dont follow, do you have an example maybe? I'm not sure what you're trying to say here.

In Channel 1, B's commitment transaction will look like this before the route is established:

Code:

Funding input --> B's local output 1 BTC
              --> A's remote output 1 BTC

After the route is established, the commitment will become

Code:

Funding input --> B's local output: 1 BTC
              --> A's remote output: 0 BTC
              --> HTLC offered to B from A: 1 BTC

Once B has the necessary information that would allow him to spend from the HTLC offered output, he can talk to A and settle this off chain by combining that HTLC with his local output, so the commitment becomes:

Code:

Funding input --> B's local output: 2 BTC
              --> A's remote output: 0 BTC

[sjefdeklerk]

B is likely to be chosen for a transaction that goes in the opposite direction, so over a long period of time, his balance will even itself out as C will send back to A (or be part of a route that includes C -> B -> A).

Agreed. Yet, man, it would be a huge obstacle, at least for me personally, to open up my channels for routing. I mean, there's a reason why I'd have $2500 in the channel with my landlord and $25 in the channel with my coffeeshop and not the other way around.

I'm thinking though, I could move money around my own channels for free I guess? *EDIT* no that won't be possible, user B can't move money into channel 2 because then the channel's worth would be over 2 BTC. The only way would be an on-chain transaction, right?

[pebwindkraft]

Maybe the obstacle can get reduced, if you think of micro payments 
A new technology never spends "millions" from the very beginning, for sure. It is easier to lower the level of a possible loss, and get accustomed to the technology (we usually gain trust in a technology over time, if we can rely on it). Personally I will start with Satoshis in the channels, not bitcoins. But I see your point: for a proper risk assessment, you have to do a qualitative and then a quantitative risk assessment, to be able to define a possible loss, and create a monetary value behind for risk mitigation or avoidance...

This thread covers a bit the same: https://bitcointalk.org/index.php?topic=2781978.msg28466764#msg28466764

[Anti-Cen]

Snooker Balls

Both party's to a channel share a private ledger but the trouble is that it's not the same
money that gets relayed on across the route because money does not cross between ledgers
that don't share the same channel

Bob --------------------->Bank Hub>---------------Alice
            $1000-$100                           $50-$10

Now Bob has more than enough money to send Alice $500 but because the banking hub
only put $50 in the private ledger between the bank and Alice when Alice opened the channel
last week he does not have the finance available to pass the on $500 in the ledger.

The way it has been designed by my understanding is that bank hub cannot just take money
out of the ledger on the left and move it to the ledger on the right and as you can see the
ledger on the right does not have the capacity to transfer the funds.

Yes i know the logic does not add up but due to the way channels are created by the miners
this is how it works so feel free to provide me proof from the lightning white paper if you feel that
i am wrong.

https://lightning.network/lightning-network-paper.pdf

[achow101]

Agreed. Yet, man, it would be a huge obstacle, at least for me personally, to open up my channels for routing. I mean, there's a reason why I'd have $2500 in the channel with my landlord and $25 in the channel with my coffeeshop and not the other way around.

I'm thinking though, I could move money around my own channels for free I guess? *EDIT* no that won't be possible, user B can't move money into channel 2 because then the channel's worth would be over 2 BTC. The only way would be an on-chain transaction, right?

You can loop money back to yourself to re-balance your channels.