Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EA0DF707 for ; Tue, 1 May 2018 16:29:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com [209.85.128.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6ABA42C4 for ; Tue, 1 May 2018 16:29:24 +0000 (UTC) Received: by mail-wr0-f169.google.com with SMTP id v60-v6so11274424wrc.7 for ; Tue, 01 May 2018 09:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=NLavGD2ur3JYYjcCOnd9PK3JdOQPkFruwauFnSppqQo=; b=TEloMbPWZ4GtWveyhoa9AtN7H4EC4q1VYS7pX/zuule0fdUJ1Ehhq2wkY9cSZU29O+ Fmxr6ScxUc45TMdVDKFi6MosZpTtcVfd4N61NRZ8dUT4M551tnlBeCurXig/CpMra7R5 O7rXg2/ss7mG2b9rS2FFuHlI3MkKmheW4lCVe+4zcqUEj8Hciomwl6ozU0WOgbdrRJi9 mpNo4gtiY9hqerqP82egt8c9yXCgEDkOiQ3OtwwS5QORUMffe6fp6c5vSQYzmn0hnz+6 ofp0eBJrY1dxaRiT1qk27c6w4Sjjw1BAhJiuuwMfFUklXIH5SP29mJ2IUgu6s249PSQ+ FvpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=NLavGD2ur3JYYjcCOnd9PK3JdOQPkFruwauFnSppqQo=; b=GCWdf86HAiXsfZZXVAf9mw38l8YMzXtsCA8O7pAjR46fsRS1hZ3Z4fgsW8hqOYpBFo OP6dV/FywO4wcBILq/Txtm085PCQal0Oz/rMROfWeW2HgLwPlJNjJFmmISxJBKWtxgLO ZFIE+65wN8DAtf3LuyyHRpm5V+QB6lGH/ugQ/z4imgB0jRXe06KUtIs0pCAStqIq969l wsJHCO/C1T48cBoeUkXoHQA8d8L/t8+svtnoff2Et2vB9UW38KQFe3ARgCmJPm3E1xq9 7mhEh7fgaxnyjnZldmP7M5OWNrNgqJi1lRW2Uelg5GcxnrhdVNctxN8WxYmSu3yxKKQj UVsg== X-Gm-Message-State: ALQs6tC2nIPd056jdCi5adDXw23F/Zqd47Ht87jExAa8CYco1rKMsCPj 45EmgMq9uy+XGnUJaImfgjE= X-Google-Smtp-Source: AB8JxZrguMubM3FMiJDzqxvxghjIikGP7miy1n2LB0WnxV8/mQTcYk3nyzZFTb4zFN+Xqkfri/w08Q== X-Received: by 2002:adf:8212:: with SMTP id 18-v6mr11903165wrb.144.1525192163043; Tue, 01 May 2018 09:29:23 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id c124sm10054531wmd.36.2018.05.01.09.29.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 09:29:22 -0700 (PDT) From: Christian Decker To: Jim Posen In-Reply-To: References: <874ljsitvx.fsf@gmail.com> <87vac7hakf.fsf@gmail.com> Date: Tue, 01 May 2018 18:29:09 +0200 Message-ID: <87in87gx0q.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 16:29:25 -0000 Jim Posen 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.