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
|
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 29774416B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Mar 2019 08:07:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0519319B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 20 Mar 2019 08:07:09 +0000 (UTC)
Date: Wed, 20 Mar 2019 08:07:00 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1553069227;
bh=419oDM8t//txo6j/4tQ1RSyftkGSIV4C6f1njB+EiV4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=EXKIPaKY+VZQSoFvc2Gi2shr34S3Wj62RaSR5IRNc4hsYC1KtkXCoy3bQrZpAjg+x
ZKrDDoHRp9C36pcSXX5UEKfoikTOmuYO6hhmioMksjRNz9lQBsBWNSVEf3oVhGAIzV
jQK5hn5aubkRmSuITPAQABB5U9rcE10nETJxDxdg=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <isp2OcX23r-Tfl-WSbybuKnppjVlZV52AM1GGEaQd8uHlkliikUBvK49WOnzgaxOjDuOCNdu6CsmHt6kfK0z_FRrOgYAYWrWaDniZA3EEZQ=@protonmail.com>
In-Reply-To: <UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.com>
References: <20190313014143.ifffshwdux2jt7w5@erisian.com.au>
<87k1gubdjm.fsf@rustcorp.com.au> <87woku9q3g.fsf@rustcorp.com.au>
<UOdt33VfD8o6NfeDKMSip0hUmy1_jyo65-ihunuMRRg8IfXEOq-W60-TPoINm5HErPqnY_-yd1x_VnnVihrvtXRA2OHkjeROZheZ_QV0Zvo=@protonmail.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
X-Mailman-Approved-At: Wed, 20 Mar 2019 21:04:42 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] More thoughts on NOINPUT safety
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: Wed, 20 Mar 2019 08:07:12 -0000
Hi aj,
Re-reading again, I think perhaps I was massively confused by this:
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> <A> CHECKSIGVERIFY <B> CHECKSIG
> or <P> CHECKSIGVERIFY <Q> CHECKSIG
>
>
> where A is Alice's key and B is Bob's key, P is muSig(A,B) and Q is
> a key they both know the private key for. In the first case, Alice
> would give Bob a NOINPUT sig for the tx, and when Bob wanted to publish
> Bob would just do a SIGHASH_ALL sig with his own key. In the second,
> Alice and Bob would share partial NOINPUT sigs of the tx with P, and
> finish that when they wanted to publish.
Do you mean that *either* of the above two scripts is OK, *or* do you mean =
they are alternatives within a single MAST or `OP_IF`?
If you mean that *either* of the above two scripts is OK, then this script:
<muSig(A,B)> CHECKVERIFY <Q> CHECKSIG
should probably be used for Watchtower-compatibility.
When creating a new state, both A and B would cooperatively sign with `muSi=
g(A,B)` with a `SIGHASH_NOINPUT` that ensures the state transaction is corr=
ect.
Then they somehow derive or share the private key to `Q`.
In the blob sent to Watchtower, A (or B) includes the `SIGHASH_NOINPUT` as =
well as the `q` private key.
Would it be safe for Watchtower to know that?
Note that the above `Q` would need to be the same in the "state" trunk of t=
he Decker-Russell-Osuntokun construction.
So, building this, our initial setup transaction pays out to script:
<muSig(A_u,B_u)> CHECKVERIFY <Q> CHECKSIG
Then each update transaction pays out to:
OP_IF
<csv_delta> OP_CSV OP_DROP
<muSig(A_si,B_si)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ELSE
<i> OP_CHECKLOCKTIMEVERIFY OP_DROP
<muSig(A_u,B_u)> OP_CHECKSIGVERIFY <Q> OP_CHECKSIG
OP_ENDIF
The `SIGHASH_NOINPUT` signature for `muSig(A_u,B_u)` would then be sufficie=
nt to unlock the setup transaction, or any update transaction with lower `n=
LockTime`.
The watchtower would then have to generate the signature for `Q`, committin=
g to a particular UTXO.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Wednesday, March 20, 2019 3:38 PM, ZmnSCPxj via Lightning-dev <lightning=
-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> > Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> > scenario (as well as the second), I'd be content with that proposal.
>
> How would this work with watchtowers?
>
> As I understand it, the current plan for eltoo watchtowers would be to st=
ore both `SIGHASH_NOINPUT` signatures from both sides in the blob sent to t=
he watchtower.
>
> Then the watchtower can always attach this to whatever is the tipmost ava=
ilable on the chain of transactions.
>
> However, if one of the signatures MUST be non-`SIGHASH_NOINPUT` --- how d=
oes the watchtower create such a non-`SIGHASH_NOINPUT` signature?
>
> Regards,
> ZmnSCPxj
>
> > Future segwit versions may choose to relax it.[1]
> > Cheers,
> > Rusty.
> > [1] Must be consensus, not standardness; my prev suggestion was bogus.
> > Rusty Russell rusty@rustcorp.com.au writes:
> >
> > > Anthony Towns aj@erisian.com.au writes:
> > >
> > > > If you publish to the blockchain:
> > > > ...
> > > > 4 can be dropped, state 5 and finish can be altered). Since the CSV=
delay
> > > > is chosen by the participants, the above is still a possible scenar=
io
> > > > in eltoo, though, and it means there's some risk for someone accept=
ing
> > > > bitcoins that result from a non-cooperative close of an eltoo chann=
el.
> > >
> > > AJ, this was a meandering random walk which shed very little light.
> > > I don't find the differentiation between malicious and non-malicious
> > > double-spends convincing. Even if you trust A, you already have to
> > > worry about person-who-sent-the-coins-to-A. This expands that set to =
be
> > > "miner who mined coins sent-to-A", but it's very hard to see what
> > > difference that makes to how you'd handle coins from A.
> > >
> > > > Beyond that, I think NOINPUT has two fundamental ways to cause prob=
lems
> > > > for the people doing NOINPUT sigs:
> > > >
> > > > 1. your signature gets applied to a unexpectedly different
> > > > script, perhaps making it look like you've being dealing
> > > > with some blacklisted entity. OP_MASK and similar solves
> > > > this.
> > > >
> > >
> > > ... followed by two paragraphs describing how it's not a "fundamental
> > > way to cause problems" that you (or I) can see.
> > >
> > > > For the second case, that seems a little more concerning. The night=
mare
> > > > scenario is maybe something like:
> > > >
> > > > - naive users do silly things with NOINPUT signatures, and end up
> > > > losing funds due to replays like the above
> > > >
> > >
> > > As we've never seen with SIGHASH_NONE?
> > >
> > > > - initial source of funds was some major exchange, who decide it'=
s
> > > > cheaper to refund the lost funds than deal with the customer co=
mplaints
> > > >
> > > > - the lost funds end up costing enough that major exchanges just =
outright
> > > > ban sending funds to any address capable of NOINPUT, which also=
bans
> > > > all taproot/schnorr addresses
> > > >
> > >
> > > I don't find this remotely credible.
> > >
> > > > FWIW, I don't have a strong opinion here yet, but:
> > > >
> > > > - I'm still inclined to err on the side of putting more safety
> > > > measures in for NOINPUT, rather than fewer
> > > >
> > >
> > > In theory, sure. But not feel-good and complex "safety measures" whic=
h
> > > don't actually help in practical failure scenarios.
> > >
> > > > - the "must have a sig that commits to the input tx" seems like i=
t
> > > > should be pretty safe, not too expensive, and keeps taproot's p=
rivacy
> > > > benefits in the cases where you end up needing to use NOINPUT
> > > >
> > >
> > > If this is considered necessary, can it be a standardness rule rather
> > > than consensus?
> > > Thanks,
> > > Rusty.
> >
> > Lightning-dev mailing list
> > Lightning-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
|
