You will again accuse me of playing grammar games, but it's not my fault that the specs are so strict.
I don't see any contradiction here. In order for the bolt01 message to be valid, you need to set a type which will be understood by your peer.
hmm really?
https://github.com/lightning/bolts/blob/master/01-messaging.md#lightning-message-formatThe type field indicates how to interpret the payload field. The format for each individual type is defined by a specification in this repository. The type follows the it's ok to be odd rule, so nodes MAY send odd-numbered types without ascertaining that the recipient understands it.
if you really want to play games that a node never sends onion routing messages or routing gossip messages without being encapsulated in a channel HTLC commit, you can play those games for decades. but you will just be playing with your group
i know your game is your narrative that the only messages sent are bolt 2 channel management messages.. but guess what. before a channel is even set up, node messages are asked to find out what type of chainhash and channels are available with a peers node. yep how can you assert that all messages are suppose to be encapsulated into a channel message if there is not yet a channel.
how can a peer encapsulate a onion message if it does not yet know which channel the partner wants to utilise for their forward to the next peer
nodes send messages outside of a blockchain formatted template of output+witness.
but hey. it might take you some time to read all of the bolts. , but dont reply if your just going to try to push conversations back into bolt 2.. (there are other bolts, with other messages, learn them)
so go play your backward-of-time-and-logic games elsewhere
i know your thinking alice can psychic predict that she needs to pay bob 1003 for a 1000pay to eric via hops through bob carol, diana.. so alice predictively commits to bob 1003 before even trying to find a route. or before alice even knowing carols, diana's fee.. or before even knowing if carol and diana have liquidity to pay to eric
but here is the thing. alice has to try a route to first know if one can be found, whether hops have liquidity to forward, and find out the total the fees actually are to then commit to bob
its not:
pay first via commit(update_htlc), find route second via channel messages of a signed blockchain transaction.
its is:
find route(node gossip), access fee's accept particular route(channel gossip). have destination accept. hops response back down the path... then commit
the messages of finding route and calculating fees are not in a channels blockchain formatted transaction template output(your update_HTLC understanding)
the dust fee, min fee and the other things are variables that can be looked at without having to change a blockchain formatted transaction templates output.
you dont need to sign blockchain formatted transactions just to see if a channel has liquidity, fee's or other channels with other peers
learn al the gossip messages and packet messages that dont involve updating a HTLC