ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-04 📝 Original message: Good morning Konstantin ...
📅 Original date posted:2019-11-04
📝 Original message:
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
📝 Original message:
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