summaryrefslogtreecommitdiff
path: root/0c/fbfb62475357bfef5b0574b13a9d40f8d771d0
blob: d40423ad3fc3a6dcbd31d914982751966a2712e2 (plain)
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
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 06D77104F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 19 Sep 2019 02:02:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
	[185.70.40.130])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA1B48A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 19 Sep 2019 02:02:01 +0000 (UTC)
Date: Thu, 19 Sep 2019 02:01:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
	s=default; t=1568858518;
	bh=Rf9J0A+E7/JbCsBkcrIFmsdCT0+wUI+TMxwwCY6WEYs=;
	h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
	Feedback-ID:From;
	b=hu4Xe7IN1zOgqxPb0Igj0eIJLtE317Duue2IZtAMvXues2fYGaTfQ57SIwRU9CglW
	Lziw8yV06aH76m7eMT4kEh0wvQxjRw49W41ScJwaSQttivBHyZ8gFjZf/vVcM+nubW
	zzF53j242Bfflc6RvZ0Kj01OKxvbT8mBchyhArUU=
To: Christian Decker <decker.christian@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>
In-Reply-To: <87ef0doh0w.fsf@gmail.com>
References: <87mufhva0k.fsf@gmail.com>
	<G_LSM42y_gQFNVrTfHHN5hqR_foZU6AlOJkfz9zMDLFyQGdk4opZ14QC97w2rjrw4UmWTwEkJDKEc_eUMItdmxEsQOl7S-gBO2y8ovFPBc0=@protonmail.com>
	<CACJVCgLe-hmSoPZtsXBMDToqa-rh04EroppO14zBQqEjdWacQw@mail.gmail.com>
	<RQVxRFj-yzhYfEPMZhVrSYCaEvFhRrlxkSI-sYmqwEE7bRO6hKPV-vdB2ijcFYND-2x_5esnr7aofW6-74B3mHFLiLlHm-FM4WPeiJo-GhQ=@protonmail.com>
	<CACJVCg+wuODW-NoNoAvwdcnr0gZbLFrDyip6-0unw9hFu2-oOg@mail.gmail.com>
	<ccotpmyCthtmIqi2aqT6DaWAF_BEYSQh5vPnz9nmVu-zemfA3utpaDsb1Xn1jqaIXlRUzHwS7UlMHR_LJE27pzARxuUCu7PM6w6MEXrL8p8=@protonmail.com>
	<87ef0doh0w.fsf@gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
	RCVD_IN_DNSWL_LOW 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>,
	"lightning-dev\\@lists.linuxfoundation.org"
	<lightning-dev@lists.linuxfoundation.org>, Richard Myers <rich@gotenna.com>
