From ketterer.konstantin at gmail.com Wed Oct 30 12:39:31 2019 From: ketterer.konstantin at gmail.com (Konstantin Ketterer) Date: Wed, 30 Oct 2019 13:39:31 +0100 Subject: [Lightning-dev] asynchronous Lightning network payments In-Reply-To: References: Message-ID: Hi ZmnSCPxj, 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? > I imagined that A somehow send the IP address of S or any information to contact S alongside the transaction and then B would connect to S and request the payment. If it had to be a polling rate I would choose something like 6 blocks. > > #### 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. > I don't think I understand what you are trying to say. Because we are using eltoo A can at any point in time publish the trigger transaction, the previous update transaction and the corresponding settlement transaction without any repercussions and recover its money after some amount of time. This essentially allows A to cancel the payment to B until B has claimed the payment from S. Because if S has already paid B and has not lost its keys ( or already signed the new update transaction beforehand) it can double spend the older settlement transaction from A with its newer update and settlement transaction. All in all, A can still force the channel to settle on chain even if S does not cooperate anymore and doesn't tell A about the new update + settlement transaction. Regards Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: