lightning-dev
asynchronous Lightning network payments
Posted on: October 29, 2019 21:20 UTC
Konstantin Ketterer proposes a solution to the problem of both parties needing to be online at the same time to send/receive money in Lightning Network.
The solution involves pre-signing a transaction by the payer A and sending it to payee B through an end-to-end encrypted communication channel, after which B can sell the signature to S using pay-for-signature made possible by payment points and scalars. The protocol uses eltoo for not having to worry about toxic channel states. The process enables asynchronous payments and outsources routing to S. However, there are potential issues with privacy, locked up capital, communication channels, and proof of payment. To solve the PoP problem, Konstantin suggests having S pay B with an AMP-like setup where they use the point B + xG on one payment where x is a nonce generated by S and the point B + sG + x*G on the other payment. The nonce, x, is revealed to the signature seller only when they receive both onions. When the payment completes, S learns b + x and b + x + s so that they can compute b = (b + x) - x and s = (b + x + s) - (b + x). s is the signature that they wanted and b is the PoP.In addition to splitting the payment between S and a public routing node P to increase privacy, the funds in the channel between A and S can be overwritten, and A can rebalance their channel A-S so that the outbound capacity - (amt + fees) in this channel is zero before going offline. There is also the option for A to instantly send B money while being offline, but A would be in charge of enforcing the channel state if S cheats.Overall, the protocol enables truly asynchronous Lightning network payments and is another reason to move to payment points and scalars. Konstantin's Github for the project is provided.