Subject: Re: [bitcoin-dev] [Lightning-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: Thu, 19 Sep 2019 02:02:04 -0000

Good morning Christian, and list,


> > > uncooperative membership change:
> > >
> > > -   a subset of channel parties might want to cooperatively sign a ch=
annel splicing transaction to 'splice out' uncooperative parties
> >
> > I believe this is currently considered unsafe.
> > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/00=
1975.html
> > Unless you refer to another mechanism...?
> > I believe this will end up requiring deep confirmation of the
> > uncooperative close followed by a new mechanism open.
>
> Not necessarily. If we have an escape hatch in the scripts that allows
> to spend any output attached to the settlement transaction by n-1
> participants we could reclaim these into a new open right away.

This would have to be very very carefully designed.
The entire point of requiring an n-of-n signature is:

* By using an n-of-n signatory where *you* are a signer, you are completely=
 immune to Sybil attacks: even if everybody other than *you* in the signato=
ry set is secretly just one entity, this is no different from doing a 2-of-=
2 bog-standard boring sleepy Zzzzzz Poon-Dryja Lightning Network channel.
  * Any m-of-n signatory where strictly m < n allows anybody with the abili=
ty to run m nodes to outright steal money from you.
    * As processing power is cheap nowadays, there is no m that can be cons=
idered safe.
      Your alternative is to fall back on proof-of-work, but that just mean=
s going onchain, so you might as well just do things onchain.
  * This is why 2-of-2 channels work so well, it's the minimum useable cons=
truction and any multiparty construction, when Sybilled, devolves to a 2-of=
-2 channel.

So the n-1 participants would have to be very very very carefully limited i=
n what they can do.
And if the only "right" the n-1 participants can do is to force the nth par=
ticipant to claim its funds onchain, then that is implementable with a tran=
saction doing just that, which is pre-signed by the nth participant and giv=
en to participants 1..n-1.

> > > mining, mining reward and difficulty adjustment
> > >
> > > -   no equivalent concept for multi-party channels
> >
> > Fees for each update. Consider how HTLC routing in Lightning
> > implicitly pays forwarding nodes to cooperate with the forwarding. I
> > imagine most nodes in a multiparticipant offchain system will want to
> > be paid for cooperation, even if just a nominal sub-satoshi amount.
>
> If we allow generic contracts on top of the base update mechanism it'll
> be rather difficult to identify the beneficiary of an update, so it's
> hard to know who should pay a fee. I'd rather argue that cooperating is
> in the interest of all participants since they'd eventually want to
> create an update of their own, and there is no upside to become
> unresponsive.
>
> Notice that the fees we leverage in LN are because we expose our funds
> to the risk of not being available by allocating them to an HTLC, not
> for the updates themselves. Since in the forwarding scenario we're only
> exposing the funds of the forwarding nodes to this risk it's only
> natural that they'd be the ones leveraging a fee, not the other
> participants that simply sign off on the change.

I suppose that could be argued.

However, I imagine it is possible for some of the updates to be implementab=
le via HTLCs within sub-mechanisms of the higher mechanism.
If so, a participant may refuse to sign for the higher mechanism in order t=
o force others to use HTLCs on the lower mechanisms, and thereby earn fees =
due to HTLC usage.
I believe I argue as much here: https://lists.linuxfoundation.org/pipermail=
/lightning-dev/2019-July/002055.html

> ZmnSCPxj can request a factory channel reorganization to move some funds =
from the ZmnSCPxj<->Rene channel to the ZmnSCPxj<->YAijbOJA channel.
> This has the same effect, i.e. it allows a forwarding attempt to push thr=
ough, that would not be possible without the factory-level channel reorgani=
zation.
>
> Further, assuming only ZmnSCPxj, YAijbOJA, and Rene are in the channel fa=
ctory, then it is the same: all three need to be online in order for the JI=
T-routing to work.
>
> But I observed above that, in a channel rebalance using current channels =
(without factories) Rene cannot be convinced to waive the fee.

The counterargument above is that if rebalances can be made fee-free, then =
the above argument disappears.


>
> > > privacy:
> > >
> > > -   disassociate a particular update from signer(s)
> > > -   disassociate IP address of signers from signature
> > > -   using SIGHASH_ALL for cooperative closes
> >
> > I suppose Tor can be used to disassociate IP address from signers if
> > everyone is from a hidden service. However, we need to include some
> > kind of mix mechanism to allow individual signers to disassociate
> > their ownership of funds from their identity as signers. Though such
> > mechanisms already exist as theoretical constructs, so "just needs
> > implementing".
> > But then again: if you own funds in the mechanism, you should be a
> > signer (else you are trusting a federation). So a basic fact here is
> > that if you are a participant in some offchain mechanism, you are
> > likely (approaching 100% probability) to own money in it.
>
> Notice that we are negotiating whether or not to apply generic
> transactions to a shared state. This also means that there is no direct
> relationship between the ownership of an output and the ID signing off
> on a change.
>
> The privacy guarantees are identical to Bitcoin on-chain, with the one
> caveat that we may identify the proposing participant, but we can defend
> against this by mixing as you propose.

Yes, but if we later combine this with allowing multiilateral kick-out of a=
 member that is unresponsive (i.e. we splice out the outputs it has at leas=
t partial ownership of, and keep only those that are owned only by the rema=
ining members), then each member would have to honestly claim which UTXOs i=
t is interested in keeping after it is kicked out of the membership set, de=
feating this point entirely.
I believe this is roughly what you propose in the next point, and roughly w=
hat you would want with the "n-1 participants" earlier.

>
> > > liveness:
> > >
> > > -   if signers know they will be offline, can they pre-sign updates t=
hat just commit their own outputs, rather then splice out?
> > > -   contingent tap-leafs to splice out non-responsive signers
> >
> > It might be possible to create a new mechanism-within-mechanism layer,
> > if a signer knows they will be offline.
> > For example, suppose entities A, B, and C have an offchain update
> > mechanism, which we shall call a "factory". Suppose this factory
> > contains an A-B channel, a B-C channel, a A-C channel, and some funds
> > owned by B only. Then suppose A knows he or she will be offline for
> > some time. Before A goes offline, they can move from this UTXO set:
> >
> > -   A-B channel
> > -   B-C channel
> > -   A-C channel
> > -   B funds
> >
> > To this UTXO set:
> >
> > -   A-B channel
> > -   A-C channel
> > -   B-C offchain update mechanism (sub-factory), which itself has its o=
wn UTXO set:
> >     -   B-C channel
> >     -   B funds
> >
> > This allows B and C to manage the B-C channels and B funds without
> > cooperation of A. Then, later, when A returns online, the B-C
> > offchain update mechanism is collapsed back to the parent A-B-C
> > offchain update mechanism.
> > This assumes A knows it will be offline (which it might do for
> > e.g. regular maintenance, or software updates).
>
> We could theoretically play this game, having each participant create
> two updates with the same state-number at each update:
>
> 1.  A normal one that just keeps them in the contract
> 2.  A fallback splice all outputs they own (direct ones, HTLCs, ...) and
>     putting the rest back into a channel without them.
>
>     In case of one user becoming inactive the others can sign the splice,
>     dropping the inactive participant and continue like nothing
>     happened. The worst case scenario is that the normal update gets
>     broadcast and confirmed instead, which means we are back to the
>     unilateral close that we'd have to do anyway without this mechanism.
>
>     Notice however that this only works if participants drop off one by o=
ne,
>     otherwise we get a combinatorial explosion for the fallback cases whe=
re
>     each combination of inactive participants needs to splice themselves
>     out. It also adds the complexity of having to identify which particip=
ant
>     is the co-owner of an output, otherwise I can claim ownership of an
>     unrelated output and force that to move on-chain by including it in m=
y
>     fallback and then becoming unresponsive (added rounds of communicatio=
n
>     can help here, but are cumbersome).

This might be a plausible way of implementing the "n-1 participants can kic=
k out nth participant".

>
>     It may be a bit much added complexity for a small complexity to be
>     honest, hopefully this won't be needed too often :-)

Statement makes no sense, unless you meant to say "It may be a bit much com=
plexity for a small benefit" or similar?

Regards,
ZmnSCPxj