From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1192971F for ; Thu, 10 May 2018 14:12:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4C0A6682 for ; Thu, 10 May 2018 14:12:34 +0000 (UTC) Received: by mail-wm0-f54.google.com with SMTP id y189-v6so4638465wmc.3 for ; Thu, 10 May 2018 07:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=2+unz6kVjoUm7XC6ZFXauWbH9z8IHhrfErZ/ayPyYlQ=; b=UAbB9T48/fkBYVRFA7l1xL+8BLndApvxHciyOQ7Qp3Itx1nG1uuRWA51fl7LSJCmzL eIXjnsS9YQ0FzmW3yQtQuFl2Peia84pn1xeXQJT5NaFizMX8kkfwkmp9u7J8jxKXxZdh n4J8u4VtNruiUtHA4rtTq4H1fKkfN9rt+wT/oi6qDSZLUwepO3kd4H8mbmtg2FfVD++R 68ZRO6+qp7KP0j8PNDZYRpEguJAwEi62Nq92QEzS3Vs9GuXxRxBPyYWOBys1nPzx1x2+ sjlDtxXGSsLbipL+jbrOKetwUZA8oqb890TSBm9+WWodrscOFobI51zFEKJ9r/ApkgWs Zsng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=2+unz6kVjoUm7XC6ZFXauWbH9z8IHhrfErZ/ayPyYlQ=; b=tKy7rleWzgBvex0g5vYsAhvL9H1H/sAP/FrDkZxfHZszIlTSOLH44RQsTy8QLRNWTC DOm1GcEF4R6DYVNNqNtnN8imJF/gAhAxvP3chu0L08HnKTjcWN8Oja31ruEq43uN29S9 /i3q7btOAFXQTLkJGbLCu9rQHfYMO7abS/GbT71kqGaB0+GP52gmcmN/Un4Tq+pNueTq ix1M1KHwUoSWBVtNM5CHuEocAwUuVSwno/BDp/NBiHM+T5rNITTVVWibQBPqsF4CcDnP Ea2sQx9wkLMihLrmQocq37K3tFcS+z7cp/oklSrRQJY3693yXLc1pFqzoTRCz/AueXys kYDw== X-Gm-Message-State: ALKqPwfLf6aY6EYFo5+L4BygQCEjhoBwDJReVlN7U+M6F7eTJL4QP82j E2McsGa4gnIIwFoF4xwMLO4= X-Google-Smtp-Source: AB8JxZoTta8BaPtC+20NJsB4KjGdpWPdgWmqFuJci29+G7rp3J1StFqa7eNKKmu9mhkI39qDsR7Yxw== X-Received: by 2002:a1c:4406:: with SMTP id r6-v6mr1283957wma.99.1525961552788; Thu, 10 May 2018 07:12:32 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id c18-v6sm1484702wmd.13.2018.05.10.07.12.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 07:12:31 -0700 (PDT) From: Christian Decker To: Olaoluwa Osuntokun , Bitcoin Protocol Discussion , Jim Posen , Bitcoin Protocol Discussion In-Reply-To: References: <874ljsitvx.fsf@gmail.com> <87vac7hakf.fsf@gmail.com> <87in87gx0q.fsf@gmail.com> <87bmdzgu4v.fsf@gmail.com> Date: Thu, 10 May 2018 15:57:30 +0200 Message-ID: <87603v4nqt.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 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: Thu, 10 May 2018 14:12:35 -0000 Olaoluwa Osuntokun via bitcoin-dev writes: > Hi Jimpo, > > You're correct that the introduction of symmetric state now > re-introduces the dependency between the CSV value of the commitment, > and the HTLC timeouts. It's worth nothing that this issue existed in > an earlier version of the BOLT spec, this was pointed out by Mats in > the past: [1][2]. The dependency meant that if we wanted to allow very > long CSV time outs (like 1 month +), then this would have the adverse > effect of increasing the total CLTV timeout along the entire route. As > a result, we moved to the 2-stage HTLC scheme which is now implemented > and deployed as a part of BOLT 1.0. It may be the case that in the mid > to near future, most implementations aren't concerned about long time > locks due to the existence of robust and reliable private > outsourcers. It's worth mentioning that the requirement for extremely large CLTV deltas would already create incredibly long CLTV deltas between the endpoints, since the endpoint delta accumulates along the path. This is true for LN-Penalty as well as eltoo. eltoo's requirement to settle before the HTLCs touch the blockchain adds a stage in which need to start on-chain settlement to ensure the HTLC hits the chain before its CLTV expires. We can imagine this as a separate timewindow, that does not accumulate across multiple hops (settlement ordering is not an issue, CLTV resolution is). My hope is that indeed with the simpler watch-towers we can reduce both the CLTV deltas as well as the settlement timeouts for eltoo, so that they become negligible. > As a side effect of the way the symmetric state changes the strategy > around breach attempts, we may see more breach attempts (and therefore > update transactions) on the chain since attempting to cheat w/ vanilla > symmetric state is now "costless" (worst case we just use the latest > state, best case I can commit the state better for me. This is in > stark contrast to punishment/slashing based approaches where a failed > breach attempt results in the cheating party losing all their funds. Not exactly costless, since the breaching party will have to pay the on-chain fees, and we may be able to reintroduce the reserve in order to add an additional punishment on top of the simple update mechanism (selectively introducing asymmetry). > However, with a commitment protocol that uses symmetric state. The > 2-stage HTLC scheme doesn't actually apply. Observe that with > Lighting's current asymmetric state commitment protocol, the "clock" > starts ticking as soon as the commitment hits the chain, and we follow > the "if an output pays to me, it must be delayed as I may be > attempting a breach". With symmetric state this no longer applies, the > clock instead starts "officially" ticking after the latest update > transaction has hit the chain, and there are no further challenges. As > a result of this, the commitment transaction itself doesn't need to > have any CSV delays within the Script branches of the outputs it > creates. Instead, each of those outputs can be immediately be spent as > the challenge period has already elapsed, and from the PoV of the > chain, this is now the "correct" commitment. Due to this, the HTLC > outputs would now be symmetric themselves, and look very much like an > HTLC output that one would use in a vanilla on-chain cross-chain > atomic swap. In addition to this it is worth pointing out that the old/replaced HTLCs have no way of ever touching the blockchain, so we can throw away a whole heap of data about these HTLCs, that we would have to carry around indefinitely if this were not the case. The same reason the HTLCs start ticking when a settlement touches the chain in LN-penalty is also the reason we need to carry all that data around. eltoo can be said to contain the two stage HTLC commit we added on top of LN-penalty. Cheers, Christian