Yaacov Akiba Slama [ARCHIVE] on Nostr: š Original date posted:2019-11-04 š Original message: Good Morning ZmnSCPxj, ...
š
Original date posted:2019-11-04
š Original message:
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 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 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 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
>