summaryrefslogtreecommitdiff
path: root/5e/582e329e7251efaa8ff63c7cfbf31f81323a07
blob: 889dd548ee5c33fc88f6d17e0b131ff8c62f92c8 (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
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
Return-Path: <rich@gotenna.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D833AC004C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Aug 2020 21:16:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id BA55A203AC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Aug 2020 21:16:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id etTTQL5-ZdkX
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Aug 2020 21:16:50 +0000 (UTC)
X-Greylist: delayed 01:49:22 by SQLgrey-1.7.6
Received: from mail-pf1-f227.google.com (mail-pf1-f227.google.com
 [209.85.210.227])
 by silver.osuosl.org (Postfix) with ESMTPS id 7695320003
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Aug 2020 21:16:50 +0000 (UTC)
Received: by mail-pf1-f227.google.com with SMTP id d188so12919543pfd.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 03 Aug 2020 14:16:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gotenna-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=VhCmZOxsUsNQyL5iN19Xf4D9GsZTbdWYzIV5HaoE6So=;
 b=AXiNR75P8QfjVlNBLAKXFnGxryDNafG7rKA+dnl6u7/7sTadXQ1FSaSqsG96lHLMyn
 5HJJM76JMeIGDqYmwjIhhjh/p7otWMnujIsZdv3U0FEmHvlJGinAeNAO9/VgBCHhZ56k
 DwUYS4XH/pHRccVzfaowQtv6nQD3+95uVfDs1kBNURuuj8gSLPtaZ8b0+lVrTsul+m8W
 GdTHOErGpylmlvkqEDng+NUEEQ7JKaJ+Yl/NB+ypREE12rhaV2ndYbc1AF6pj5R0X1cz
 MRyGOdGxN4mtfF/mVSN6IaFp5LEYT+ce6gEChmCS4D+fWGkZe8slzecNnuuTBETEWnCB
 l0TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=VhCmZOxsUsNQyL5iN19Xf4D9GsZTbdWYzIV5HaoE6So=;
 b=HZmOxf/1+ALPCONn08c06D61MCzcQ26A9RK11ZMC49ChPg3E2T4BNNZSJ8QqsDitkN
 zQWiIH1R2dJz3Y8iteWrGbuzF6urjKGUpwUwk+piUncytqQumMwDZjwhMo+Ibnu3ZepG
 qZ9WAAccbhVjyk0gb4BINleFWRBeO4vPE7lHr5snxLbvDx3lK3CtHoP4BX0JRhhoEtnv
 w8CNbUaJ+JPBU5uHMqHaxsK2WOL9433Ea/VrpUWUCDKjljxH7TB6b0VqNy6ilq+vqQmY
 tSW2T65DHyi0UXYE6cELXM2kGBQEzzU40lavnHX4raoLzdYVagM+BoxICHbNeo7m24dY
 0u6g==
X-Gm-Message-State: AOAM533nMa64RjPl0swdvuOHPbQ8brLiDJ/3M7yZ36fYrY+375nP7DCs
 BeF3zPyRQdnL7Udz83CyYcJ4UtYLA+yNYMcaMsqGvqTZzgKwpQ==
X-Google-Smtp-Source: ABdhPJygUjt8RYbtBg0nOtnfJpI+B/Tu5ebx8qM/dJdpwl9vOU5i850SjIiU4UMmClY9afj/IlCXo236cvZs
X-Received: by 2002:a62:19c4:: with SMTP id 187mr16890917pfz.312.1596482847755; 
 Mon, 03 Aug 2020 12:27:27 -0700 (PDT)
Received: from us2.smtp.exclaimer.net (us2.smtp.exclaimer.net. [104.209.35.28])
 by smtp-relay.gmail.com with ESMTPS id z6sm44293pjq.17.2020.08.03.12.27.27
 for <bitcoin-dev@lists.linuxfoundation.org>
 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
 Mon, 03 Aug 2020 12:27:27 -0700 (PDT)
X-Relaying-Domain: gotenna.com
Received: from mail-ed1-f71.google.com (209.85.208.71) by
 us2.smtp.exclaimer.net (104.209.35.28) with Exclaimer Signature Manager
 ESMTP Proxy us2.smtp.exclaimer.net (tlsversion=TLS12,
 tlscipher=TLS_ECDHE_WITH_AES256_SHA1); Mon, 3 Aug 2020 19:27:27 +0000
X-ExclaimerHostedSignatures-MessageProcessed: true
X-ExclaimerProxyLatency: 12673289
X-ExclaimerImprintLatency: 399986
X-ExclaimerImprintAction: 751862e0a47d4a9b9b4454b05a805c31
Received: by mail-ed1-f71.google.com with SMTP id cz26so968140edb.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 03 Aug 2020 12:27:26 -0700 (PDT)
X-Received: by 2002:a17:906:4acd:: with SMTP id
 u13mr18030509ejt.4.1596482844592; 
 Mon, 03 Aug 2020 12:27:24 -0700 (PDT)
X-Received: by 2002:a17:906:4acd:: with SMTP id
 u13mr18030494ejt.4.1596482844341; 
 Mon, 03 Aug 2020 12:27:24 -0700 (PDT)
MIME-Version: 1.0
References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au>
 <O_Zr7tM2TYwJdFS0o9RraXrtRPI4ZcVU65qcBpg-tvTPOqnGWkEUDQY5XqcihbUyAHF31L4isFWsD_u2SsSb8YzfjYDWiVXQsr6oAd9YXBY=@protonmail.com>
In-Reply-To: <O_Zr7tM2TYwJdFS0o9RraXrtRPI4ZcVU65qcBpg-tvTPOqnGWkEUDQY5XqcihbUyAHF31L4isFWsD_u2SsSb8YzfjYDWiVXQsr6oAd9YXBY=@protonmail.com>
From: Richard Myers <rich@gotenna.com>
Date: Mon, 3 Aug 2020 21:27:13 +0200
Message-ID: <CACJVCgL+Ap9VBsDQp+KEuwhAkPZ1c0ACBRjHnB_qk-hi8_Uq7Q@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d3fcb605abfe20af"
X-Mailman-Approved-At: Mon, 03 Aug 2020 21:33:51 +0000
Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_ANYPREVOUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 03 Aug 2020 21:16:52 -0000

--000000000000d3fcb605abfe20af
Content-Type: text/plain; charset="UTF-8"

Thanks AJ for the updated BIP - very exciting!

I'm also interested in this in the context of a Taproot version of
Decker-Russell-Osuntokun (eltoo). Thanks ZmnSCPxj for summarizing your
thoughts on how this would work. I have had some difficulty understanding
when someone might want to use ANYPREVOUT vs. ANYPREVOUTANYSCRIPT and this
is a clever demonstration of how the differences can be exploited.

I sketched out the protocol you described to help my understand it (below)
and some questions came to mind:

1) If you do a collaborative close, would you need to use script-path
spending, or could you use key-path spending instead to improve privacy?

