Re: [Lightning-dev] asynchronous Lightning network payments

[Yaacov Akiba Slama]

Hello Konstantin, In asynchronous payments we want to be sure that there are only two states: 1) Before B received the payment. 2) After B received the payment. In state 1), we want A to still have the control of the amount, and at the same time we want to let B decide (until a certain timeout) to receive the payment. In this state, S can only help B to be paid, or cancel the whole transfer, but in this case, A cannot lose the amount. In state 2), we want to be sure that no money is lost by S (and consequently that the amount in A wallet is decremented by amt). As ZmnSCPxj wrote in https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002260.html (as I understand the last sentences), there is no way to do that without locking the amount. In order to increase the privacy, we are improving the specification to be be able to use several Rod nodes: a list of nodes chosen by the payer and another list by the payee. The Rod nodes are supposed to be almost always online, so standard https can be used to communicate with them and between them. --yas On 29/10/2019 22:46, Konstantin Ketterer wrote: ## Problem Currently, both parties have to be online at the same time to send/ receive money. This can be avoided by using something like the Lightning Rod Protocol by Breez (https://github.com/breez/LightningRod). However, funds have to be locked up longer than usual. We can do better than that. ## Solution The payer A pre-signs a transaction handing over money to their local channel partner S and sends the transaction to the payee B in an end to end encrypted communication channel. B can then sell the signature for the transaction to S using pay-for-signature made possible by payment points and scalars. (https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002077.html) We will be using eltoo because we don't have to worry about toxic channel states. A and S are online, A and S have a channel 1. A contacts S: they commit and exchange the R (= k*G) part of the Schnorr Signature for the update and settlement transaction 2. A and S sign the settlement transaction increasing the balance between them by amt + fee in favor of S and exchange the signatures 3. A signs the corresponding update transaction but does not give it so S 4. A sends the update transaction to B using an end to end encrypted asynchronous communication channel A can go offline B comes online 4. Decrypts the update transaction and sells the signature s to S for amt When A comes back online S gives A the invoice (with the payment point s*G) signed by B, the corresponding scalar s (the signature from A for the update transaction) and signature from S for the update transaction. They can now proceed as normal. In addition to enabling asynchronous payments, this outsources the routing to S. ### Potential issues #### Privacy S currently knows both the sender and the receiver of the payment. If we split the payment from S to B into two payments between S and a public routing node P and P and B by still using the same scalar + payment point, S now only knows the sender and P only knows the receiver. To further increase privacy we can split the payment multiple times but all nodes involved must support this feature. #### Locked up capital While B hasn't yet claimed its money, the funds in the channel between A and S are essentially locked up. However, A and S could simply overwrite the payment (new update + settlement transaction), then A could send multiple payments with the remaining balance and before going offline A would do the procedure again. If A has sufficient inbound capacity in other channels it can also re-balance its channel A-S so that the outbound capacity - (amt + fees) in this channel is zero and then do the procedure. #### Communication channel Obviously, the communication channel must be end to end encrypted otherwise this is highly insecure. Hopefully, we will have a sort of decentralized paid mail server system which is compatible across all LN wallets and part of BOLT. #### Proof of payment The invoice by B with the payment point s*G and s are not sufficient as a PoP because S can simply give A the invoice and A already knows s. ## the other way around We can also do it in a way that A can instantly send B (who is offline) money but now A is in charge of enforcing the channel state if S cheats. Because it has more issues like who pays the transaction fees if S cheats and because I believe Lightning is generally not designed for people who are offline for a long time I prefer the first one. But here is the other one: B and S are online, B and S have a channel 1. B and S sign a new settlement transaction increasing balance in favor of B by amt 2. B signs the corresponding update transaction, encrypts it and sends it together with the settlement transaction to A B can go offline A comes online 3. A decrypts the transactions, A pays S to sign the update transaction which makes this new channel state valid/ enforceable 4. now A essentially acts like a watchtower while B is offline ## Conclusion This enables truly asynchronous Lightning network payments and is yet another reason to move to payment points and scalars. Regards Konstantin Ketterer Github: https://github.com/ko-redtruck/async-payments-ln _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev