Direct Message draft



Summary:

The Lightning Network is a popular topic of discussion among developers, with various proposals being put forward to address potential issues. One contributor raises concerns about timing attacks that could allow an intermediate node to guess how far away another node is. To prevent this, the proposal suggests using different paths if direct messages are part of a larger conversation between two parties.Another suggestion is to create a circular path where Alice constructs an onion that creates a path from herself to Bob and back, ensuring different nodes on the forward and return directions. If a node in the circular path drops, the circuit is disrupted, so any higher-level protocols on top of that should be willing to resume the conversation on another circular circuit.The Lightning Network is not just for invoice requests, and messaging over lightning is suggested as an obvious candidate for much more. However, directed messages are unreliable and designed to be cheap and not need to be committed to a database. Each message has an optional reply, which is onion-encoded just like HTLC errors. Directed messages use BOLT 4 protocol for end-to-end encryption, but they are not associated with a particular local channel.The Lightning-dev mailing list recently discussed the need to define a reasonable timeout for forgetting updates that have not received a reply, similar to update_add_htlc and update_fail_htlc. The discussion also references RFC 1950, which specifies the ZLIB compressed data format version 3.3.


Updated on: 2023-06-02T23:48:55.912225+00:00