1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
Return-Path: <decker.christian@gmail.com>
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 <decker.christian@gmail.com>
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 <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: 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
|
