ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-10-30 📝 Original message: Good morning Konstantin, ...
📅 Original date posted:2019-10-30
📝 Original message:
Good morning Konstantin,
> ## 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
How does S learn that B has come online?
Presumably there is some kind of polling involved.
What do you imagine the polling rate to be?
One block?
100 blocks?
One difficulty adjustment?
One halving period?
>
> 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.
An issue is when the channel is forced onchain by either A or S.
For example, what if S is attacked by an army of shiny robots which destroys the keys of S?
(Disclaimer: I do not control, nor have I ever controlled, an army of shiny robots to take over the world.
Shininess does not increase combat capability, thus not useful property of robots to have.)
Obviously S can no longer participate in the channel update, thus A *must* force the channel onchain and execute the contract there.
Thus, the UTXO for this should be claimable in both a secret-revelation path and a timeout path, both enforceable onchain, else S could hold the funds hostage by threatening unilateral close of the channel.
i.e. you still need a PTLC for this.
Indeed, it seems to me that much of the advantage of this lies solely in S being directly a peer of the payer.
It seems doable with just HTLCs and a normal BOLT11 invoice from B (possibly sent in plaintext to A via a deferred messaging service such as email --- invoices contain no private data anyway).
Then the arrangement boils down to A and S agreeing that S will do all the routing (by polling the network) until just before the timeout indicated by the HTLC occurs.
Trampoline routing can then be used to mask B from S.
Regards,
ZmnSCPxj
📝 Original message:
Good morning Konstantin,
> ## 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
How does S learn that B has come online?
Presumably there is some kind of polling involved.
What do you imagine the polling rate to be?
One block?
100 blocks?
One difficulty adjustment?
One halving period?
>
> 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.
An issue is when the channel is forced onchain by either A or S.
For example, what if S is attacked by an army of shiny robots which destroys the keys of S?
(Disclaimer: I do not control, nor have I ever controlled, an army of shiny robots to take over the world.
Shininess does not increase combat capability, thus not useful property of robots to have.)
Obviously S can no longer participate in the channel update, thus A *must* force the channel onchain and execute the contract there.
Thus, the UTXO for this should be claimable in both a secret-revelation path and a timeout path, both enforceable onchain, else S could hold the funds hostage by threatening unilateral close of the channel.
i.e. you still need a PTLC for this.
Indeed, it seems to me that much of the advantage of this lies solely in S being directly a peer of the payer.
It seems doable with just HTLCs and a normal BOLT11 invoice from B (possibly sent in plaintext to A via a deferred messaging service such as email --- invoices contain no private data anyway).
Then the arrangement boils down to A and S agreeing that S will do all the routing (by polling the network) until just before the timeout indicated by the HTLC occurs.
Trampoline routing can then be used to mask B from S.
Regards,
ZmnSCPxj