Published on: 2019-09-18T10:30:57+00:00
In a recent discussion, Hiroki Gondo proposes using HTLC variants that are not compatible with BOLT 1.x HTLCs to achieve Stuckless Payments. By modifying the BOLT #3 offered and received HTLC policies, the changes allow for the implementation of Stuckless Payments without relying on PTLCs. However, ZmnSCPxj and Bastien raise concerns about security and privacy issues related to the proposal. They agree that it is important to retain the property of "D does not know payer A". The addition of a new ACK-key turnaround may enable intermediate nodes to guess the payer's identity by measuring the time from sending the ACK to receiving the key.To address this concern, Hiroki suggests embedding an ACK onion packet inside the last hop payload of the add_htlc onion packet. This would prevent D and intermediate nodes from learning anything about the payer. Hiroki plans to further understand the limitations of the onion packet and consider combining this proposal with AMP and new routing algorithms such as Trampoline and Rendezvous.The email conversation also discusses a potential solution to the "American Call Option" problem in stuckless payments. The proposed solution involves requiring immediate payment of the premium by the exchange, with the premium encumbered only by the exchange. Steps involved in the payment process include requesting a public key anonymously via Tor, routing the payment via the exchange, providing proof-of-knowledge, and using signatures to validate transactions. The payer and payee can still lock the exchange funds by not paying the option premium, but the exchange has the ability to permanently delete the funds if they are not paid. Additionally, instead of sending the key in response to ACK, the payer can send a cancel message.Another topic discussed on the Lightning-dev mailing list is the proposal to add an additional round of communication to avoid wormhole attacks and decorrelate payments. While this would increase latency, it would provide a way to "cancel" stuck payments and retry them. The option to make multiple tries in parallel is also considered to help with latency. Payer anonymity is addressed by suggesting that the ACK message can be constructed by A and sent via a different route than the add_htlc onion packet.In a message to Hiroki, ZmnSCPxj suggests sending the payment decorrelation sums in onion packets in a new phase called Pre-Settlement. However, adding the ACK-key turnaround may allow intermediate nodes to guess the payer's distance. There is uncertainty about how to weigh this information as it may lead to attempts at censorship. Additionally, the added latency of payments may worsen with the use of ACK-key turnaround despite the possibility of multiple tries in parallel. Further consideration is needed to ensure correctness.The proposal aims to reduce the occurrence of stuck payments by allowing both the payee and the payer to provide keys to settle payments without involving intermediate nodes. However, it is important to note that this proposal cannot be used with BOLT 1.x and will only apply to future specifications. In cases where payments do get stuck, additional trusted operations will be required by the final node's implementation, application, or service operator. For example, if a payment gets stuck when a payer orders a cup of coffee and attempts to pay for the invoice, corrective actions need to be taken to resolve the issue. Retry attempts using different routes with the same invoice present problems as the payer may end up paying twice for the same invoice if the previously stuck payment succeeds after a successful retry. Obtaining a refund from the payee for the extra payment would require additional trusted operations dependent on the application or service operator.
Updated on: 2023-07-31T21:44:19.913124+00:00