Quote from: Rath_ on Today at 05:17:10 PM

Quote from: franky1 on Today at 03:49:45 PM

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

Quote from: Rath_ on Today at 05:17:10 PM

Quote from: franky1 on Today at 03:49:45 PM

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.

Quote from: franky1 on Today at 03:49:45 PM

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:

Quote from: https://github.com/lnbook/lnbook/blob/develop/11_gossip_channel_graph.asciidoc

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.

Quote from: https://github.com/lnbook/lnbook/blob/develop/11_gossip_channel_graph.asciidoc

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:

Quote

the more information a node receives, the better its "map" becomes and more effective it can be

share (gossip) information that they have received from other peers.

the construction of a channel graph is not a one_time event but rather an ongoing activity

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.

notice all the wants, decides, if's, cans..
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 of only data it can see from its peers which its peers has allowed it to get

you do realise that there are many messages that happen separate to the initial sync map build.. right?