diff options
| author | Jim Posen <jim.posen@gmail.com> | 2018-05-01 15:50:27 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-05-01 15:50:40 +0000 |
| commit | e50f5234a8942ffba311f91b9ad84003d678edb7 (patch) | |
| tree | f2e7a862c7c401fea173c09e5532aff7d61ac486 | |
| parent | 19ba87888b5ac8b93427ec58828346f64a19a510 (diff) | |
| download | pi-bitcoindev-e50f5234a8942ffba311f91b9ad84003d678edb7.tar.gz pi-bitcoindev-e50f5234a8942ffba311f91b9ad84003d678edb7.zip | |
Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
| -rw-r--r-- | 67/42d83195c077165223637a9ee6450e2129fbdc | 189 |
1 files changed, 189 insertions, 0 deletions
diff --git a/67/42d83195c077165223637a9ee6450e2129fbdc b/67/42d83195c077165223637a9ee6450e2129fbdc new file mode 100644 index 000000000..3a6020562 --- /dev/null +++ b/67/42d83195c077165223637a9ee6450e2129fbdc @@ -0,0 +1,189 @@ +Return-Path: <jim.posen@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 6E8DD723 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 May 2018 15:50:40 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com + [209.85.216.171]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7A79C682 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 1 May 2018 15:50:39 +0000 (UTC) +Received: by mail-qt0-f171.google.com with SMTP id f13-v6so5231856qtp.10 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 01 May 2018 08:50:39 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=dJrxS4qLiTqdaA2beCTDaBFg5H2F7I+Nqo1ppjIRD3k=; + b=VnBZZnN/xFLkD+NG0e3AfYcYx7lfvhRN38frpyRwecD8yidG2KaLrp5QRRt+lJLRY+ + Ua1s9gh3I9ft3IdNaPL+ZzkSzLf4RFVF4aA3A5WO74SnqAZxT5vAysDs3uvLHsfMFE7F + F2GxjnJGnUPh0l7WAGq9v/eVKg7IoCVI4giK6ufIAYJY4DlfUNp0LV1sgsKLLIy3t5D+ + HHKszr/xvzRqVEK4a4PLl4uxlvUqSY0sqzpPnlfj3si+uIOe4Oe3jH7lzfoln3Pt3pgE + ySJYxoYt0aDd2jN7SEPlzpEpf7NWEfntTk5JFM5Ejr4TZz0QYQLYs5XBQdrclNnj7ebL + mHzw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=dJrxS4qLiTqdaA2beCTDaBFg5H2F7I+Nqo1ppjIRD3k=; + b=tjhWa/oY7ZHhZjzykTSlV+WSpCAJh50nwdrS3ZRWsbxb64x+5L/vvFE6r06SEHaYxW + g5I9BHzrE9/0BV1SsCnqCI6EKs+G6U9SdH7c7Q3p6XRoxSTM3NioZUGwgLM6y93Vog7Q + g9ngTPW7lh0FDSsmC2ryn1xb4XFwwsW+FNLXa3eC7GfSstxXgdzikVYhTV2GvBdW/v/x + Cb2+VG3YhiL8D21UzwX6+5ImgQZ6ffqzPMVSAgn0QrVtY5pyqlTBoecSprTgl3+3giJ3 + Vecaxon76cCJ1+xJtQHl6x6CfdP5xVyEFDuxi+sb/SuRQYJ4iEPyaCtDRbEt8L8z4g5u + 6D4g== +X-Gm-Message-State: ALQs6tAroTJdzVWEE5hzOMQYsd16y7ixOIUUhAOApvjoRflFbVhwLH+Q + 5i9ckLpN7ozQ0JvaMlBVPB6kpHLY8J1ZRrxnJ6Q= +X-Google-Smtp-Source: AB8JxZo5y80NEiVTdOShgqE/kYI1bxNUG0x0n/uUFf7SQPKnizlSHOqehTT3RWMLsIPMrq15ZGcoax45swXSUC0n1hQ= +X-Received: by 2002:ac8:35f0:: with SMTP id + l45-v6mr14036662qtb.317.1525189838503; + Tue, 01 May 2018 08:50:38 -0700 (PDT) +MIME-Version: 1.0 +References: <874ljsitvx.fsf@gmail.com> + <CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com> + <87vac7hakf.fsf@gmail.com> +In-Reply-To: <87vac7hakf.fsf@gmail.com> +From: Jim Posen <jim.posen@gmail.com> +Date: Tue, 01 May 2018 15:50:27 +0000 +Message-ID: <CADZtCShihv1PR4yD_xATD2mv5CSMqH385HWVLdZQSG_9ZyJ7Jw@mail.gmail.com> +To: Christian Decker <decker.christian@gmail.com> +Content-Type: multipart/alternative; boundary="0000000000008a045e056b26ee59" +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 01 May 2018 15:57:21 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for + Lightning and Off-Chain Contracts +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Tue, 01 May 2018 15:50:40 -0000 + +--0000000000008a045e056b26ee59 +Content-Type: text/plain; charset="UTF-8" + +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? + +On Tue, May 1, 2018, 5:05 AM Christian Decker <decker.christian@gmail.com> +wrote: + +> Jim Posen <jim.posen@gmail.com> writes: +> > 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? +> +> That's a good point Jim. We need to make sure that the CLTVs are far +> enough in the future for the CSV timeout to expire and to grab any +> preimage downstream and insert it upstream. Overall this results in an +> offset of all the CLTVs to (less than) the maximum CSV timeout along the +> path. This would be a fixed offset for each channel and can be announced +> using the gossip protocol, so senders can take it into consideration +> when computing the routes. Notice that this is not really the CLTV +> delta, which would accumulate along the path, but an offset on which the +> CLTV deltas build on. +> +> In today's network we have many nodes that have a CLTV delta of 144 +> blocks, which quickly results in HTLC funds unavailable for several days +> depending on the route length, so I don't think that adding a fixed +> offset is much worse. Once we have watch-towers we can reduce both the +> offset as well as the CLTV deltas. Since eltoo makes watch-towers less +> expensive, given the reduced storage costs, I'd argue that it's a net +> positive for the Lightning network (but then again I'm biased) :-) +> + +--0000000000008a045e056b26ee59 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"auto">Can you explain why a fixed offset along the whole circui= +t is enough to ensure safely as opposed to an increased delta at each hop?<= +/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, May 1, 2018, 5= +:05 AM Christian Decker <<a href=3D"mailto:decker.christian@gmail.com">d= +ecker.christian@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmai= +l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= +:1ex">Jim Posen <<a href=3D"mailto:jim.posen@gmail.com" target=3D"_blank= +" rel=3D"noreferrer">jim.posen@gmail.com</a>> writes:<br> +> If my understanding is correct though, this construction would<br> +> significantly increase the safe CLTV delta requirements because HTLCs<= +br> +> cannot be timed out immediately on the settlement transaction. Conside= +r a<br> +> case where node B receives an HTLC from A and forwards to C. If the HT= +LC<br> +> offered to C times out and C does not fail the HTLC off-chain, Lightni= +ng<br> +> currently guarantees that the CLTV delta is sufficient that I may clos= +e the<br> +> channel to C on-chain and claim the timed-out HTLC before my upstream = +HTLC<br> +> to A times out. If the CLTV delta is too small, I may fail the upstrea= +m<br> +> HTLC as soon as it times out, and then C may still claim the downstrea= +m<br> +> HTLC with the preimage on-chain. With eltoo, when B closes the downstr= +eam<br> +> channel on-chain, it must wait the CSV timeout on the update transacti= +on<br> +> before locking in the timed-out HTLC. This effectively means the CLTV = +delta<br> +> has to be greater than the CSV timeout, plus some extra (whereas it is= +<br> +> currently safe to make it significantly shorter). Is that true or am I= +<br> +> missing something?<br> +<br> +That's a good point Jim. We need to make sure that the CLTVs are far<br= +> +enough in the future for the CSV timeout to expire and to grab any<br> +preimage downstream and insert it upstream. Overall this results in an<br> +offset of all the CLTVs to (less than) the maximum CSV timeout along the<br= +> +path. This would be a fixed offset for each channel and can be announced<br= +> +using the gossip protocol, so senders can take it into consideration<br> +when computing the routes. Notice that this is not really the CLTV<br> +delta, which would accumulate along the path, but an offset on which the<br= +> +CLTV deltas build on.<br> +<br> +In today's network we have many nodes that have a CLTV delta of 144<br> +blocks, which quickly results in HTLC funds unavailable for several days<br= +> +depending on the route length, so I don't think that adding a fixed<br> +offset is much worse. Once we have watch-towers we can reduce both the<br> +offset as well as the CLTV deltas. Since eltoo makes watch-towers less<br> +expensive, given the reduced storage costs, I'd argue that it's a n= +et<br> +positive for the Lightning network (but then again I'm biased) :-)<br> +</blockquote></div> + +--0000000000008a045e056b26ee59-- + |