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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1YCAP5-0005cX-Lz
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Jan 2015 17:09:47 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.174 as permitted sender)
client-ip=209.85.216.174; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f174.google.com;
Received: from mail-qc0-f174.google.com ([209.85.216.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YCAP4-0004dF-7J
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Jan 2015 17:09:47 +0000
Received: by mail-qc0-f174.google.com with SMTP id c9so17930327qcz.5
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Jan 2015 09:09:40 -0800 (PST)
X-Received: by 10.224.113.200 with SMTP id b8mr25593440qaq.35.1421428180732;
Fri, 16 Jan 2015 09:09:40 -0800 (PST)
Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net.
[69.143.204.74])
by mx.google.com with ESMTPSA id p7sm4660053qat.4.2015.01.16.09.09.40
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 16 Jan 2015 09:09:40 -0800 (PST)
Message-ID: <54B945D3.1000404@gmail.com>
Date: Fri, 16 Jan 2015 12:09:39 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CABETNRtquBWEZZ=jOcWojcgMTpjU5nWP9p74DArLxOXqqQT7og@mail.gmail.com> <6E575287-887C-4628-834C-282B67AFAA94@eeqj.com> <CABr1YTdqUxBs3+dMmtZ5dQvxP8MBFgttCdJ9cuvy10LdwAKaYQ@mail.gmail.com> <3382316.6TbFyFjyI6@crushinator> <CA+s+GJCsta-FesGv7zW_i2pEtZM5U20ZqP2V_Oog_LBtQBbe-w@mail.gmail.com> <CABETNRsTS=eDqTL5Cj8uYxLPZhWHW=p8CCxCdP7uUAHYujs7gA@mail.gmail.com>
<54B93D89.5020005@thomaskerin.io>
In-Reply-To: <54B93D89.5020005@thomaskerin.io>
Content-Type: multipart/alternative;
boundary="------------000708080106040307040601"
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
1.0 FREEMAIL_REPLY From and body contain different freemails
X-Headers-End: 1YCAP4-0004dF-7J
Subject: Re: [Bitcoin-development] convention/standard for sorting public
keys for p2sh multisig transactions
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, 16 Jan 2015 17:09:47 -0000
This is a multi-part message in MIME format.
--------------000708080106040307040601
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
I see no reason to restrict compressed/uncompressed. Strings don't have
to be the same length to sort them lexicographically. If a multi-sig
participant provides an uncompressed key, they are declaring that the
key that they use and it will only be used uncompressed. Clients don't
have to go looking for all combinations of compressed & uncompressed.
On 01/16/2015 11:34 AM, Thomas Kerin wrote:
>
>
> It seems there is scope for further narrowing down how a multisig
> scripthash address should be determined - what do people think of
> anticipating only compressed keys for scripts?
>
> It's possible to cause confusion if one put forward a compressed key
> at some time, and an uncompressed key at another. A different script
> hash would be produced even though there is no difference to the keys
> involved. The client will not search for this.
>
>
> Having spoken with Jean-Pierre and Ruben about this for quite some
> time now, there is 100% the need for a BIP outlining this. Everyone
> has had the idea at some point, and some of us already using it, but
> people shouldn't have to go digging in BIP45 for the two lines which
> mention it. All we need is a place to put the docs.
>
> I am building up a list of implementations which currently support
> sorting, and briefly describing a motivation for such a BIP.
>
>
> On 16/01/15 10:16, Ruben de Vries wrote:
> > Since we only need the sorting for creating the scriptPubKey,
> > wouldn't it make the most sense to sort it by the way it represented
> in that context?
>
>
> > On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj@gmail.com
> <mailto:laanwj@gmail.com>> wrote:
>
> > On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
> <bip@mattwhitlock.name <mailto:bip@mattwhitlock.name>> wrote:
> > > On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
> > >> Internally, pubkeys are DER-encoded integers.
> > >
> > > I thought pubkeys were represented as raw integers (i.e.,
> they're embedded in Script as a push operation whose payload is the
> raw bytes of the big-endian representation of the integer). As far as
> I know, DER encoding is only used for signatures. Am I mistaken?
>
> > OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
> > DER-encoded signature on the stack.
>
> > Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
> > used in outputs, which compares the 160-bit hash of the pubkey
> against
> > the given hash (usually taken from a bitcoin address).
>
> > It doesn't help understanding to consider either as integers.
> They are
> > binary blob objects with either a fixed format (DER) or a fixed size
> > (hashes).
>
> > Wladimir
>
>
>
>
> > --
> > BlockTrail B.V.
> > Barbara Strozzilaan 201
> > 1083HN Amsterdam
> > The Netherlands
>
> > Phone:+31 (0)612227277
> > E-mail:ruben@blocktrail.com <mailto:ruben@blocktrail.com>
> > Web:www.blocktrail.com
> > <http://www.blocktrail.com/>
> > Github:www.github.com/rubensayshi <http://www.github.com/rubensayshi>
>
> > BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
> Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
>
>
> >
> ------------------------------------------------------------------------------
> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> > GigeNET is offering a free month of service with a new server in
> Ashburn.
> > Choose from 2 high performing configs, both with 100TB of bandwidth.
> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> > http://p.sf.net/sfu/gigenet
>
>
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
>
------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------000708080106040307040601
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I see no reason to restrict compressed/uncompressed. Strings don't
have to be the same length to sort them lexicographically. If a
multi-sig participant provides an uncompressed key, they are
declaring that the key that they use and it will only be used
uncompressed. Clients don't have to go looking for all
combinations of compressed & uncompressed.<br>
<br>
On 01/16/2015 11:34 AM, Thomas Kerin wrote:<br>
<span style="white-space: pre;">></span><br>
<blockquote type="cite"><br>
It seems there is scope for further narrowing down how a multisig
scripthash address should be determined - what do people think of
anticipating only compressed keys for scripts?<br>
<br>
It's possible to cause confusion if one put forward a compressed
key at some time, and an uncompressed key at another. A different
script hash would be produced even though there is no difference
to the keys involved. The client will not search for this.<br>
<br>
<br>
Having spoken with Jean-Pierre and Ruben about this for quite some
time now, there is 100% the need for a BIP outlining this.
Everyone has had the idea at some point, and some of us already
using it, but people shouldn't have to go digging in BIP45 for the
two lines which mention it. All we need is a place to put the
docs.<br>
<br>
I am building up a list of implementations which currently support
sorting, and briefly describing a motivation for such a BIP.<br>
<br>
<br>
On 16/01/15 10:16, Ruben de Vries wrote:<br>
> Since we only need the sorting for creating the scriptPubKey,<br>
> wouldn't it make the most sense to sort it by the way it
represented in that context?<br>
<br>
<br>
> On Thu, Jan 15, 2015 at 2:03 PM, Wladimir
<<a class="moz-txt-link-abbreviated" href="mailto:laanwj@gmail.com">laanwj@gmail.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:laanwj@gmail.com"><mailto:laanwj@gmail.com></a>> wrote:<br>
<br>
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
<<a class="moz-txt-link-abbreviated" href="mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a> <a class="moz-txt-link-rfc2396E" href="mailto:bip@mattwhitlock.name"><mailto:bip@mattwhitlock.name></a>>
wrote:<br>
> > On Wednesday, 14 January 2015, at 3:53 pm, Eric
Lombrozo wrote:<br>
> >> Internally, pubkeys are DER-encoded integers.<br>
> ><br>
> > I thought pubkeys were represented as raw integers
(i.e., they're embedded in Script as a push operation whose
payload is the raw bytes of the big-endian representation of the
integer). As far as I know, DER encoding is only used for
signatures. Am I mistaken?<br>
<br>
> OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded
pubkey and a<br>
> DER-encoded signature on the stack.<br>
<br>
> Possibly you're confused with OP_HASH160 <hash160>
OP_EQUALVERIFY as<br>
> used in outputs, which compares the 160-bit hash of the
pubkey against<br>
> the given hash (usually taken from a bitcoin address).<br>
<br>
> It doesn't help understanding to consider either as
integers. They are<br>
> binary blob objects with either a fixed format (DER) or a
fixed size<br>
> (hashes).<br>
<br>
> Wladimir<br>
<br>
<br>
<br>
<br>
> --<br>
> BlockTrail B.V.<br>
> Barbara Strozzilaan 201<br>
> 1083HN Amsterdam<br>
> The Netherlands<br>
<br>
> Phone:+31 (0)612227277<br>
> <a class="moz-txt-link-abbreviated" href="mailto:E-mail:ruben@blocktrail.com">E-mail:ruben@blocktrail.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:ruben@blocktrail.com"><mailto:ruben@blocktrail.com></a><br>
> Web:www.blocktrail.com<br>
> <a class="moz-txt-link-rfc2396E" href="http://www.blocktrail.com/"><http://www.blocktrail.com/></a><br>
> Github:www.github.com/rubensayshi
<a class="moz-txt-link-rfc2396E" href="http://www.github.com/rubensayshi"><http://www.github.com/rubensayshi></a><br>
<br>
> BlockTrail B.V. Is registered with the Dutch Chamber of
Commerce in Amsterdam with registration No.:60262060 and VAT
No.:NL853833035B01<br>
<br>
<br>
>
------------------------------------------------------------------------------<br>
> New Year. New Location. New Benefits. New Data Center in
Ashburn, VA.<br>
> GigeNET is offering a free month of service with a new server
in Ashburn.<br>
> Choose from 2 high performing configs, both with 100TB of
bandwidth.<br>
> Higher redundancy.Lower latency.Increased capacity.Completely
compliant.<br>
> <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/gigenet">http://p.sf.net/sfu/gigenet</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><br>
<br>
</blockquote>
<span style="white-space: pre;">><br>
><br>
><br>
>
------------------------------------------------------------------------------<br>
> New Year. New Location. New Benefits. New Data Center in
Ashburn, VA.<br>
> GigeNET is offering a free month of service with a new server
in Ashburn.<br>
> Choose from 2 high performing configs, both with 100TB of
bandwidth.<br>
> Higher redundancy.Lower latency.Increased capacity.Completely
compliant.<br>
> <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/gigenet">http://p.sf.net/sfu/gigenet</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>
</body>
</html>
--------------000708080106040307040601--
|
