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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 550EDAB2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Dec 2018 21:24:05 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6FE6710
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 24 Dec 2018 21:24:04 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1545686632; cv=none; d=zoho.com; s=zohoarc;
b=IVeRANVvFaXXt7YTX7d75LGgb1sITyiVC9Kl7CddOkjLe4CR0M4tmupGjeYusauq/XRwwHR3xHZplQZUoVgqpyCQFsoQlwH0B+q3rCG21wQp6mL3lkPEdvRHF+2E7+4G68VwwM6/fU5ekckDuOn6YOBZ9FGolK+S2qmw7TMr68Q=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1545686632;
h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=IDlBmxphEdiTFXj+OkQI8iPjOV29XMkMwc2qgvvgHVU=;
b=j257rFLYPj6Q5xcX2BOt/MvbbTeiCKSSje+pMTzYo56kNDyGfnrgaaO/4sbT8qksHwPKwD8fDVrGlCUoDV3YrchawhrfH6GDCyKUaEhKrzu5haT1vcJcOOTZfxXennOpXu/qeVEmdhKfhfSXVLUVhvDhMR4up+z0YtiFossgVKE=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1545686630525322.7577141590385;
Mon, 24 Dec 2018 13:23:50 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <4CE7B999-F1C3-4E7F-BCED-E02C5D0BE4BB@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_BDB34EED-0A74-47E7-A74D-0CAE21F1746F"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Tue, 25 Dec 2018 05:23:44 +0800
In-Reply-To: <_gOQU8sPtEG5jisR7GskWPyvzLK1xixz8-v1YbRWlAXFq9YGPyMEj9Q-xZ6CYfwgiGeJR2Qlboq4UFU_y6pur1HBG_yRTIgngWqiENmJ1Bc=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <87ftv3xerx.fsf@rustcorp.com.au>
<20181214093002.p2nvfrlaycqblww3@erisian.com.au>
<F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk>
<87mup4hmq5.fsf@rustcorp.com.au>
<2302A26C-FB9C-47D2-AF6C-4D2EF02FFAC0@xbt.hk>
<87y38jn5z8.fsf@rustcorp.com.au>
<73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk>
<20181223042659.munrqfe4l6nff2ug@erisian.com.au>
<F445FD1D-52E2-41E4-8FBD-3419A6317CF6@xbt.hk>
<_gOQU8sPtEG5jisR7GskWPyvzLK1xixz8-v1YbRWlAXFq9YGPyMEj9Q-xZ6CYfwgiGeJR2Qlboq4UFU_y6pur1HBG_yRTIgngWqiENmJ1Bc=@protonmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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
X-Mailman-Approved-At: Tue, 25 Dec 2018 04:22:45 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
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: Mon, 24 Dec 2018 21:24:05 -0000
--Apple-Mail=_BDB34EED-0A74-47E7-A74D-0CAE21F1746F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I find another proposed use of CODESEPARATOR here: =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/00045=
5.html =
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/0004=
55.html>
<KeyA> OP_CHECKSIG
OP_IF
<KeyB>
OP_ELSE
<Delay> OP_CSV OP_DROP
OP_CODESEPARATOR <KeyA>
OP_ENDIF
OP_CHECKSIG
It is actually 2 scripts:
S1: <KeyA> OP_CHECKSIGVERIFY <KeyB> OP_CHECKSIG
S2: <Delay> OP_CSV OP_DROP <KeyA> OP_CHECKSIG
Under taproot, we could make Q =3D P + H(P||S2)G, where P =3D =
MuSig(KeyA, KeyB)
S1 becomes a direct spending with Q, and there is no need to use OP_IF =
or CODESEPARATOR in S2 at all.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If it is only to force R reuse, there is no need to use CODESEPARATOR:
Input: <R> <S2> <S1> Script: 2DUP EQUAL NOT VERIFY 2 PICK SWAP CAT =
<key> DUP TOALTSTACK CHECKSIGVERIFY CAT FROMALTSTACK CHECKSIG
But using CODESEPARATOR will save 3 bytes
Input: <S2> <R> <S1> Script: OVER SWAP CAT <key> DUP TOALTSTACK =
CHECKSIGVERIFY CODESEPARATOR SWAP CAT FROMALTSTACK CHECKSIG
However, a much better way would be:
Input: <S> Script: <known R> SWAP CAT <key> CHECKSIG
The discrete log of R could be a shared secret between A and B. If the =
purpose is to publish the private key to the whole world, R =3D G could =
be used.
> On 24 Dec 2018, at 8:01 PM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning,
>=20
>> Could anyone propose a better use case of CODESEPARATOR?
>=20
> Long ago, aj sent an email on Lightning-dev about use of CODESEPARATOR =
to impose Scriptless Script even without Schnorr. It involved 3 =
signatures with different CODESEPARATOR places, and forced R reuse so =
that the signatures to claim the funds revealed the privkey.
>=20
> The script shown had all CODESEPARATOR in a single branch.
>=20
> I cannot claim to understand the script, and am having difficulty =
digging through the mailinglist
>=20
> Regards,
> ZmnSCPxj
--Apple-Mail=_BDB34EED-0A74-47E7-A74D-0CAE21F1746F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">I =
find another proposed use of CODESEPARATOR here: <a =
href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-Mar=
ch/000455.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-=
March/000455.html</a><div class=3D""><br class=3D""></div><div =
class=3D""><pre style=3D"white-space: pre-wrap; font-variant-ligatures: =
normal; orphans: 2; widows: 2;" class=3D""><KeyA> OP_CHECKSIG
OP_IF
<KeyB>
OP_ELSE
<Delay> OP_CSV OP_DROP
OP_CODESEPARATOR <KeyA>
OP_ENDIF
OP_CHECKSIG</pre><div class=3D"">It is actually 2 scripts:</div><div =
class=3D""><br class=3D""></div><div class=3D"">S1: <span =
style=3D"orphans: 2; white-space: pre-wrap; widows: 2;" =
class=3D""><KeyA> OP_CHECKSIGVERIFY </span><span style=3D"orphans: =
2; white-space: pre-wrap; widows: 2;" class=3D""><KeyB> =
OP_CHECKSIG</span></div><div class=3D""><span style=3D"orphans: 2; =
white-space: pre-wrap; widows: 2;" class=3D"">S2: </span><span =
style=3D"orphans: 2; white-space: pre-wrap; widows: 2;" =
class=3D""><Delay> OP_CSV OP_DROP <KeyA> </span><span =
style=3D"orphans: 2; white-space: pre-wrap; widows: 2;" =
class=3D"">OP_CHECKSIG</span></div><div class=3D""><br =
class=3D""></div><div class=3D"">Under taproot, we could make Q =3D P + =
H(P||S2)G, where P =3D MuSig(KeyA, KeyB)</div><div class=3D""><br =
class=3D""></div><div class=3D"">S1 becomes a direct spending with Q, =
and there is no need to use OP_IF or CODESEPARATOR in S2 at =
all.</div><div class=3D""><br class=3D""></div><div class=3D""><br =
class=3D""></div><div class=3D"">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D</div><div class=3D""><br class=3D""></div><div class=3D"">If =
it is only to force R reuse, there is no need to use =
CODESEPARATOR:</div><div class=3D""><br class=3D""></div><div =
class=3D"">Input: <R> <S2> <S1> Script: =
2DUP EQUAL NOT VERIFY 2 PICK SWAP CAT <key> DUP TOALTSTACK =
CHECKSIGVERIFY CAT FROMALTSTACK CHECKSIG</div><div class=3D""><br =
class=3D""></div><div class=3D"">But using CODESEPARATOR will save 3 =
bytes</div><div class=3D"">Input: <S2> <R> <S1> =
Script: OVER SWAP CAT <key> DUP TOALTSTACK =
CHECKSIGVERIFY CODESEPARATOR SWAP CAT FROMALTSTACK CHECKSIG</div><div =
class=3D""><br class=3D""></div><div class=3D""><div>However, a much =
better way would be:</div><div><br class=3D""></div><div>Input: =
<S> Script: <known R> SWAP CAT <key> =
CHECKSIG</div><div><br class=3D""></div><div>The discrete log of R could =
be a shared secret between A and B. If the purpose is to publish the =
private key to the whole world, R =3D G could be used.</div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 24 =
Dec 2018, at 8:01 PM, ZmnSCPxj <<a =
href=3D"mailto:ZmnSCPxj@protonmail.com" =
class=3D"">ZmnSCPxj@protonmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Good =
morning,<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">Could anyone propose a better use case of CODESEPARATOR?<br =
class=3D""></blockquote><br class=3D"">Long ago, aj sent an email on =
Lightning-dev about use of CODESEPARATOR to impose Scriptless Script =
even without Schnorr. It involved 3 signatures with different =
CODESEPARATOR places, and forced R reuse so that the signatures to claim =
the funds revealed the privkey.<br class=3D""><br class=3D"">The script =
shown had all CODESEPARATOR in a single branch.<br class=3D""><br =
class=3D"">I cannot claim to understand the script, and am having =
difficulty digging through the mailinglist<br class=3D""><br =
class=3D"">Regards,<br class=3D"">ZmnSCPxj<br =
class=3D""></div></div></blockquote></div><br =
class=3D""></div></div></body></html>=
--Apple-Mail=_BDB34EED-0A74-47E7-A74D-0CAE21F1746F--
|
