Quote from: franky1 on Today at 01:29:42 PM

wait. but for a few posts you have been saying everyone knows everything... and now you admit that alice would have no way of knowing about eric via the network map..

Nice try franky1. A few posts ago you were not talking about private channels at all, so I assumed that all channels are public, which is the most common case. You are trying to prove me wrong by changing your assumptions. That's no bueno, my dear.

Quote from: franky1 on Today at 01:29:42 PM

thank you for admitting its not about commitment signing and is about sending messages (messages denominated in msat)

Read my reply again.

Quote from: Rath_ on Today at 10:07:30 AM

No one is relaying signed transactions. Commitment updates are local. Nodes relay instructions which tell them how they should update their local transactions.

From the very beginning, I have been saying that you need to send "update_add_htlc" message which includes those instructions AND forces commitment update as per bolt02:

Code: (https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#forwarding-htlcs)

Forwarding HTLCs
*until an incoming HTLC has been irrevocably committed:
MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.

Quote from: franky1 on Today at 01:29:42 PM

a node only knows of the map of its peers, peers

You seem to forget that Lightning explorers, which obtain data through the gossip protocol, exist. All Lightning nodes should have exactly the same information as those explorers.

Quote from: franky1 on Today at 01:29:42 PM

channel updates are not forced to only happen at 3 times:(your view)
network map initialisation
invoice send
commitment signed

No, my view is that "channel_update" is sent whenever some node makes changes to some channel's parameters (most commonly the fees). You don't need to send "channel_update" when you give someone an invoice or when you sign a new commitment transaction with someone. You can also send "channel_update" when your peer goes offline so that no one tries to route a payment through this channel. In other words, you can disable the channel.

Quote from: franky1 on Today at 01:29:42 PM

EG if alice is preparing to pay carol using say map or invoice. but during that preparation crol wants to pay her partner zoe, carol then has to change stuff.
EG if while alice is preparing to pay carol. bob(for his own reason separately) pays someone else for something else. he too has to change something.

Change what exactly? If liquidity is not public then there is nothing to change in this case through "channel_update".

Quote from: franky1 on Today at 01:29:42 PM

EG if alice is preparing to pay diana, where diana sent an invoice with a hint path through CBA at each transaction BCE can change their cltv per transaction to add some privacy. meaning random numbers change every few seconds and updates occur

You don't need to spam the network with "channel_update" messages. Here's an easier way to improve one's privacy:

Quote from: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message

If a route is computed by simply routing to the intended recipient and summing the cltv_expiry_deltas, then it's possible for intermediate nodes to guess their position in the route. Knowing the CLTV of the HTLC, the surrounding network topology, and the cltv_expiry_deltas gives an attacker a way to guess the intended recipient. Therefore, it's highly desirable to add a random offset to the CLTV that the intended recipient will receive, which bumps all CLTVs along the route.

Quote from: franky1 on Today at 01:29:42 PM

its a pass the parcel game.. not everyone connects to everyone randomly [...]
again in the pass the parcel game. your not connecting to all nodes and interrogate their channels. your being passed parcels from a peer who gets data from a peer thats allowing said data to be passed or not [...]
the channel announcements are not broadcast to all nodes.. all nodes are not connected to all nodes.

You need to read bolt07 more carefully:

Quote from: https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message

BOLT #7: P2P Node and Channel Discovery

This specification describes simple node discovery, channel discovery, and channel update mechanisms that do not rely on a third-party to disseminate the information.
Node and channel discovery serve two different purposes:

Node discovery allows nodes to broadcast their ID, host, and port, so that other nodes can open connections and establish payment channels with them.
Channel discovery allows the creation and maintenance of a local view of the network's topology, so that a node can discover routes to desired destinations.
To support channel and node discovery, three gossip messages are supported:

For node discovery, peers exchange node_announcement messages, which supply additional information about the nodes. There may be multiple node_announcement messages, in order to update the node information.

For channel discovery, peers in the network exchange channel_announcement messages containing information regarding new channels between the two nodes. They can also exchange channel_update messages, which update information about a channel. There can only be one valid channel_announcement for any channel, but at least two channel_update messages are expected.

If you suddenly stop liking bolt07, here's bolt00:

Quote from: https://github.com/lightning/bolts/blob/master/00-introduction.md

To make a payment, a participant needs to know what channels it can send through. Participants tell each other about channel and node creation, and updates.

See BOLT #7: P2P Node and Channel Discovery for details on the communication protocol, and BOLT #10: DNS Bootstrap and Assisted Node Location for initial network bootstrap.

Quote from: franky1 on Today at 01:29:42 PM

bob however is ok with being public to carol. so bob knows of alice. and carol knows alice-bob and carol is ok to send to diana and diana sends to eric. meaning eric knows of alice route. but eric is not node peer handshaked to alice to tell alice

No, Eric still doesn't know anything the BC channel. Neither Alice's nor Diana's network map contain any information about the BC channel. The same goes for Eric. You can't make only one side of the channel private; the whole channel must be private.

Quote from: franky1 on Today at 01:29:42 PM

when routes are built alice needs to know the latest total of msat and the cltv of the entire route. which can change from the app opening initialising network map view. and change from the invoice sent 5 minutes ago. because bobs circumstance has changed in the last 2 minutes

If that happens then the payment attempt simply fails. Channels don't change their parameters frequently anyway.