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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1URFOU-0007Yr-U0
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Apr 2013 05:22:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.173 as permitted sender)
client-ip=209.85.216.173; envelope-from=etotheipi@gmail.com;
helo=mail-qc0-f173.google.com;
Received: from mail-qc0-f173.google.com ([209.85.216.173])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1URFOT-0006ZW-Qr
for bitcoin-development@lists.sourceforge.net;
Sun, 14 Apr 2013 05:22:26 +0000
Received: by mail-qc0-f173.google.com with SMTP id b12so1766175qca.32
for <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Apr 2013 22:22:20 -0700 (PDT)
X-Received: by 10.224.8.129 with SMTP id h1mr16548314qah.86.1365916940347;
Sat, 13 Apr 2013 22:22:20 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPS id e2sm23929507qey.3.2013.04.13.22.22.19
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 13 Apr 2013 22:22:19 -0700 (PDT)
Message-ID: <516A3CD1.20704@gmail.com>
Date: Sun, 14 Apr 2013 01:21:21 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20130414050958.GA11142@savin>
In-Reply-To: <20130414050958.GA11142@savin>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------040706080107010709030104"
X-Spam-Score: -0.6 (/)
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
X-Headers-End: 1URFOT-0006ZW-Qr
Subject: Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to
P2SH multisig
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: Sun, 14 Apr 2013 05:22:27 -0000
This is a multi-part message in MIME format.
--------------040706080107010709030104
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
If we're going to extend/expand message signing, can we please add a
proper ASCII-armored format for it? Really, anything that encodes the
signed message next to the signature, so that there's no ambiguities
about what was signed. You can keep the "bare signatures" as an option
for backwards compatiblity, but offer this as the primary one.
What we really want is to have the user copy an ASCII-armored block of
text into the client (or we could have a URI-extension for this), and
the app pops up with a window that says "The following message has a
valid signature from address 1XKjf32kJbf...: <message>".
I know people argue they'd like to get away from raw addresses and
copy-and-paste. But it'll be a while before that happens, and there's a
lot of demand for Armory to become compatible with Bitcoin-Qt signing.
People are obviously using it.
-Alan
On 04/14/2013 01:09 AM, Peter Todd wrote:
> Currently signmessage/verifymessage only supports messages signed by a
> single key. We should extend that to messages signed by n-of-m keys, or
> from the users point of view, P2SH multisig addresses.
>
> rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
> starts with a header byte marking the signs of the various keys to allow
> for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E
>
>
> For multisig signmessage signatures this is extended:
>
> <01> <varint n> <varint m> <sig or key> {<sig or key>, ...}
>
> Each signature or key can be one of the following forms:
>
> sig: <1B/1C/1D/1E> <32 byte r> <32 byte s>
> compress key: <02/03> <32 byte x>
> uncompressed key: <04> <32 byte x> <32 byte y>
>
> Note that we have to provide all pubkeys, even if they aren't used for a
> given signature, to allow the P2SH address to be reconstructed.
>
> Decoding/encoding is a bit code-intensive due to the all the cases, but
> on the other hand this format keeps the size down to an absolute
> minimum. Alternatively I could use length bytes.
>
> The format is backwards compatible in the sense that older versions will
> fail safely on new signatures, even ones that have been truncated.
> Similarly new signatures are easily distinguished from old, and going
> forward if we for some reason need yet another signature format the
> leading byte can be incremented.
>
> Signing incomplete signatures on messages can be handled by converting
> pubkeys to signatures. Similarly the RPC signmessage command can be
> extended with an optional "existing signature" option.
>
>
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------040706080107010709030104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">If we're going to extend/expand message
signing, can we please add a proper ASCII-armored format for it?
Really, anything that encodes the signed message next to the
signature, so that there's no ambiguities about what was signed.
You can keep the "bare signatures" as an option for backwards
compatiblity, but offer this as the primary one.<br>
<br>
What we really want is to have the user copy an ASCII-armored
block of text into the client (or we could have a URI-extension
for this), and the app pops up with a window that says "The
following message has a valid signature from address
1XKjf32kJbf...: <message>". <br>
<br>
I know people argue they'd like to get away from raw addresses and
copy-and-paste. But it'll be a while before that happens, and
there's a lot of demand for Armory to become compatible with
Bitcoin-Qt signing. People are obviously using it.<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
On 04/14/2013 01:09 AM, Peter Todd wrote:<br>
</div>
<blockquote cite="mid:20130414050958.GA11142@savin" type="cite">
<pre wrap="">Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
starts with a header byte marking the signs of the various keys to allow
for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E
For multisig signmessage signatures this is extended:
<01> <varint n> <varint m> <sig or key> {<sig or key>, ...}
Each signature or key can be one of the following forms:
sig: <1B/1C/1D/1E> <32 byte r> <32 byte s>
compress key: <02/03> <32 byte x>
uncompressed key: <04> <32 byte x> <32 byte y>
Note that we have to provide all pubkeys, even if they aren't used for a
given signature, to allow the P2SH address to be reconstructed.
Decoding/encoding is a bit code-intensive due to the all the cases, but
on the other hand this format keeps the size down to an absolute
minimum. Alternatively I could use length bytes.
The format is backwards compatible in the sense that older versions will
fail safely on new signatures, even ones that have been truncated.
Similarly new signatures are easily distinguished from old, and going
forward if we for some reason need yet another signature format the
leading byte can be incremented.
Signing incomplete signatures on messages can be handled by converting
pubkeys to signatures. Similarly the RPC signmessage command can be
extended with an optional "existing signature" option.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
<a class="moz-txt-link-freetext" href="http://www2.precog.com/precogplatform/slashdotnewsletter">http://www2.precog.com/precogplatform/slashdotnewsletter</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040706080107010709030104--
|