2) You mention 1.5 round trips for the (two party) MuSig signing session.
Must there be separate 1.5 round trips for each of the two signatures
produced (update, settlement) for each state update?

3) A related question: can the 1.5 round trips for signing be combined with
the 1.5 round trips required to update the channel (ie. A signs settlement
tx, B signs settlement & update txs, A signs update tx)?

Perhaps something like this:
 -> A provides partial signature for settlement tx
 <- B provides complete signature for settlement tx and partial signature
for update tx
 -> A provides complete signature for update tx

4) I'm not sure why AJ's formulation included an addition sig(X), but
otherwise is it similar to what you're suggesting?

https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-May/001996.html

All the best,

  -- Richard

------- my interpretation of your scheme ----


  [Fund Channel]
    |
    |
    |
    v
   P=Musig(A,B)+scripts (Taproot internal key, aka script path key?)
   Q=Musig(A,B) (Taproot output key, aka root key?)

   OR ----------- [Cooperative Close]
   |||            Sig(Q) -----+
   |||                        |----> Sig(A)...
   |||                        |
   |||                        |----> Sig(B)...
   |||
   |||
   ||+-->[Update(n)]
   ||    nlocktime/state > n
   ||    Sig(P)+ANYPREVOUTANYSCRIPT
   ||
   ||     OR ---------->[Settle(n)]           [Uncooperative Close @
state n]
   ||      |            Sig(P)+ANYPREVOUT
   ||      |            csv [delay] --------+---> Sig(A)...    [HTLCs
& Settled
   ||      |                                |
Outputs ]
   ||      |                                |---> Sig(B)...
   ||      v
   |+---->[Update(n+1)]
   |      nlocktime/state > n+1
   |      Sig(P)+ANYPREVOUTANYSCRIPT
   |
   |      OR ----------->[Settle(n+1)]        [Uncooperative Close @
state n+1]
   |       |             Sig(P)+ANYPREVOUT
   |       |             csv [delay] -------+---> Sig(A)...    [HTLCs
& Settled
   |       |                                |
Outputs ]
   v       v                                |---> Sig(B)...





On Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

...

> Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction
> could, in theory, have only a single internal taproot pubkey, `P = MuSig(A,
> B)` for a channel between A and B.
>
> So the funding outpoint would be spent with a taprooted P + a single
> tapscript `<1> OP_CHECKSIG`.
>
> Update transactions would be signed with the internal taproot pubkey using
> `SIGHASH_ANYPREVOUTANYSCRIPT`.
> The update transaction output would be spendable with a taprooted P + a
> single tapscript `<index + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <1>
> OP_CHECKSIG`.
> Each update transaction would have a monotonically-increasing `nLockTime`,
> i.e. the above `index`.
>
> Then a state transaction would be signed with the internal taproot pubkey
> using `SIGHASH_ANYPREVOUT`, which commits to the exact script including
> `<index + 1>`, which is unique for each update transaction.
> Thus a state transaction can only spend the specific update transaction,
> but the update transaction can spend the funding outpoint or any update
> transaction outpoint.
> State transaction input would have an `nSequence` requiring a relative
> locktime of the agreed-upon unilateral close delay.
>
> The above assumes MuSig signing, which requires 1.5 round trips for a
> channel, or three broadcast rounds for a multiparticipant (n >= 3)
> construction.
>
>
> Regards,
> ZmnSCPxj
>
>

--000000000000d3fcb605abfe20af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Thanks =
AJ for the updated BIP - very exciting!<br><br>I&#39;m also interested in t=
his in the context of a Taproot version of Decker-Russell-Osuntokun (eltoo)=
.=C2=A0Thanks ZmnSCPxj for summarizing your thoughts on how this would work=
. I have had some difficulty understanding when someone might want to use A=
NYPREVOUT vs. ANYPREVOUTANYSCRIPT and this is a clever demonstration of how=
 the=C2=A0differences can be exploited.</div><div dir=3D"ltr"><br></div><di=
v>I sketched out the protocol you described to help my understand it (below=
) and some questions came to mind:</div><div><br></div><div>1) If you do a =
collaborative close, would you need to use script-path spending, or could y=
ou use key-path spending instead to improve privacy?</div><div><br></div><d=
iv>2) You mention 1.5 round trips for the (two party) MuSig signing session=
. Must there be separate 1.5 round trips for each of the two signatures pro=
duced (update, settlement) for each state update?</div><div><br></div><div>=
3) A related question: can the 1.5 round trips for signing be combined with=
 the 1.5 round trips required to update the channel (ie. A signs settlement=
 tx, B signs settlement &amp; update txs, A signs update tx)?=C2=A0</div><d=
