but it is funny how you are using bolt2 (Peer Protocol for Channel Management).
and avoiding yet again:
bolt4: (Onion Routing Protocol)
bolt11 (Invoice Protocol for Lightning Payments)
Let me repeat again. bolt11 describes only how a payment invoice should be encoded/decoded. As for the bolt4:
This document describes the construction of an onion routed packet that is used to route a payment from an origin node to a final node.
bolt4 describes how the onion packet is constructed and how it can be validated by each node. It does not describe how it is passed around. Here's a piece of information from bolt2:
The format of the onion_routing_packet portion, which indicates where the payment is destined, is described in BOLT #4.
type: 128 (update_add_htlc)
data:
[channel_id:channel_id]
[u64:id]
[u64:amount_msat]
[sha256:payment_hash]
[u32:cltv_expiry]
[1366*byte:onion_routing_packet]
The "onion_routing_packet", which contains encrypted instructions for each hop, is a part of "update_add_htlc". So, Carol doesn't know anything about Diana unless Bob sends her "update_add_htlc". Bob can't send it unless Alice replies with "commitment_signed" and they finish exchanging revocation keys. Why? Again:
Forwarding HTLCs
Requirements
A node:
until an incoming HTLC has been irrevocably committed:
MUST NOT offer the corresponding outgoing HTLC (update_add_htlc) in response to that incoming HTLC.
If you still disagree, tell me what kind of message nodes use to forward the "onion_routing_packet" without triggering the update of the commitment transaction.
the millisat payment comes first. and is then rounded up/down into sat commitment as a second part
That's exactly what I have said in my previous post:
The receiving node routes down the value to whole satoshis before preparing and signing the commitment transaction. The sending node does the same for their version of the commitment transaction. If either of them doesn't do that, the HTLC can be failed.
payment_hash (same for all parties involved in a route).. and its payment _secret (same for all parties of a route) is for the msat payment.
separetly the localpubkey remotepubkey(just between channel peers) and revoke keys(just between channel peers) are buzzwords for the channel commitment
Payment secret and payment hash are also used in the locking script of the HTLC output in the commitment transaction.
payments are done as a separate HTLC(in msat) and once E has received the payment_hash from D, who got it from C, who got it from B who got it from A(who got it from E). then E knows to send payment_secret to D, who passes to C, who passes to B who passes to A. and then A and B make the commitment where B is deserved the value
You still haven't answered my question. How do all of these nodes communicate? How do they forward the onion packet?
Is there anyone here who is following our discussion?