Quote from: Rath_ on Today at 05:49:33 PM

So, as per specifications, the data sent through ping/pong messages is just a bunch of zeros.

really??

Quote

Rationale

The largest possible message is 65535 bytes; thus, the maximum sensible byteslen is 65531 — in order to account for the type field (pong) and the byteslen itself. This allows a convenient cutoff for num_pong_bytes to indicate that no reply should be sent.

Connections between nodes within the network may be long lived, as payment channels have an indefinite lifetime. However, it's likely that no new data will be exchanged for a significant portion of a connection's lifetime. Also, on several platforms it's possible that Lightning clients will be put to sleep without prior warning. Hence, a distinct ping message is used, in order to probe for the liveness of the connection on the other side, as well as to keep the established connection active.

Additionally, the ability for a sender to request that the receiver send a response with a particular number of bytes enables nodes on the network to create synthetic traffic. Such traffic can be used to partially defend against packet and timing analysis — as nodes can fake the traffic patterns of typical exchanges without applying any true updates to their respective channels.

When combined with the onion routing protocol defined in BOLT #4, careful statistically driven synthetic traffic can serve to further bolster the privacy of participants within the network.

Limited precautions are recommended against ping flooding, however some latitude is given because of network delays. Note that there are other methods of incoming traffic flooding (e.g. sending odd unknown message types, or padding every message maximally).

Finally, the usage of periodic ping messages serves to promote frequent key rotations as specified within BOLT #8.

ping and pong can be sent:
1. randomly with any extra data that can be false so that it confuses others
2. with onion routing to have private updates, or (1) because just waiting for a official update can be
3. to do other things like changing keys

oh and you forgot the "extension" part of the message. yea, i see you just wanted to codebox the 'type/payload(data)'

Quote

As Z, you won't learn about the CW channel, but you can still learn about AB, BC, CD, DE from either W, who can learn about them from C, or from some outside node which had received a gossip message about any of those channels. W can safely forward gossip messages from C as those messages are exactly the same for every hop.

and if C is private. there wont be a BC or CD or CW on the DNS network bootstrap map..
instead of seeing a tree that links
ABCDE
ABCWXYZ
ZYXWCBA
ZYXWCDE

you would instead see
AB ZYXW

heres the funny part, there is no consensus in LN. so while you play games saying that the rules are strict and network compliant and everyone is forced,default public. where peopel cant just switch on and off their visibility. and where people cant negotiate payments away from YOUR version of pre organised payment setup from bootstrap data. there is no network wide audit, (well there wasnt and shouldnt.. though public loving person you are, you may want there to be. )

i guess you cant think of PR campaign to promote privacy, so you avoid wanting to discuss that its an option. and instead want to quote andreas saying things about how its default and forced to be public.

i still laugh that you think that it all has to be done via the payload of a update_add_htlc

again very strange tactic your playing