From nadav at suredbits.com Tue Oct 29 21:20:28 2019 From: nadav at suredbits.com (Nadav Kohen) Date: Tue, 29 Oct 2019 16:20:28 -0500 Subject: [Lightning-dev] asynchronous Lightning network payments In-Reply-To: References: Message-ID: Hi Konstantin, This looks cool and I haven't had a chance yet to spend time with the idea, but I would like to add that you can likely solve the PoP problem mentioned under potential issues by having S pay B with an AMP-like setup. We use the point B + x*G on one payment where x is a nonce generated by S, and the point B + s*G + x*G on the other payment. The nonce, x, is revealed to the signature seller only when they receive both onions. This way 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. Best, Nadav On Tue, Oct 29, 2019 at 3:47 PM Konstantin Ketterer < ketterer.konstantin at gmail.com> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: