Published on: 2016-04-13T00:36:19+00:00
Anton is seeking clarification on how routing data works in the Lightning Network, particularly regarding making an initial payment request. He provides an example of running a Lightning node on his phone and someone only knowing his bitcoin-pubkey-style ID. Rusty suggests using QR codes or other means to provide the necessary information for payment requests. It is mentioned that general messages over the network will not be routed in the short term. There is also a mention of a long-term solution involving a deterministic method to determine which node should connect to a user's ID.Concerns are raised about DDoS attacks, where someone could spam a Lightning device with millions of payment requests. Rusty agrees that this could be a problem and suggests mitigating the attacks through request rationing using blind signatures. However, he is unsure how to enforce this on a distributed network.The email thread discusses various aspects of how routing data works in the Lightning Network. One suggestion is for devices to establish a socket connection to landmark nodes. However, this approach may overwhelm both devices and landmark nodes. Another possibility is a deterministic method that determines the exact node a user's ID should connect to, which would help distribute the load across the network.DDoS attacks are a concern, and Rusty proposes a solution where nodes have an ID and publish their public routes by proving ownership of anchor transactions for their channels. Information on routes to and from landmarks is stored by every node. To accept a payment, the receiver must provide a unique hash of R-value, an amount, and route information from a landmark to themselves. The thread also touches on the need for stable identities on devices, encryption for transferring core data, and the potential for a service parallel to LN that can transfer core data in encrypted form.Anton expresses interest in adding Lightning Network to his Bitcoin wallet and asks about its functionality for end-users. Rusty explains that a payment sender needs the R-hash and one or more routes to interact with LN. Nodes have an ID that is a bitcoin-style pubkey, and they publish their public routes by proving ownership of anchor transactions for their channels. A new set of landmarks is selected every 24 hours using the bitcoin block hash, and nodes store information on routes to and from these landmarks. To accept a payment, the receiver must provide a unique hash of R-value, an amount, and route information from a landmark to themselves. The sender's location remains unknown to the receiver.Additional requirements are discussed, such as the need for "core" data to come directly from the receiver's device and resistance to MITM attacks and identity theft. Rusty suggests that users should generate stable identities on their devices using EC25519 keys due to their small size and applicability for encryption and signing. A service parallel to LN is proposed to transfer core data in encrypted form and potentially act as a third-party watcher for commitment transactions and a "name authority" for users who provide metadata along with their public keys. Offline receive is considered challenging and not planned for the 1.0 specification.In conclusion, the author expresses their ideas and asks if they make sense or if there are any areas where they may be off.
Updated on: 2023-07-31T18:56:53.603636+00:00