iv><br></div><div>Perhaps something like this:</div><div>=C2=A0-&gt; A prov=
ides partial signature for settlement tx</div><div>=C2=A0&lt;- B provides c=
omplete signature for settlement tx and partial signature for update tx</di=
v><div>=C2=A0-&gt; A provides complete signature for update tx</div><div><b=
r></div><div>4) I&#39;m not sure why AJ&#39;s formulation included an addit=
ion sig(X), but otherwise is it similar to what you&#39;re suggesting?</div=
><div>=C2=A0=C2=A0<a href=3D"https://lists.linuxfoundation.org/pipermail/li=
ghtning-dev/2019-May/001996.html">https://lists.linuxfoundation.org/piperma=
il/lightning-dev/2019-May/001996.html</a></div><div><br></div><div>All the =
best,</div><div><br></div><div>=C2=A0 -- Richard</div><div><br></div><div>-=
------ my interpretation of your scheme ----<span style=3D"color:rgb(0,0,0)=
">=C2=A0</span></div><div><span style=3D"color:rgb(0,0,0)"><br></span></div=
><div><pre class=3D"gmail-result--content--pre" style=3D"margin-top:0px;mar=
gin-bottom:0px;padding:0px;overflow:hidden;line-height:1.2em;color:rgb(0,0,=
0)">                                                                       =
                 =20
  [Fund Channel]                                                           =
             =20
    |                                                                      =
             =20
    |                                                                      =
             =20
    |                                                                      =
             =20
    v                                                                      =
             =20
   P=3DMusig(A,B)+scripts (Taproot internal key, aka script path key?)     =
               =20
   Q=3DMusig(A,B) (Taproot output key, aka root key?)                      =
               =20
                                                                           =
             =20
   OR ----------- [Cooperative Close]                                      =
             =20
   |||            Sig(Q) -----+                                            =
             =20
   |||                        |----&gt; Sig(A)...                          =
                =20
   |||                        |                                            =
             =20
   |||                        |----&gt; Sig(B)...                          =
                =20
   |||                                                                     =
             =20
   |||                                                                     =
             =20
   ||+--&gt;[Update(n)]                                                    =
                =20
   ||    nlocktime/state &gt; n                                            =
                =20
   ||    Sig(P)+ANYPREVOUTANYSCRIPT                                        =
             =20
   ||                                                                      =
             =20
   ||     OR ----------&gt;[Settle(n)]           [Uncooperative Close @ sta=
te n]           =20
   ||      |            Sig(P)+ANYPREVOUT                                  =
             =20
   ||      |            csv [delay] --------+---&gt; Sig(A)...    [HTLCs &a=
mp; Settled         =20
   ||      |                                |                   Outputs ]  =
             =20
   ||      |                                |---&gt; Sig(B)...             =
                =20
   ||      v                                                               =
             =20
   |+----&gt;[Update(n+1)]                                                 =
                =20
   |      nlocktime/state &gt; n+1                                         =
                =20
   |      Sig(P)+ANYPREVOUTANYSCRIPT                                       =
             =20
   |                                                                       =
             =20
   |      OR -----------&gt;[Settle(n+1)]        [Uncooperative Close @ sta=
te n+1]         =20
   |       |             Sig(P)+ANYPREVOUT                                 =
             =20
   |       |             csv [delay] -------+---&gt; Sig(A)...    [HTLCs &a=
mp; Settled         =20
   |       |                                |                   Outputs ]  =
             =20
   v       v                                |---&gt; Sig(B)...             =
                 </pre></div><div><span style=3D"color:rgb(0,0,0)">=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><br></div><pre style=3D"margin=
-top:0px;margin-bottom:0px;padding:0px;overflow:hidden;line-height:1.2em;co=
lor:rgb(0,0,0)">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<pre class=3D"gmail-result--content--pre"=
 style=3D"margin-top:0px;margin-bottom:0px;padding:0px;overflow:hidden;line=
-height:1.2em"><span style=3D"font-family:Arial,Helvetica,sans-serif;color:=
rgb(34,34,34)">On Fri, Jul 10, 2020 at 5:30 AM ZmnSCPxj via bitcoin-dev &lt=
;</span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank" style=3D"font-family:Arial,Helvetica,sans-serif">bitcoin-dev@lists.=
linuxfoundation.org</a><span style=3D"font-family:Arial,Helvetica,sans-seri=
f;color:rgb(34,34,34)">&gt; wrote:</span><br></pre></pre></div></div><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">...</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
Slightly off-topic, but I suppose a Decker-Russell-Osuntokun construction c=
ould, in theory, have only a single internal taproot pubkey, `P =3D MuSig(A=
, B)` for a channel between A and B.<br>
<br>
So the funding outpoint would be spent with a taprooted P + a single tapscr=
ipt `&lt;1&gt; OP_CHECKSIG`.<br>
<br>
Update transactions would be signed with the internal taproot pubkey using =
`SIGHASH_ANYPREVOUTANYSCRIPT`.<br>
The update transaction output would be spendable with a taprooted P + a sin=
gle tapscript `&lt;index + 1&gt; OP_CHECKLOCKTIMEVERIFY OP_DROP &lt;1&gt; O=
P_CHECKSIG`.<br>
Each update transaction would have a monotonically-increasing `nLockTime`, =
i.e. the above `index`.<br>
<br>
Then a state transaction would be signed with the internal taproot pubkey u=
sing `SIGHASH_ANYPREVOUT`, which commits to the exact script including `&lt=
;index + 1&gt;`, which is unique for each update transaction.<br>
Thus a state transaction can only spend the specific update transaction, bu=
t the update transaction can spend the funding outpoint or any update trans=
action outpoint.<br>
State transaction input would have an `nSequence` requiring a relative lock=
time of the agreed-upon unilateral close delay.<br>
<br>
The above assumes MuSig signing, which requires 1.5 round trips for a chann=
el, or three broadcast rounds for a multiparticipant (n &gt;=3D 3) construc=
tion.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br><br></blockquote></div><div dir=3D"ltr"><div></div></div></div>

--000000000000d3fcb605abfe20af--