EG your "update_add_htlc forces commitment update. thinking the only messages are update_add_htlc (again facepalm)
Thank you for finally admitting that "update_add_htlc" enforces commitment update.
[/quotes]
1. you mistook my saying of YOUR mindset that YOU still think update_add_htlc is a command to changes blockchain format transaction output (which i facepalmed)
2. ok so below is you again thinking everything is done by a network map everyone has publicly.. i did laugh, ill explain my laughter after the quotes
yep before alice even sends bob an (incoming to bob) alice needs to do stuff, which requires lots of messages
Alice doesn't need to send any messages as she should be able to extract all the information she needs from her local network graph.
an incoming HTLC. how is that formed(what data is inside this incoming htlc).
Again, all the data she needs to prepare "onion_routing_packet" should be obtainable from her local network graph.
As both of us are probably getting tired of the "contradiction game". I invite you to play the "quote game".
The gossip protocol:
The Lightning Network solves this problem by implementing a gossip protocol. Gossip protocols are typical for peer-to-peer (P2P) networks and allow nodes to share information with the whole network with just a few direct connections to peers. Lightning nodes open encrypted peer-to-peer connections to each other and share (gossip) information that they have received from other peers. As soon as a node wants to share some information, for example, about a newly created channel, it sends a message to all its peers. Upon receiving a message, a node decides if the received message was novel and, if so, forwards the information to its peers. In this way, if the peer-to-peer network is well connected, all new information that is necessary for the operation of the network will eventually be propagated to all other peers.
The construction of a channel graph is not a one-time event, but rather an ongoing activity. As a node bootstraps into the network it will start receiving "gossip," in the form of the three update messages. It will use these messages to immediately start building a validated channel graph.
The more information a node receives, the better its "map" of the Lightning Network becomes and the more effective it can be at pathfinding and payment delivery.
So, you actually don't need any channel peers to start syncing the graph which contradicts your view:
..
try not to imagine the utopia of a central mempool(DNS server) for all nodes to access, showing all nodes channels of the whole network. and instead imagine each node with its own mempool
you do realise that there are many messages that happen separate to the initial sync map build.. right?