Published on: 2018-05-23T07:41:25+00:00
In a discussion on the Lightning-dev mailing list, the topic of onion peeling in the Lightning Network was raised. It was mentioned that onion unpeeling did not make it into the BOLT spec due to issues with it. The purpose of unpeeling the onion was to identify slow nodes. The discussion also touched on proving channel closure if onion unpeeling is not possible, which would result in a penalty for the unresponsive party.The conversation then shifted to the relationship between reputation and `reputation_loss_rate` in HTLC. Reputation score was described as a private per-node thing, while `reputation_loss_rate` is explicit in the HTLC. It was suggested that reputation loss should be proportional to the value assigned to it by the owners of the funds. Graphing reputation loss along the line as N increases forms a triangle, where the area of the triangle represents the total reputation destroyed. Only one edge of the triangle is lost by the Node18->Mallory3 reputation score.The behavior of reputation in case of successful and failed payments was discussed. In the case of successful payments, the upstream peer's reputation is increased by the fee earned, while the downstream peer's reputation is decreased by T times the reputation_loss_rate. If the payment fails after T time, the downstream peer's reputation is decreased by T times the reputation_loss_rate, but the upstream peer's reputation remains unchanged.The discussion further delved into reputation manipulation and the misalignment of user and node incentives in a decentralized system. It was suggested that pricing resource utilization appropriately could defend against attacks and protect routers. The reputation system was proposed as a means of achieving this. Each node would have a local configuration of its "reputation loss rate" per channel, and a reputation score would be kept for each peer node. Fees collected from completed payments would be added to the reputation score, while the reputation loss rate on offered HTLCs times their elapsed time would be subtracted from the reputation score for each payment where the node is the downstream hop.The trade-off between network efficiency and privacy was also discussed. It was argued that a reputation system could help protect against DoS attacks but may sacrifice privacy and create new vectors for deanonymizing the network. The need for a real design of the reputation system and a careful evaluation of its impact on neighborliness were emphasized.In an email conversation, concerns were raised about the complexity and communication overhead of penalizing parties for delaying HTLCs beyond a certain threshold. A reputation system was suggested as a better option, giving more discretion to the preceding hop. However, it was pointed out that a reputation system misaligns user and node incentives and can centralize the network. The idea of keeping a reputation score for each node to ensure high-quality links in the network was proposed, but concerns about deanonymization and new attack vectors were raised. The discussion concluded with the need for a well-designed reputation system and a thorough evaluation of its impact on neighborliness.In another email exchange, the concept of directing normal traffic in a payment routing system was discussed. It was clarified that the sender constructs the circuit, so routing nodes have limited choice in which nodes to forward payments to. An attacker could perform a loop attack by sending a payment to another node they control and delaying the payment on the receiving end. However, the reputation protocol should properly penalize the receiving node's reputation, making it unlikely for the attack to succeed in subsequent attempts. The issue of asymmetrical resources and the potential for malevolent nodes to direct normal traffic to sacrificial nodes they control was also raised, highlighting the need for careful consideration of reputation-risk reporting.The email thread revolves around the issue of information leakage and reputation loss in the Lightning Network. One proposal suggests randomizing the reputation-loss-rate to obfuscate intermediate node distance, but it is pointed out that this leaks both distances simultaneously, which is worse than leaking just one distance. Another proposal involves CLTV-delay randomization for payments, but there are concerns that CLTV values already partly leak the distance from the payee.The discussion also focuses on the advantages of implementing a reputation system, which gives more discretion to the preceding hop and helps keep all links in the network high quality. Nodes earn reputation scores over time and are quickly disconnected from delaying nodes if the incentives are right. However, there are concerns about certain models tried in Milan that created an incentive to fail payments. It is argued that even if routing nodes receive a nominal spam fee for failed payments, they still have more to gain by forwarding the payment and earning the full fee on a completed payment.The email thread also discusses the amount of information leaked and the drawbacks of aggregating losses along the route, as it allows estimation of the sender's distance from the ultimate sender of the funds.Another aspect of the discussion centers around the proposed reputation system for the Lightning Network. The proposed system aims to prevent opportunistic attackers from delaying payments.
Updated on: 2023-07-31T20:15:57.540062+00:00