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
|
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 72DD4B62;
Thu, 19 Sep 2019 10:27:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com
[209.85.208.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88D6383A;
Thu, 19 Sep 2019 10:27:20 +0000 (UTC)
Received: by mail-ed1-f54.google.com with SMTP id r9so2679959edl.10;
Thu, 19 Sep 2019 03:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:cc:subject:in-reply-to:references:date:message-id
:mime-version; bh=i1QTpi+oIb94uFEPW89bveQ1XESLrhWJTNpnyF6RlpU=;
b=XBOTeFAui+EHUimMg1q9OIcf5XbR7McYBuf/wGfjf9MZTAhYlGPRft8EazrU1ztC/e
sO91RKfDsSWr6cUtD+GUZ2WeUnfswvuITNnsd/yrr/Mxuxism0H1Bx9IasQ0AD85Tn5+
dQ4IFaoXXcPDbXPkJN9aL41YIfqRWoEKDtdw+yQvGxvgaNroL0vgOB0Ze/w+qqb1aLsS
DQ9H28ESwK/X6w8dObKTyAOYbyO2zBVarXQ7pyUkN0d5AOylTg/+QHSOQIaf+Mm7DrQt
hNiI5Rt5lxQ2Y9mGE7c/er5KqzL/VAOLG9fkLYTf1s6aX48U9EmvnLhkjEg+80pIJKA5
8WNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date
:message-id:mime-version;
bh=i1QTpi+oIb94uFEPW89bveQ1XESLrhWJTNpnyF6RlpU=;
b=dHrPTBXvbSZI8HYfZutxXTRndt4NZVkKynVspGmFjgLnjN0LFlSEXRKbaFx8pGE32Q
iRFLYP6ZzJjffKPxCd0QNgDAUn0DYimJ8p1nhZV7Wv4+BQDlumicIoM11jTFu1xU4XKL
zhGRoVYPfjQbZkNum3sthdowS9S1LzWKAZKx8t3E5jsX+7R1hDGBU1NXjkZK61H3wrtr
S5XZtELmtGSiI9ZhG3MYEM/YC+ufknJFFMldEWDaNk/bfwn3X1U360QK1QYj9V8ruw6m
F8VE7lt/DNs2+g+t0e1Ch23xb+z6g0yrrZ+I14yswPgGtJiX6Od8E9KDsuMXRDB4m9lm
GdxQ==
X-Gm-Message-State: APjAAAVmTfydH52yvrxhgs0GRxnUt82iSQ1KblG8wsTCX3xVN2tTMKSm
qGddVFQqEIxnF2aGx1wdjco=
X-Google-Smtp-Source: APXvYqwiBsxkgr8cEmysgM04JCMBfcbX8C/nebpDHLOqy5KIEMKW3tSCUtxcIDHkIXjEBqhP4g1SFg==
X-Received: by 2002:a50:ef12:: with SMTP id m18mr15039497eds.18.1568888839094;
Thu, 19 Sep 2019 03:27:19 -0700 (PDT)
Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa])
by smtp.gmail.com with ESMTPSA id
l19sm1557260edb.50.2019.09.19.03.27.18
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 19 Sep 2019 03:27:18 -0700 (PDT)
From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.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>
<4YUElfSfClWLonv-Lkuq6KzBE5xCEJEc5VBTO04VxFJq9dmwBWQa4Qob_g5W3WFlACJ0sb6uNXtuZMCw-VOQV5O_6ACBQZB-ETr0pxcOmKw=@protonmail.com>
Date: Thu, 19 Sep 2019 12:26:13 +0200
Message-ID: <87sgos8tve.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>,
"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 10:27:21 -0000
ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:
>> 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 signatory 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 ability to run m nodes to outright steal money from you.
> * As processing power is cheap nowadays, there is no m that can be considered safe.
> Your alternative is to fall back on proof-of-work, but that just means 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 construction 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 in what they can do.
> And if the only "right" the n-1 participants can do is to force the nth participant to claim its funds onchain, then that is implementable with a transaction doing just that, which is pre-signed by the nth participant and given to participants 1..n-1.
Just to be clear, I do *not* want to support uncooperative splice-outs.
This is due to their need to either pre-sign a splice-out of the party
like I explained further down, or it requires encumbering whatever we
build on top in order to do a fast-reopen.
But I do think there is value in exploring what the options are :-)
>> 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 least partial ownership of, and keep only those that are owned
> only by the remaining members), then each member would have to
> honestly claim which UTXOs it is interested in keeping after it is
> kicked out of the membership set, defeating this point entirely. I
> believe this is roughly what you propose in the next point, and
> roughly what you would want with the "n-1 participants" earlier.
That is indeed the issue I explained further down:
> It also adds the complexity of having to identify which participant 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 my
> fallback and then becoming unresponsive (added rounds of communication
> can help here, but are cumbersome).
Claiming ownership would then involve providing a valid input script
(disregarding any timelocks) that could spend the output under some
condition. Others would have to verify this proof-of-ownership before
accepting the node's self-splice-out before accepting it.
>> 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 complexity for a small benefit" or similar?
Indeed, that was a weird sentence :-) I did mean that it is a lot of
complexity for very little benefit :-)
Cheers,
Christian
|
