Lightning - Question to understand atomic transactions over the network

[Kogs]

Hi,

I'm trying to deeply understand how the lightning network is working.

I understand how a payment channel between two nodes works, but I did not find out yet, how a more complex multi hop transaction is working in terms of an atomic transaction.

How does the network make sure, that all nodes are doing the transaction if everything is fine, or that no node is doing the transaction if any problem occurs (for example one of the selected nodes in the route is down).

I understand the network like this.

1) Sender is searching the best route through all nodes to reach the target.
2) Sender is encrypting the selected route node by node (onion routing)
3) Sender send coins to the first node using a payment channel between sender and first node
4) The next node decrypts the follow up node and continue sending coins to the next node over the next payment channel
5) continue with 4 until the target node is reached.

In my understanding, whenever I send something over the payment channel, this transaction is completed and not reversible (this is maybe the point where I'm wrong).
So, when I have 10 nodes in my selected route, and node 5 in my list is down. How does the network make sure, that the 4 nodes before are doing a rollback to give back the coins to the sender, so the sender can try a different route.

An explanation about this missing link I have would be great.

Thank you in advanced.

[1715533595]

1715533595

[1715533595]

1715533595

[Anti-Cen]

2) Sender is encrypting the selected route node by node (onion routing)

You could be right but how does the sender know what channels are open between each of the banking nodes
to be in a position to plan the route ?

The number of hops needed seems to be about six but the network is not fluid, more like snooker balls
bumping into each other with your money remaining inside the first ledger and this is the reason you end
up having to borrow money in effect to send payments across the network.

Bob and Alice models are never going to work here because the number of hops required would be
measured in hundreds and the Alice's of this world don't have $1m to finance hundreds of channels.

DO Please correct me if I am wrong here because that is my understanding.

Here is the current map if that helps you https://lnmainnet.gaben.win/

[Kogs]

2) Sender is encrypting the selected route node by node (onion routing)

You could be right but how does the sender know what channels are open between each of the banking nodes
to be in a position to plan the route ?
...
Here is the current map if that helps you https://lnmainnet.gaben.win/

You answer your question by yourself.
With the link you provided you see the complete network. Each node has information about the exact same info like this site has. You know each node in the network with each capacity of every payment channel between two nodes. So by knowing this, the source can make whatever route it wants to reach the target (I think there is a limit of maximum 20 hops).

Different implementations may focus on different strategies to route to the target. But I guess the most will try to find the cheapest route which has enough capacity to send the coins.

[achow101]

I understand the network like this.

1) Sender is searching the best route through all nodes to reach the target.
2) Sender is encrypting the selected route node by node (onion routing)
3) Sender send coins to the first node using a payment channel between sender and first node
4) The next node decrypts the follow up node and continue sending coins to the next node over the next payment channel
5) continue with 4 until the target node is reached.

In my understanding, whenever I send something over the payment channel, this transaction is completed and not reversible (this is maybe the point where I'm wrong).
So, when I have 10 nodes in my selected route, and node 5 in my list is down. How does the network make sure, that the 4 nodes before are doing a rollback to give back the coins to the sender, so the sender can try a different route.

That's not how payment routing actually works. That's just the messaging protocol to transmit some information between nodes.

The actual payment part works through Hashed Time Locked Contracts (HTLCs). So node A offers a HTLC output to node B. In order for node B to spend from that HTLC (thus being paid by node A), he needs to provide the preimage to some hash in addition to his own signature. After some timeout, node A can take the money back with a signature of his own.

In LN, the HTLCs are used to make the payments between the nodes. They use the same hash so they all have the same hash pre-image required. So if any one HTLC is spent, all HTLCs in the route can be spent since the hash pre-image is revealed during the spend. If the hash preimage is never revealed, then the coins are never sent to the other party. This makes it atomic.

As a shortcut (to avoid on chain transactions for each HTLC) LN uses the onion routing method you described. The hash preimage is given to the recipient by the sender and that is transmitted to each node in the route so that they all have the hash preimage. Once both nodes in the channel have the hash preimage, they resolve the HTLC off chain. If some nodes are not able to transmit the hash preimage to settle the HTLC off chain, then the node that was able to settle with one peer but not the other can settle on-chain, and in doing so, reveals the hash preimage for the remaining nodes to settle (either on chain or off chain, as necessary). That node is incentivized to settle on chain because he would actually be losing money by not settling.

[Kogs]

That's not how payment routing actually works. That's just the messaging protocol to transmit some information between nodes.

The actual payment part works through Hashed Time Locked Contracts (HTLCs). So node A offers a HTLC output to node B. In order for node B to spend from that HTLC (thus being paid by node A), he needs to provide the preimage to some hash in addition to his own signature. After some timeout, node A can take the money back with a signature of his own.

In LN, the HTLCs are used to make the payments between the nodes. They use the same hash so they all have the same hash pre-image required. So if any one HTLC is spent, all HTLCs in the route can be spent since the hash pre-image is revealed during the spend. If the hash preimage is never revealed, then the coins are never sent to the other party. This makes it atomic.

As a shortcut (to avoid on chain transactions for each HTLC) LN uses the onion routing method you described. The hash preimage is given to the recipient by the sender and that is transmitted to each node in the route so that they all have the hash preimage. Once both nodes in the channel have the hash preimage, they resolve the HTLC off chain. If some nodes are not able to transmit the hash preimage to settle the HTLC off chain, then the node that was able to settle with one peer but not the other can settle on-chain, and in doing so, reveals the hash preimage for the remaining nodes to settle (either on chain or off chain, as necessary). That node is incentivized to settle on chain because he would actually be losing money by not settling.

Thank you for your great answer. This was the missing link I had.
It's now clear for me and I can dig deeper into the details of the lightning protocol/network.