Nadav Kohen [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-29 📝 Original message: Hi Konstantin, This looks ...
📅 Original date posted:2019-10-29
📝 Original message:
Hi Konstantin,
This looks cool and I haven't had a chance yet to spend time with the idea,
but I would like to add that you can likely solve the PoP problem mentioned
under potential issues by having S pay B with an AMP-like setup. We use the
point B + x*G on one payment where x is a nonce generated by S, and the
point B + s*G + x*G on the other payment. The nonce, x, is revealed to the
signature seller only when they receive both onions. This way when the
payment completes, S learns b + x and b + x + s so that they can compute b
= (b + x) - x and s = (b + x + s) - (b + x). s is the signature that they
wanted and b is the PoP.
Best,
Nadav
On Tue, Oct 29, 2019 at 3:47 PM Konstantin Ketterer <
ketterer.konstantin at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191029/f44fc4d8/attachment.html>;
📝 Original message:
Hi Konstantin,
This looks cool and I haven't had a chance yet to spend time with the idea,
but I would like to add that you can likely solve the PoP problem mentioned
under potential issues by having S pay B with an AMP-like setup. We use the
point B + x*G on one payment where x is a nonce generated by S, and the
point B + s*G + x*G on the other payment. The nonce, x, is revealed to the
signature seller only when they receive both onions. This way when the
payment completes, S learns b + x and b + x + s so that they can compute b
= (b + x) - x and s = (b + x + s) - (b + x). s is the signature that they
wanted and b is the PoP.
Best,
Nadav
On Tue, Oct 29, 2019 at 3:47 PM Konstantin Ketterer <
ketterer.konstantin at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191029/f44fc4d8/attachment.html>;