From ZmnSCPxj at protonmail.com Wed Oct 30 04:28:28 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Wed, 30 Oct 2019 04:28:28 +0000 Subject: [Lightning-dev] asynchronous Lightning network payments In-Reply-To: References: Message-ID: 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