rath's narrative was that LN payments were done not by messages of Msat data but by actually editing outputs in a blockchain format transaction template and signing them. and then sending thoses signed transactions to the peeres to sign and complete the payment.
..
his more recent and changed view now atleast admits there are messages. and those messages have things in them but he still misses some things
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.
Cool 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.
in (2) he thinks that alice constructs a path just from network gossip. and tries the cheapest route to bob,
and then (3) signs a commitment to bob..
but here is the thing.
again using the example (its only a 1 hop instead of 3 hop to avoid lengthy example)
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#routing-examplealice wants to pay Carol 499999 based on carols details
amount_msat: 4999999
cltv_expiry: current-block-height + 9
onion_routing_packet:
amt_to_forward = 4999999
outgoing_cltv_value = current-block-height + 9
but if alice paid bob to pay carol. bob would not get a fee. and also bob has his own defauly CLTV of 9 meaning carols cant begin because bobs has the 9
so instead alice has to request some update messages where by bob and carol talk. and alice gets an update of
amount_msat: 5010198
cltv_expiry: current-block-height + 20 + 9 + 42
onion_routing_packet:
amt_to_forward = 4999999
outgoing_cltv_value = current-block-height + 9 + 42
as you can see the fee and calculated amount_msat and the cltv have changed based on the numbers that need to change to fulfill the route..
this is only done via alice talking to bob talking to carol and carol talking back to bob who talks back to alice.
this is not all just found at the network map on initial opening of an app.
it is only then that alice knows it will cost her 5010198msat to pay carol 4999999
by which alice can try to see the amount of other routes.. and then choose the route to actually take.
and then on taking the actual route then comit to the channel of that route direction
again for emphasis. because network map does not hold all info. such as CLTV amount_msat of active available balance, nor any other personal parameters like adding a bit of shade to each CLTV. making each one unique.
you cant just create a route in A using just A network map and just commit to bob. for an amount A guessed based solely on the network map
there are reasons why onion messages are a thing. and its not to transmit signed commitments