Author: Anthony Towns 2015-09-28 10:37:19
Published on: 2015-09-28T10:37:19+00:00
The email conversation in the context is centered around the routing and fees in a Lightning Network. The author suggests using parameters such as k and n that can be easily changed without affecting the network. They also propose a two-phase system for selecting and setting up new beacons to avoid the risk of losing money due to channel fraud. The author discusses the need for updating route info with fee changes and the importance of having smoothly transitioning parameters. Additionally, the potential challenges of microtransactions are discussed, and the importance of having enough investment to cover transactions is emphasized. Finally, the author proposes a delay of ten blocks before using a beacon to ensure that routes have been sufficiently established.The discussion further revolves around the viability of using beacon nodes, with some participants questioning its profitability, while others suggest that it's not worth running a node if you're not a beacon. One participant suggests that beacons are a clever idea, but won't actually work out at all. The issue of routing to donation addresses is also addressed, with suggestions of a best-effort DHT or probing the route with nanopayments.In addition, the layer system of the Lightning Network is discussed, with the routing being considered a layer up and effectively sort-of pluggable. The discussion also touches upon the need for real offline mode for standard wallets.Moreover, the context discusses the feasibility of using a phone as a replacement for cash and credit cards for everyday transactions. However, it is acknowledged that certain things cannot go offline, such as IoT devices doing micropayments ($1-$10), routers/cloud computers paying for their internet ($10-$100), merchants doing reasonable volume ($1000-$5000) and nodes operating as revenue-generating investments ($1000-$100,000).The privacy concerns regarding the use of Lightning primarily as a wallet versus trying to be a profit-generating node are also discussed. There is a discussion about fees eroding channels for nodes earning a return on investment and how node owners can avoid this by having the node pay from the node to a personal lightning wallet once a month. Finally, there is a discussion about the route beacon_X -> X -> Y -> Z and how a beacon could avoid this by partitioning its neighbors into two sets and setting incoming fees for one set prohibitively high and outgoing fees to the other set as prohibitively high. The number of connections a beacon might want and the potential impact on blockchain transactions are also considered.
Updated on: 2023-05-18T15:17:37.584163+00:00