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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
