From ZmnSCPxj at protonmail.com Mon Nov 4 07:31:56 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 04 Nov 2019 07:31:56 +0000 Subject: [Lightning-dev] asynchronous Lightning network payments In-Reply-To: <66da6c29-2e73-a7b6-1afd-c5041fca3d6d@slamail.org> References: <CAHoOKgJfz9bEuqDFrWkPjsjYoemBSpjgLvh5e+z+h37wnXVsTw@mail.gmail.com> <66da6c29-2e73-a7b6-1afd-c5041fca3d6d@slamail.org> Message-ID: <-vh6mN7Q7RhNpUx8anRyY6M1upYwUBkmLYF8l5MWJ92k_pyy3naXVEkHYWbuOyticnq654CuHmHmicFNyUOK1V7Z5-H65xP0KnuzFPAoURw=@protonmail.com> Good morning Konstantin and yas, Indeed, yas is quite correct: the money is still locked, and all that this proposal adds is to limit the funds locked by having S be a direct peer of the payer. In the case proposed by Konstantin, this is simply locked between both A and S only, but it *must* be locked, or else timing shenanigans can be performed to defraud S. A proposal, is to add some sort of `please_poll` flag TLV to Trampoline onions, where if `please_poll` is enabled for a Trampoline node, it will perform the above-mentioned polling of once every 6 blocks. That way, any node that supports Trampoline *and* `please_poll` can work as an S (or Rod) for a possibly-offline next step. Alternatively, Trampoline implementations might actually just implement the polling behavior automatically without a `please_poll` flag; this might be viable especially if the Trampoline is given a substantial fee and time budget anyway. The only thing needed is for Trampoline to allow prepending of onions, then even the payee gets privacy from the payer. Regards, ZmnSCPxj > [Resending in Plain Text. Sorry for the spam] > 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 at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev