LN routed transaction settlement | Bitcointalksearch.org

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: sjefdeklerk on January 21, 2018, 10:00:09 AM

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.

Anti-Cen

member

Activity: 210

Merit: 26

High fees = low BTC price

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

pebwindkraft

sr. member

Activity: 257

Merit: 343

Maybe the obstacle can get reduced, if you think of micro payments Grin

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://bitcointalksearch.org/topic/m.28466764

sjefdeklerk

jr. member

Activity: 154

Merit: 8

SODL

Quote from: achow101 on January 20, 2018, 10:53:32 PM

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?

achow101

staff

Activity: 3458

Merit: 6793

Just writing some code

Quote from: sjefdeklerk on January 20, 2018, 10:00:36 PM

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).

Quote from: sjefdeklerk on January 20, 2018, 10:00:36 PM

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

jr. member

Activity: 154

Merit: 8

SODL

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

Quote from: achow101 on January 20, 2018, 09:52:12 PM

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...

Quote

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

Quote

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

staff

Activity: 3458

Merit: 6793

Just writing some code

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

jr. member

Activity: 154

Merit: 8

SODL

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?

Topic: LN routed transaction settlement (Read 223 times)