Good Morning ZmnSCPxj,
The problem with polling is that the payee can be online between two
attempts and offline when the trampoline node polls.
We need a way for the payee to notify the trampoline node when online.
This is another reason to implement sooner than later messaging in LN.
Meantime, other communication mechanisms need to be used.
Thanks,
--yas
On 04/11/2019 09:31, ZmnSCPxj wrote:
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@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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
