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