Published on: 2019-07-16T03:26:57+00:00
In an email addressing BOLT developers, Rene Pickhardt proposed improvements for the Lightning Network protocol. The first idea involved splitting a regular payment into multiple paths using a sha-chain of preimages and payment hashes. This would allow payments to be divided between recipients. However, this method lacked atomic proof-of-payment. To solve this problem, Pickhardt suggested that the payee create multiple sha-chains of payment hashes. Despite this improvement, there was still a privacy issue where a payee could receive only a fraction of all payments and stop collaborating. To address this, an invoice would have to specify the actions to be taken in exchange for payment.Another proposal mentioned in the email was the use of XOR on preimages with a sequence number or unique number. This would make it more difficult for attackers to correlate consecutive payments. However, this method was not atomic and therefore could not function as a trustless payment system. The email also suggested extending this proposed protocol for streaming live data. However, it was noted that there may be significant congestion on the Lightning Network due to the high rate of payments. In such cases, congestion and flow control protocols were deemed more appropriate.The email also discussed a congestion and flow control mechanism proposed by Pickhardt to enhance the speed and reliability of multi-path routing schemes on the Lightning Network. Currently, there is an issue of stuck payments on the network, particularly when Atomic Multi Path routing is used. This means that all payments and HTLCs of a multipath payment will only be settled once enough incoming HTLCs arrive at the recipient. A malicious actor can disrupt the entire payment process, and the duration of the payment process depends on the maximum time needed among all payments.To tackle this problem, Pickhardt looked at the windowing mechanism used in TCP and applied it to the Lightning Network. He proposed a base version protocol where a regular payment on the Lightning Network has a Payment Hash and a preimage. If a recipient agrees to split the payment over multiple paths, they would create a sha-chain of preimages and payment hashes. However, sequential payments would further prolong the process since it is not just the maximum time needed among all payments, but the sum of times needed.To resolve this issue, Pickhardt suggested introducing flow control using a windowing mechanism and allowing concurrency of partial payments. In this suggested version, assuming the receiving node supports a certain number of concurrent payments, the payee would create multiple sha-chains of payment hashes. This mechanism allows for the delivery of partial payments as long as fewer than the specified number of payments are stuck. Additionally, Pickhardt proposed privacy improvements such as using xor on preimages with a sequence number to make it harder for attackers to correlate consecutive payments and introducing path decorrelation when reusing paths for partial payments.The sender would need to keep track of successfully sent payments and those in transition or stuck, while the receiver would need to store more data in memory. Pickhardt concluded that with the introduction of two new fields in BOLT 11 invoices and simple code changes for invoice creation and preimage releasing, the proposed mechanism could be extended for a streaming payments protocol. He believed that this mechanism could reduce network load, and a few stuck payments could be considered as the "cost" of operation.
Updated on: 2023-07-31T21:49:10.883001+00:00