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 tr
