What is Nostr?
Lloyd Fournier [ARCHIVE] /
npub1khl…05yp
2023-06-09 13:04:09

Lloyd Fournier [ARCHIVE] on Nostr: đź“… Original date posted:2021-10-11 đź“ť Original message: On Mon, 11 Oct 2021 at ...

đź“… Original date posted:2021-10-11
đź“ť Original message:
On Mon, 11 Oct 2021 at 17:30, Anthony Towns <aj at erisian.com.au> wrote:

>
> I don't think the layering here quite works: if Alice forwarded a payment
> to Bob, with timeout T, then the only way she can be sure that she can
> either reclaim the funds or know the preimage by time T is to close the
> channel on-chain at time T-to_self_delay.
>
> Any time later than that, say T-to_self_delay+x+1, would allow Bob to
> post the inflight tx at T+x (prior to Alice being able to claim her
> balance directly due to the to_self_delay) and then immediately post the
> layered transaction (4, above) revealing the preimage, and preventing
> Alice from claiming the refund.
>

This problem may not be as bad as it seems. Recall that the issue in eltoo
is worse because you are delayed both when you are offering and receiving
the HTLC. In this one you are only delayed on offered HTLC.

Adjust the protocol so that you reciprocate the in-flight txs. So when I
offer you a HTLC you first forward it and then lazily send me the signature
for the inflight tx. Therefore I dont have to wait to get the HTLC on chain
and don’t have to close the channel early.

So against a malicious node you have to go on chain to_self_delay earlier
than usual but if both are honest you don’t have to. The problem with eltoo
is that we don’t know how to achieve this even if both parties are honest
iirc.

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211011/270d3661/attachment.html>;
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp