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
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
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 E826B22A1;
Fri, 6 Sep 2019 13:23:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f67.google.com (mail-ed1-f67.google.com
[209.85.208.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED240831;
Fri, 6 Sep 2019 13:23:37 +0000 (UTC)
Received: by mail-ed1-f67.google.com with SMTP id i1so6306392edv.4;
Fri, 06 Sep 2019 06:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:cc:date:message-id:mime-version;
bh=EOcaEuS/DzeX+REKHfXEhOTJXjuMmfZzVeTqOfQzFiA=;
b=JIeaNN8iumjsjdABJJJjeoEWVVPRLWnjoCsp1NdH36y5igZouCX6b3YDTWG7GAeIti
28mDVfM3p5vNyB+C01s6m9IZB7yPsHwUuQqry5zB8sS4ED7yPGOqUFHjtA8Kz0zmgxkm
PrG3ic9OdbfP0v37NJf0Qw8N8GbH6gJnjJpEYC5K3LWPc5YAx9ts9dAJUHQ9Ffkm3hoL
P8SNWsOyIKsRHLZl8BQHzPe8+T+O+kTRM+m0w0c841MEJ52PSWyfY+KfPCtyb0eAUxvv
/XD6OjozE+aAL9prkCkQ+yQw+hPHg9ow23mW0PMuFaP69KHSsFaoE6gZdBirbLDYpNpH
Z+vw==
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:cc:date:message-id:mime-version;
bh=EOcaEuS/DzeX+REKHfXEhOTJXjuMmfZzVeTqOfQzFiA=;
b=MinhJG3p+Vbgs1lwleIqZjbSGo5IyfTXv+0yIFlkhGAwZc8NvJwtf65RH7U2xjzgnb
jkEixpRD5p2HO3pn1aBe7BoL6HegMA0weceVuCFaBEyJboffrqjZZguvamM+jsV3iy3h
v37eWvagN1HExpp3HTTHfzTlzyZwuJCPVYMuSru6sHfm/4r9DVQL6I+bG700XJcShNLd
AeTayMtwakZ7RcJ3KmjXO0tyxwuqzu8AKw8Ymjyn30zJ4Uez7LpD8MJyUn/PCAFd4hdU
9C36/map12hqvTi3jLWP0bi+Tf9g0rJdRqxTGuVNv2l6cQfaPbZnPNvY/KSo4C8MGT0f
VZ5w==
X-Gm-Message-State: APjAAAWwr3QlRP8UQtoUpLzcpGNzsspAFRvecf4TZNgl1lljQbnqxBpb
lHD/Mv4I5ICw0RbiWVZYy4iexAv9jdI=
X-Google-Smtp-Source: APXvYqzEo31nSIoCCTybRh+P0F9TibfrOO5lhS5aTwQGGVyfwoEDAE81/bOgVvCGUq559dIfbtk/fg==
X-Received: by 2002:a17:907:10c2:: with SMTP id
rv2mr7080198ejb.305.1567776215856;
Fri, 06 Sep 2019 06:23:35 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:151b:6955:e30b:9bb2])
by smtp.gmail.com with ESMTPSA id bm1sm937335edb.29.2019.09.06.06.23.34
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Fri, 06 Sep 2019 06:23:35 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: lightning-dev@lists.linuxfoundation.org
Date: Fri, 06 Sep 2019 15:18:03 +0200
Message-ID: <87mufhva0k.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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Reconciling the off-chain and on-chain models with
eltoo
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: Fri, 06 Sep 2019 13:23:39 -0000
With the recently published proof-of-concept of eltoo on signet by
Richard, I thought it might a good time to share some thoughts on ho I
think we can build this system. I think there are a few properties of
eltoo that allow us to build a nicely layered protocol stack, which
improves flexibility and simplifies the reasoning about their relative
security.
Since I don't like huge e-mails myself and I'm about to write one,
here's a quick TL;DR:
> Using the clean separation of protocol layers provided by eltoo we can
> reconcile many on-chain and off-chain concepts, and simplify the
> reasoning to build more complex functionality beyond simple
> HTLCs. Bitcoin transactions are a natural fit to represent proposed
> off-chain state-changes while they are being negotiated.
### Clean separation of protocol layers
One of te big advantages of eltoo over other off-chain update mechanisms
is that it provides strong guarantees regarding the state that will
eventually end up confirmed on-chain. If parties in an eltoo off-chain
contract agree on an update, we can be certain (within eltoo's security
assumptions) that this is the state that will eventually confirm
on-chain, if no newer states are agreed.
In particular it means that we are guaranteed no earlier state can leak
onto the chain, keeping anything we build on top of the update layer
unencumbered since it doesn't have to deal with this case.
This is in stark contrast to the penalty update mechanism, where
old/revoked states can leak on-chain, resulting in anything built on top
of the penalty mechanism having to deal with that eventuality. For
example if we look at HTLCs as specified [1] we see that it needs an
additional revokation path for the case the commitment transaction that
created this HTLC output is confirmed:
```btcscript
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
OP_IF
OP_CHECKSIG
OP_ELSE
<remote_htlcpubkey> OP_SWAP OP_SIZE 32 OP_EQUAL
OP_IF
# To local node via HTLC-success transaction.
OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
2 OP_SWAP <local_htlcpubkey> 2 OP_CHECKMULTISIG
OP_ELSE
# To remote node after timeout.
OP_DROP <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
OP_CHECKSIG
OP_ENDIF
OP_ENDIF
```
The update mechanism bleeding into the other layers is rather cumbersome
if you ask me, and complicates the reasoning about security. Having to
thread the penalty through outputs created by the off-chain contract may
also not work if we deal with more than 2 parties, since penalties
always steal all the funds, regardless of whether the output belonged to
the cheater or not (see asymmetry vs symmetry argument from the paper
[2]).
With the clean separation we get from eltoo we can concentrate on
building the output scripts we'd like to have without having to thread
penalties through them. This reduces the complexity and our on-chain
footprint.
The update layer now exposes only two very simple operations:
`add_output` and `remove_output` (this should sound very familiar :-p).
### Ownership and atomic update model
Now that we have a solid update layer, which ensures that agreed upon
states will eventually be reflected on-chain, we can turn our attention
to the next layer up: the negotiation layer. Each output in our
agreed-upon state needs to be assigned one or more owners. The owners
are the participants that need to sign off on removal of an output and
the creation of new outputs which redistribute the funds contained in
the removed outputs to newly created outputs.
In addition we need to ensure that multiple `remove_output` and
`add_output` are guaranteed to be applied atomically. By creating a
datastructure that lists a number of operations that are to either be
applied to the current state or discarded, we can have arbitrary complex
changes of ownership, and the newly created outputs can have arbitrary
scripts.
If all of this sounds familiar that's because this is exactly the UTXO
model and the transaction structure we have in Bitcoin. We
collaboratively manage funds bound to some outputs (UTXO) and can change
their ownership and allocation over time (transactions).
This means that a subset of the participants in an off-chain contract
can negotiate among themselves how to redistribute funds, join and split
them in an arbitrary fashion, without the rest of the contract being
involved. The end result is a valid Bitcoin transaction that spends some
outputs of the current state, and is signed by the owners. The
transaction can then be presented to the entire group, and applied to
the state. Applying the transaction flattens multiple transactions built
on top of the current state into a new state (similar to transaction
cut-through in mimblewimble).
Using transactions as a means to represent off-chain negotiations, and
then applying them to the off-chain state via cut-through has a number
of advantages over similar schemes:
- Even if we failed to update the off-chain state, the transactions
building on top of it are valid transactions, so once we tear down
the channel, our negotiated new state can still be reached by
broadcasting the transaction after settlement (this is basically
what the channel factory paper [3] was using).
- We can reuse a lot of tools that we have already built for on-chain
transactions, including things like miniscript and hardware wallets,
without explicitly requiring them in our own specification. The
Bitcoin object model is our interface here.
- It allows for experimentation even inside a running eltoo instance. If
you can find another participant that supports a fancy new protocol,
you can use that protocol even though some of the other participants
may not know anything about it. As long as you can understand the
Bitcoin transaction model you can participate in a multi-party
channel.
I think this reconciliation between the off-chain model and the on-chain
model, with many concepts cleanly mapping from one context to another
(state outputs = UTXO, off-chain update = on-chain transactions,
cut-through = confirmation, operation batching = block creation) is
rather nice :-)
That should be enough rambling on my side. I'm interested in what others
think about this. Is it completely off, does it make no sense at all, or
is this something we should be looking into going forward?
Cheers,
Christian
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#received-htlc-outputs
[2] https://blockstream.com/eltoo.pdf
[3] https://tik-old.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable%5FFunding%5FOf%5FBlockchain%5FMicropayment%5FNetworks.pdf
|
