Published on: 2021-12-27T19:12:10+00:00
In a recent email discussion, Matt Corallo and Rusty Russell discussed the challenges of sending invoices using bolt12. One issue that came up was the inability to preprint amountless invoices because each invoice must contain an amount. To address this problem, they proposed a generic authorization mechanism with a fallback node. This method allows users to choose the trust model they prefer.Matt Corallo also suggested using PTLCs (Probabilistic Time-Locked Contracts) to solve the problem of correlation in onion routing. He proposed adding a random nonce to each PTLC payment to enhance security. However, he also mentioned the unique tweaks derived from the onion share secret in bolt12, which need to be addressed.The Lightning Network community is actively discussing proposals to improve payment security while maintaining non-custodial payments. One proposal involves using onion messages and notifications to build a better solution than holding HTLCs at the recipient's LSP. It was noted that both senders and recipients need to be online during the payment settlement period to avoid losing channels. Suggestions were made to have a longer timeout and to use two hashes instead of one for every HTLC. However, it was agreed that adapting every node in the path for these changes might be complex, making PTLCs a simpler and more practical solution.In an email conversation between Bastien and ZmnSCPxj, they discussed an improvement to HTLCs for payments on the Lightning Network. Bastien liked the idea of using onion messages with notifications to get recipients online quickly. ZmnSCPxj suggested using two hashes instead of one for every HTLC, providing similar protection as the `payment_secret` in invoices. However, they agreed that implementing this change in every node along the path might be challenging, making PTLCs a more feasible option.ZmnSCPxj recommended using PTLCs as a solution to prevent collusion between the sender and lnurl endpoint in stealing funds. He proposed adding a random nonce to each payment to make it difficult for anyone to steal the funds. However, he also sought suggestions apart from PTLCs. Another suggestion made by ZmnSCPxj was using two hashes in an HTLC, with the second hash generated by the sender. This would provide protection against forwarding nodes probing.In an email exchange between ZmnSCPxj and Matt, ZmnSCPxj suggested using two hashes instead of one in HTLCs to enhance security on the Lightning Network. The second hash would be generated by the sender and sent encrypted via onion to the receiver. However, both parties agreed that implementing this change in every node along the path would require significant adaptation, making PTLCs a simpler solution. Nonetheless, ZmnSCPxj recommended incorporating PTLCs for all payments and suggested adding a random nonce * G to further enhance security.Andrés G. Aragoneses asked Matt to clarify a paragraph regarding accepting lightning payments on mobile devices. Matt explained the issue of users needing to have their lightning app open and in the foreground to receive payments. Existing solutions attempt to solve this problem with limited CPU time allocated to notifications, but there's no guarantee of availability on Android and iOS platforms. Matt acknowledged that relying on users to open the app immediately upon receiving a notification is not ideal, and a better solution is needed.The email thread discusses the challenges of coordinating lightning payments between mobile users. Various solutions have been proposed, including using lnurl and PTLCs to prevent collusion and allow for secure payments without requiring constant app presence. However, feedback and proposals are still being received to improve these solutions.Overall, the Lightning Network community is actively exploring ways to enhance payment security while maintaining non-custodial payments. The use of onion messages, notifications, PTLCs, and multiple hashes in HTLCs are among the proposed solutions to address various challenges and improve the Lightning Network's functionality.
Updated on: 2023-07-31T23:53:18.571885+00:00