From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jim Posen <jim.posen@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
Date: Tue, 01 May 2018 01:01:52 -0400 [thread overview]
Message-ID: <iDuf_CCTloIT3lZZsuC00xX8UW4Aq_czO6EvI-N6GMexp0HNcg5KazxVT9p4hOlQkjfpVwBNhzq-Py-8jFs0yXUIVqqknt3rBMNtyRqSZjg=@protonmail.com> (raw)
In-Reply-To: <CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Good morning Jim,
> If my understanding is correct though, this construction would significantly increase the safe CLTV delta requirements because HTLCs cannot be timed out immediately on the settlement transaction. Consider a case where node B receives an HTLC from A and forwards to C. If the HTLC offered to C times out and C does not fail the HTLC off-chain, Lightning currently guarantees that the CLTV delta is sufficient that I may close the channel to C on-chain and claim the timed-out HTLC before my upstream HTLC to A times out. If the CLTV delta is too small, I may fail the upstream HTLC as soon as it times out, and then C may still claim the downstream HTLC with the preimage on-chain. With eltoo, when B closes the downstream channel on-chain, it must wait the CSV timeout on the update transaction before locking in the timed-out HTLC. This effectively means the CLTV delta has to be greater than the CSV timeout, plus some extra (whereas it is currently safe to make it significantly shorter). Is that true or am I missing something?
I believe this is quite true; indeed only the LN-penalty/Poon-Dryja channels do not have this drawback, as Decker-Wattenhofer invalidation trees also have the same drawback that the CSV and CLTV add up.
However the worst-case invalidation tree total CSV timeouts under Decker-Wattenhofer can grow quite massive; it seems the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 1684 bytes --]
next prev parent reply other threads:[~2018-05-01 5:02 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 15:41 Christian Decker
2018-04-30 23:00 ` Jim Posen
2018-05-01 5:01 ` ZmnSCPxj [this message]
2018-05-01 11:36 ` Christian Decker
2018-05-01 15:50 ` Jim Posen
2018-05-01 16:29 ` Christian Decker
2018-05-01 17:07 ` Jim Posen
2018-05-01 17:31 ` Christian Decker
2018-05-02 1:15 ` Jim Posen
2018-05-07 23:26 ` Olaoluwa Osuntokun
2018-05-10 13:57 ` Christian Decker
2018-05-01 5:07 ` [bitcoin-dev] [Lightning-dev] " ZmnSCPxj
2018-05-01 11:38 ` Christian Decker
[not found] ` <20180619115618.ppycfvdh76rdagfo@email>
[not found] ` <87tvpy96lz.fsf@gmail.com>
[not found] ` <20180619180251.j4l3zvxfmwi5mwlb@email>
[not found] ` <20180620153150.4mdash2sj7r2aiwo@email>
2018-06-22 0:32 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='iDuf_CCTloIT3lZZsuC00xX8UW4Aq_czO6EvI-N6GMexp0HNcg5KazxVT9p4hOlQkjfpVwBNhzq-Py-8jFs0yXUIVqqknt3rBMNtyRqSZjg=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jim.posen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox