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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <me@thomaskerin.io>) id 1Yvqk4-00021Q-4u
for bitcoin-development@lists.sourceforge.net;
Fri, 22 May 2015 17:28:16 +0000
X-ACL-Warn:
Received: from static.204.212.9.5.clients.your-server.de ([5.9.212.204]
helo=thelaboratory.tk)
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Yvqjz-0007hV-Tq
for bitcoin-development@lists.sourceforge.net;
Fri, 22 May 2015 17:28:16 +0000
Received: from [192.168.192.39] (unknown [46.7.4.219])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: me@thomaskerin.io)
by thelaboratory.tk (Postfix) with ESMTPSA id 80F489BA0976;
Fri, 22 May 2015 17:28:04 +0000 (UTC)
Message-ID: <555F6722.7000103@thomaskerin.io>
Date: Fri, 22 May 2015 18:28:02 +0100
From: Thomas Kerin <me@thomaskerin.io>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net,
Gregory Maxwell <gmaxwell@gmail.com>
References: <54DD1E3F.60006@thomaskerin.io> <201502122213.34765.luke@dashjr.org>
<54DE8C1C.60804@thomaskerin.io>
In-Reply-To: <54DE8C1C.60804@thomaskerin.io>
OpenPGP: url=http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155
Content-Type: multipart/alternative;
boundary="------------010006010900090308040004"
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1Yvqjz-0007hV-Tq
Subject: Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash
multi-signature addresses
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 22 May 2015 17:28:16 -0000
This is a multi-part message in MIME format.
--------------010006010900090308040004
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I wonder are there any other blockers or modifications that need to be
made for this to be merged?
Latest version of the document:
https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki
On 13/02/15 23:43, Thomas Kerin wrote:
>
> On 12/02/15 22:13, Luke Dashjr wrote:
>> Where is the Specification section?? Does this support arbitrary
scripts, or
>> only the simplest CHECKMULTISIG case?
>
> The BIP is a process for deriving only the type of scripts you would
encounter doing addmultisigaddress. More complicated scripts would
require more metadata to be shared, but the only case we describe is
when given public keys and the number of signatures required.
>
> You're right, we're missing a Specification. I have tweaked the
document to cover this now.
>
>
>
> On 13/02/15 07:53, Peter Todd wrote:
>> It might be enough to rewrite this BIP to basically say "all pubkeys
executed by all CHECKMULTISIG opcodes will be in the following canonical
order", followed by some explanatory examples of how to apply this
simple rule. OTOH we don't yet have a standard way of even talking about
arbitrary scripts, so it may very well turn out to be the case that the
above rule is too restrictive in many cases - I certainly would not want
to do a soft-fork to enforce this, or even make it an IsStandard() rule.
>
> It would be interesting, but I agree it should not be brought into
these validation rules - just a convention for people to follow for now.
I think it's fair that implementers are free to order them however they
please. But I think there is good reason for wallets to opt in to the
convention and declare this, for ease of recovery, and for
interoperability reasons.
>
>
> --
> Thomas Kerin
> -------------------------
> My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
>
>
>
------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media,
is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQJ8BAEBCgBmBQJVX2ciXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA
gz9kb4pJMEhTtZNv7z9C
=iq37
-----END PGP SIGNATURE-----
--------------010006010900090308040004
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
I wonder are there any other blockers or modifications that need to
be made for this to be merged?<br>
<br>
Latest version of the document:
<a class="moz-txt-link-freetext" href="https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki">https://github.com/afk11/bips/blob/213e8a27a3a2eaaf44f79221a9f9f888af002801/bip-0067.mediawiki</a><br>
<br>
<br>
<br>
On 13/02/15 23:43, Thomas Kerin wrote:<br>
<span style="white-space: pre;">><br>
> On 12/02/15 22:13, Luke Dashjr wrote:<br>
>> Where is the Specification section?? Does this support
arbitrary scripts, or <br>
>> only the simplest CHECKMULTISIG case?<br>
><br>
> The BIP is a process for deriving only the type of scripts
you would encounter doing addmultisigaddress. More complicated
scripts would require more metadata to be shared, but the only
case we describe is when given public keys and the number of
signatures required.<br>
><br>
> You're right, we're missing a Specification. I have tweaked
the document to cover this now.<br>
><br>
><br>
><br>
> On 13/02/15 07:53, Peter Todd wrote:<br>
>> It might be enough to rewrite this BIP to basically say
"all pubkeys executed by all CHECKMULTISIG opcodes will be in the
following canonical order", followed by some explanatory examples
of how to apply this simple rule. OTOH we don't yet have a
standard way of even talking about arbitrary scripts, so it may
very well turn out to be the case that the above rule is too
restrictive in many cases - I certainly would not want to do a
soft-fork to enforce this, or even make it an IsStandard() rule.<br>
><br>
> It would be interesting, but I agree it should not be brought
into these validation rules - just a convention for people to
follow for now. I think it's fair that implementers are free to
order them however they please. But I think there is good reason
for wallets to opt in to the convention and declare this, for ease
of recovery, and for interoperability reasons. <br>
><br>
><br>
> -- <br>
> Thomas Kerin<br>
> -------------------------<br>
> My PGP key can be found here
<a class="moz-txt-link-rfc2396E" href="http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155"><http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155></a><br>
><br>
><br>
>
------------------------------------------------------------------------------<br>
> Dive into the World of Parallel Programming. The Go Parallel
Website,<br>
> sponsored by Intel and developed in partnership with Slashdot
Media, is your<br>
> hub for all things parallel software development, from weekly
thought<br>
> leadership blogs to news, videos, case studies, tutorials and
more. Take a<br>
> look and join the conversation now.
<a class="moz-txt-link-freetext" href="http://goparallel.sourceforge.net/">http://goparallel.sourceforge.net/</a><br>
><br>
><br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a></span><br>
<br>
- -- <br>
Thomas Kerin<br>
- -------------------------<br>
<br>
My PGP key can be found here
<a class="moz-txt-link-rfc2396E" href="http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155"><http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155></a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (GNU/Linux)<br>
<br>
iQJ8BAEBCgBmBQJVX2ciXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w<br>
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz<br>
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFVlOwP/1w/Omr/6jGyi7spqW22HQ7P<br>
4+lNNzcsWp5/pv8e6YelUOSYiHuh/KxRoFfWL+wF+PNS2EtjRxSsXxg/R2nMft7B<br>
JQLNmIG6zTzVg/lhVObeSslXaia7repZxZ1S4nyEcs8rDVt7kkNnNguFOeONF95O<br>
3usCnrch+QbQacIt9StySAz155u1SuHeSmGmA/fRGLfArndXDdN0fYwE1KGyv5wm<br>
LqZ1PQfmYaCc0TUKRvpDRuc/+KF7q1fDMzuP9mZ3WiPdvTDKCXSRxYfbQYJdxplg<br>
AC0CFiOne+DXgiBdTOIcs9pcp1/6SyZs75Bkpv71AxBCmTlRTuYpsfH7O3VuZBGP<br>
FrN/4BMYnzMbGnNmvZwerUKH59MmzZTAzLSwZlpvj7ZxRks6KOp1CHInFWQlHAXJ<br>
O5c5McvqSdQ0rPHLcQ4DwB00Q1els18NRULjxdsTfLrT32birIXn3M1Hn/Q9d8Sa<br>
N+Y/cfXkojf4rJt75+XwjLyHECwS378ZFC8lfs1m/B3VSQxTtTZWA8905a1IRv/F<br>
nPQ2eaxBrFjm4OatE5lx+I/xmVAQuybG54UdcZGaKVXJbMg3sOslcYg7eA77pmR5<br>
7jRoRU+q7GhiRsUmxSkD+57FfhaMzX7iUl4xe3YK14KUS/pONuv0USC9to8a62kA<br>
gz9kb4pJMEhTtZNv7z9C<br>
=iq37<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>
--------------010006010900090308040004--
|
