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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ruben@blockcorp.com>) id 1YC4KC-0006O4-IX
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Jan 2015 10:40:20 +0000
Received: from mail-we0-f180.google.com ([74.125.82.180])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YC4K9-0002oE-Bs
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Jan 2015 10:40:20 +0000
Received: by mail-we0-f180.google.com with SMTP id w62so19497868wes.11
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Jan 2015 02:40:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=p35v9HTRRauDd83gcIKilhtIxkiyRA6X21layfGNRlY=;
b=YkXSmEmi4VD6IaxBhbr8xu1EZyhAL8dEAzPfUq1eA2HktzxXgZbnoNfUzP+FxTOXxo
AAsWErTNV9drkymiJcrgvvzfGnIjoxTSa9VNU8RjpKsgOi8ydYB7iIMvOuJscmSzwiWl
lY6zquJmM1AdwwOSW3LX3Kq0jHXQIHNJwSNsDnx2LzNzDIwDhnBC4wtP7WprjDXc7/Gn
zzjz2tXeRQNmMghA6Zxe15FgPM28QpMiZRcq7ef9WrifWMABMORPc9iqTmpCMS3IrEBq
/81c4QWe8PeiJFsJuqwGfJVeHW7maxHXkW6opoYcDVypy8qR/lH0rRxNtsKd5vQ8U74i
uxPw==
X-Gm-Message-State: ALoCoQkCRARs9/wZKgfBSpWCafysTNxQL7LeYX1H/u6XdBdM7MduUZhofylLyjhycZTL7v64n4aD
MIME-Version: 1.0
X-Received: by 10.194.193.4 with SMTP id hk4mr27649789wjc.38.1421403416215;
Fri, 16 Jan 2015 02:16:56 -0800 (PST)
Received: by 10.27.11.34 with HTTP; Fri, 16 Jan 2015 02:16:56 -0800 (PST)
In-Reply-To: <CA+s+GJCsta-FesGv7zW_i2pEtZM5U20ZqP2V_Oog_LBtQBbe-w@mail.gmail.com>
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>
Date: Fri, 16 Jan 2015 11:16:56 +0100
Message-ID: <CABETNRsTS=eDqTL5Cj8uYxLPZhWHW=p8CCxCdP7uUAHYujs7gA@mail.gmail.com>
From: Ruben de Vries <ruben@blocktrail.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb03946b4ddc8050cc24558
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: 1YC4K9-0002oE-Bs
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
Jeffrey Paul <jp@eeqj.com>
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 10:40:20 -0000
--047d7bb03946b4ddc8050cc24558
Content-Type: text/plain; charset=UTF-8
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> wrote:
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <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
Web: www.blocktrail.com
Github: 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
--047d7bb03946b4ddc8050cc24558
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:verdana,=
sans-serif">Since we only need the sorting for creating the scriptPubKey,=
=C2=A0</div><div class=3D"gmail_default" style=3D"font-family:verdana,sans-=
serif">wouldn't it make the most sense to sort it by the way it represe=
nted in that context?</div><div class=3D"gmail_default" style=3D"font-famil=
y:verdana,sans-serif"><br></div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <span dir=3D=
"ltr"><<a href=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmai=
l.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"HOEnZb"><div class=3D"h5">On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock &=
lt;<a href=3D"mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>> w=
rote:<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 th=
e big-endian representation of the integer). As far as I know, DER encoding=
is only used for signatures. Am I mistaken?<br>
<br>
</div></div>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>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Wladimir<br>
</font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b=
r><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di=
v><font face=3D"arial, helvetica, sans-serif">BlockTrail B.V.</font></div><=
div><font face=3D"arial, helvetica, sans-serif">Barbara Strozzilaan 201</fo=
nt></div><div><font face=3D"arial, helvetica, sans-serif">1083HN Amsterdam<=
/font></div><div><font face=3D"arial, helvetica, sans-serif">The Netherland=
s</font></div><div><br></div><div><font face=3D"arial, helvetica, sans-seri=
f">Phone:<span style=3D"white-space:pre"> </span>+31 (0)612227277</font></=
div><div><font face=3D"arial, helvetica, sans-serif">E-mail:<span style=3D"=
white-space:pre"> </span><a href=3D"mailto:ruben@blocktrail.com" target=3D=
"_blank">ruben@blocktrail.com</a></font></div><div><font face=3D"arial, hel=
vetica, sans-serif">Web:<span style=3D"white-space:pre"> </span><a href=3D=
"http://www.blocktrail.com/" target=3D"_blank">www.blocktrail.com<br></a></=
font></div><div>Github:<span style=3D"font-family:arial,helvetica,sans-seri=
f;white-space:pre"> </span><span style=3D"font-family:arial,helvetica,sans-=
serif;white-space:pre"> <a href=3D"http://www.github.com/rubensayshi" targe=
t=3D"_blank">www.github.com/rubensayshi</a></span></div><div><font face=3D"=
arial, helvetica, sans-serif"><br></font></div><div><font face=3D"arial, he=
lvetica, sans-serif">BlockTrail B.V. Is registered with the Dutch Chamber o=
f Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833=
035B01</font></div></div></div></div></div>
</div>
--047d7bb03946b4ddc8050cc24558--
|
