From: Jim Posen <jim.posen@gmail•com>
To: Christian Decker <decker.christian@gmail•com>
Cc: 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, 1 May 2018 10:07:22 -0700 [thread overview]
Message-ID: <CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.gmail.com> (raw)
In-Reply-To: <87in87gx0q.fsf@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]
I'm still not following why this doesn't accumulate.
In the example route, let's look at it from the point of view of C. C sees
the following regardless of whether D or E or someone behind E is the last
hop in the route:
B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
So D is not required to reveal the preimage before time X, and in the case
of an on-chain settle, C needs to be able to redeem the HTLC output through
the timeout clause before time X + delta. C can't redeem the HTLC (with
sufficient confirmations) at least until the settlement transaction is
confirmed. So it seems to me that regardless of the overall route and the
maximum CSV on it, the delta for the C hop has to be greater than the CSV
delay on the update transaction. And that this must be true at every hop
for the same reason.
On Tue, May 1, 2018 at 9:29 AM, Christian Decker <decker.christian@gmail•com
> wrote:
> Jim Posen <jim.posen@gmail•com> writes:
> > Can you explain why a fixed offset along the whole circuit is enough to
> > ensure safely as opposed to an increased delta at each hop?
>
> Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
> let's assume they all have a CLTV delta of 144 blocks (lnd's default
> setting). Furthermore let's assume that the CSV timeout for the channels
> is also 144.
>
> This means that with the current LN-penalty mechanism you'd have the
> following CLTV deltas in the HTLC:
>
> ```
> A -(576)-> B -(432)-> C -(288)-> D -(144)-> E
> ```
>
> Meaning that if the current time is approaching the absolute CLTV we
> need initiate a channel closure to safely fetch the preimage on-chain,
> and be able to turn around and send it on the upstream channel.
>
> This is minimal, but can be arbitrarily higher, if you follow the best
> practice of obfuscating the final destination by building a shadow route
> behind the real recipient, and add it's CLTV deltas and fees to your
> route.
>
> With eltoo you'd need to make sure that you have the settlement
> transaction confirmed before your desired CLTV timeout delta begins to
> count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV
> delta` you need to initiate a close, whereas Lightning allows you to
> wait for time `now + CLTV delta`. Effectively this results in the
> following time deltas:
>
> ```
> A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E
> ```
>
> Taking the last hop for example, if we had a CLTV of 1000 with eltoo
> we'd need to start closing at height 712, instead of 856 with
> LN-penalty. However, this increased delta does not accumulate along the
> path, it's just a fixed offset. The longer the route, the smaller the
> actual impact of this offset.
>
[-- Attachment #2: Type: text/html, Size: 3798 bytes --]
next prev parent reply other threads:[~2018-05-01 17:07 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
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 [this message]
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=CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.gmail.com \
--to=jim.posen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=decker.christian@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