I see that you have completely ignored my answers and remarks to your statements, again. Never mind.

You seem to forget that "update_add_htlc", which forces commitment update, always includes "onion_routing_packet" which contains routing instructions. That's how both peers know how to update the channel.

Actually, you can tell if Eric is online from the network gossip. Either of the peers can disable their side of the channel through "channel_update" and that's what all implementations do if their peer goes offline. Disabled channels are ignored during payment path construction. Carol doesn't need to know if Eric is online as she interacts only with Bob and Diana. If Carol or any other hop beside Alice knew that Eric is the final destination, it would be a huge privacy concern.

I have never said that the gossip protocol (bolt07) is used to reply whether or not there is enough liquidity in the channel to forward the payment. You keep saying that you need to send bolt04 payloads in a bolt01 format, but I have already proved you in my previous post that bolt04 error messages need to be associated with HTLCs from bolt02.


The only HTLC related messages that can return bolt04 errors are "update_fail_malformed_htlc" and "update_fail_htlc". Your peer cannot send them unless there is an HTLC commited to the channel ("update_add_htlc" + "commitment_signed" + revocation keys exchange).

---

Here's your view as far as I understand:

1) Alice constructs a path based on the information from her map. If she doesn't have some information about specific node, she requests it through the gossip protocol.
2) Alice sends just "onion_routing_packet" in a bolt01 format to learn if all nodes in the route have enough liquidity.
3) Each node in the path forwards that packet in the same way
4) Once the packet reaches Eric, he replies whether or not he can accept the payment.
5) All hops reply to their partners in the backwards order.
6) [Here should be the commitment part, but I have no idea how you want to handle it with a different secret for each hop and trustlessly without HTLC outputs in the commitment transaction]

My comments:

I have already shared most of my concerns before. I still don't know what message each node would use to say "I can forward your payment". I also didn't mention HTLC outputs here as you clearly ignore that they exist or say that they could be claimed with just payment secret, which is not true. Without them, if Eric claims the payment in his channel with Diana and Carol disappears, Diana can't claim the coins she was promised as the promise was not enforceable in any way.

---

Here's my current understanding of how the system works:

0) Lightning nodes constantly use the gossip protocol (bolt07) to forward/receive "node_announcement", "channel_announcement", "channel_update" messages and maintain a local view of the whole network.
1) Alice receives a payment invoice from Eric which includes information like: Eric node's public key, payment hash, amount, expiry (date) and cltv expiry.
2) Alice constructs a path to Eric using her local map of the network. She tries to find the cheapest and the shortest route. The longer the route, the higher the risk that funds will get stuck during routing.
2a) She prepares "onion_routing_packet" which includes encrypted routing information for each hop.
3) Alice sends "update_add_htlc" message to Bob, which includes the "onion_routing_packet" (which is the same for all peers), the amount, the payment hash and cltv expiry.
4) Alice and Bob sign a new commitment transaction with an HTLC output.
5) Bob sends "update_add_htlc" to Carol with the same "onion_routing_packet".
6) Carol and Diana, Diana and Eric do the same.
7) Eric sends "update_fullfil_htlc" message to Diana, which includes the payment secret.
8) Eric and Diana remove the HTLC output and update balances by signing a new commitment transaction.
9) Diana sends "update_fullfil_htlc" to Carol with the same payment secret and they update the commitment transaction.
10) Carol and Bob, Bob and Alice do the same.

Comments:

3) The amount Alice sends is actually bigger than the one in the invoice as she must account for the fees. Each hop forwards the HTLC with a smaller amount and keeps the difference. If some hop tries to claim higher fees than Alice expected, the next node in the route will fail the payment as the routing instructions say how much one's node is supposed to forward.

If Bob doesn't have enough coins to forward the payment on his side of the channel with Carol, he must send "update_fail_htlc" message and Alice needs to try sending the payment through another route.

All channels use the same payment hash. It is safe because HTLC outputs require both the payment secret and HTLC signatures, which can be produced only by channel partners, to be spent. See this post for explanation.


I can back up my statements by showing you my node's logs and quoting research papers and other resources, but you will totally ignore them as always.