[Lightning-dev] asynchronous Lightning network payments

[Konstantin Ketterer]

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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191030/3c07d8bb/attachment.html>