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 6526A4A3; Mon, 30 Apr 2018 17:28:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 698595D3; Mon, 30 Apr 2018 17:28:58 +0000 (UTC) Received: by mail-wm0-f52.google.com with SMTP id n10so15439146wmc.1; Mon, 30 Apr 2018 10:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=cT/qe8T0NjKhd0sVa4BHayGc19G+PU1psD9+EiRLCow=; b=bZG48FnWlXN3LBNtfbAn747CB6+Xhklns1HkRnTL3ZsxEmYO3MkiEMrQ6IzbbzvShX osfJoRG3oABo/zAMBv70x/LsrmO/kKUt4rb9YAO8zlhzkkEMbRdUdMeFcP8D0vHkzLNc /AVUw4d3fJIKLvErWGgCIVbVS6na44s6BEIbyFbmY4CA5IY6SwQ/MYox7a2RZSI+znRR E/8qylOucg56FQG+LZpwsVzc95AbcPGM3AQ6J+9ki6clGkgasc+29yh4sWcET7IKaD5K d4WarfzFv2i4pvSDW6i5mEBfIEnoiXuq9fqZa++Zty9MJ66+FXgqIzslxJgHQlU6iAy9 sdZg== 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:date:message-id:mime-version :content-transfer-encoding; bh=cT/qe8T0NjKhd0sVa4BHayGc19G+PU1psD9+EiRLCow=; b=uNjdNMzIZx3gnxg5RUPpwv7Ewy9oRIjoJsKJgbtve4MgZ0nuvK5EwiYnM9xxpkk7oy bwStl0dT4XkLj7SCq1+g+IPdDI4ndxXo9BbIlljNenGT5xCZ6yz5m3W+f7RjApFr+F7X Ejlgh1KKyUadbUfvtZ7HFz29x/Yqv1zMbomN51TT1G7HMgOBnX0YMBVVRetX/Zd435bp I9HX11pBAt6AwBJpRrEjfFrbR7IP4G/Fwm9GnXWGhZMqQqzJTcAD4Jmcnt01XIt1BheQ mOIOM4cKaPj6GPgpx1/1bFDf9P7hFGdcHPO2p2mJo7RDpLwhWKbG5dppRPfRB6q570GA EmqA== X-Gm-Message-State: ALQs6tDwg7sB88B8iFk7/mBnEJLa6GbXz7rpnQU9O66ScYGiD5PEhvT/ UKZb7XKh+PCau2E562zRAivEAWSb X-Google-Smtp-Source: AB8JxZpXmgNCa4vvsiIUevvAXkqp5KF10gCobUa384QF0afMwOJrYeuSLAomG00Bh7HYUuvW96Lvjw== X-Received: by 10.28.69.24 with SMTP id s24mr4326311wma.50.1525109336660; Mon, 30 Apr 2018 10:28:56 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id u36-v6sm12096706wrf.87.2018.04.30.10.28.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 10:28:55 -0700 (PDT) From: Christian Decker To: lightning-dev@lists.linuxfoundation.org, bitcoin-dev@lists.linuxfoundation.org Date: Mon, 30 Apr 2018 17:41:38 +0200 Message-ID: <874ljsitvx.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MIME_QP_LONG_LINE, 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: [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: Mon, 30 Apr 2018 17:28:59 -0000 (cross-posting to bitcoin-dev since this serves as motivation behind the sighash_noinput proposal) > TL;DR: we announce a new, simple, update mechanism for off-chain protocols, > see the announcement [1] and the paper [2] :-) A little over a year ago, the three Lightning Network implementation teams joined forces to work on a common specification for the protocol stack. Now that both that specification and our three implementations are becoming stable and usable, it is time to look forward: to further improve the protocol, to add new features, to simplify, and to fix downsides. One of the core innovations that enabled Lightning in the first place was an off-chain update mechanism to renegotiate a new state and ensure that the old state can not be settled on-chain. Today, we're excited to release our latest research paper on a new, simplified, update mechanism for layer 2 protocols, called eltoo. eltoo is a drop-in replacement for the penalty based invalidation mechanism that is used today in the Lightning specification. It is similar in many ways to the sequence number mechanism that was already present in the original Bitcoin implementation. But, while sequence numbers were unenforceable on the blockchain, eltoo is enforceable by overriding subsequent states on-chain. Unlike the current mechanism used in Lightning so far, it is not penalty based, i.e., publishing an old state does not result in the faulty node to automatically lose funds, and is most similar to the duplex micropayment channels construction. It is a symmetric scheme, i.e., all participants share an identical set of transactions, and it ensures that the last agreed upon state is settled on-chain, with similar tradeoffs as today's Lightning (timelock vs. online requirement). eltoo addresses some of the issues we encountered while speficying and implementing the Lightning Network. For example outsourcing becomes very simple since old states becoming public can't hurt us anymore. We completely remove the need to estimate fees ahead of time. The construction allows us to attach fees when settling, and even allows for fees to be bumped using CPFP or RBF. Beyond Lightning, eltoo can be used as a generic update mechanism for an off-chain contract, for a larger number of participants. This was not possible in the current update mechanism since reactions to a misbehaving participant needed to be tailore to that participant. This enables other protocols such as the channel factories, and in combination with Schnorr signatures allows for very large off-chain contracts with minimal on-chain footprint. Before we can implement eltoo, we need a minor change to Bitcoin: the introduction of the SIGHASH_NOINPUT flag for signatures. This was first discussed a few months ago in the context of watchtowers to help secure Lightning channels, but was not formally proposed. A formal proposal may now be found in the eltoo paper. We invite the community to consider our proposal and to participate in its discussion. We hope to arrive at a consensus for the usage of SIGHASH_NOINPUT, so that it can be accepted and included in a future soft fork of Bitcoin Script. Doing so will put us on the road to a more reliable and simpler Lightning Network, incorporating a new update mechanism that can also be used for many other applications. The full official announcement can be found at [1] and the paper with the full details can be found at [2]. Looking forward to the communities feedback, Christian [1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html [2] https://blockstream.com/eltoo.pdf