(buzzwordatory:)the path finding gossip is not part of invoice exchange messages
(laymans speek:)finding routes is not part of payments
(buzzwordatory:)
pathfinding gossip uses
"node_announce" message which reveal which channels it owns.
type: 257 (node_announcement)
data:
[signature:signature]
[u16:flen]
[flen*byte:features]
[u32:timestamp]
[point:node_id]
[3*byte:rgb_color]
[32*byte:alias]
[u16:addrlen]
[addrlen*byte:addresses]
"channel_announce" which reveals the partners of the node
type: 256 (channel_announcement)
data:
[signature:node_signature_1]
[signature:node_signature_2]
[signature:bitcoin_signature_1]
[signature:bitcoin_signature_2]
[u16:len]
[len*byte:features]
[chain_hash:chain_hash]
[short_channel_id:short_channel_id]
[point:node_id_1]
[point:node_id_2]
[point:bitcoin_key_1]
[point:bitcoin_key_2]
"channel_update" which reveals the fee's of the channels
type: 258 (channel_update)
data:
[signature:signature]
[chain_hash:chain_hash]
[short_channel_id:short_channel_id]
[u32:timestamp]
[byte:message_flags]
[byte:channel_flags]
[u16:cltv_expiry_delta]
[u64:htlc_minimum_msat]
[u32:fee_base_msat]
[u32:fee_proportional_millionths]
[u64:htlc_maximum_msat] (option_channel_htlc_max)
htlc_maximum_msat is not the live available liquidity left. its the first 'state' value of the channel creation without revealing anything about liquidity/payments performed to adjust the balance available.
none of these three messages have anything to do with the payment. but everything to do with route discovery and choosing the cheapest route.
there are no payment fails at route discovery as no payment is 'locked' temporarily at route discovery
when building the route graphs its just a spam of "node_announce" and "channel_announce" and "channel_update" messages back and fourth. and the software then looks at the possible routes that lead to the desired node
(laymans speek:)
like building a map of a road network and finding out the toll fee's along certain roads
the software then makes a decision about which route has the cheapest total(combined) fee of the route.
your debug log has nothing to do with the process i have mentioned about about the path finding stage..
so lets now explain the nest stage.. (separately)
SEPARATELY AND SECONDARY
then it performs the invoice exchange telling the route how much the payer wants to push forward including a public key(htlc) that requires a secret.(buzzword: update_add_htlc)
then the channels along the route lock up the value into this public key and send back a funding_locked response to say their LN iou msat promises are set..
when the payer receives the "funding locked" response(in regards to the LN iou promises) meaning everyone else along the route has also had the same, its deemed a valid route to complete a payment. and the payer sends the "secret" and this pass the parcel forward until the destination gets it.
an error at this stage IS a payment fail
as for your other comments in your post:
do not confuse the 'payment' temporary iou promises of LN with the open/close channel contract of bitcoin format when you try to refer to your version of understanding of the use of "funding_locked"
the open/close session contracts measured in sat are a different format to the temporary LN payment locks measured in msat.
"funding_locked" is used by both the open/close contract... and the temporary LN iou promises. but dont pretend they are the same thing or that the LN payments dont do this because you only know about the bitcoin open/close contract part
I can tell when a payment fails due to no liquidity in one of my channels, but I can't tell the exact reason if the payment fails at some further point in the route.
i know you cant tell.. but one thing you should learn. and understand. is that the fail is not due to the route discovery/path finding gossip stage. and not due to a payer just not choosing you because your fees are too high
it is not the case of "payment failed because they simply chose a different route"
the LN pizza example in 2018 was not scenario of 150 pizza orders with a spam of 1500 'payments' that never complete.
FOLD actually said they had 1500 food orders through dominos portal. but only got 10% payment
meaning 1350 pizza's were not delivered to peoples mouths. who had made a pizza order.
they DID NOT have 150 domino's orders and 1350 spam payments (10x the payment attempts than domino order requests)
a payment failure is not due to:
not establishing a full route to destination (meaning those intermediaries, halfway through map get forgotten)
deciding to try route A (meaning B is declared fail due to simply not taking that route) for reasons of less hops
deciding to try route A (meaning B is declared fail due to simply not taking that route) for reasons of less fees
a payment failure is a fail due to:
delays in messages expiring
such as not sending the secret before htlc expiry
liquidity issues
such as the liquidity being 'spent' by other pending payments before the current payment completes
wallet errors
peer communication issues. loss of keys, going offline. bugs, faults with nodes, ddos