summaryrefslogtreecommitdiff
path: root/ee/60908f798b363418bf202b55dc5656d1191afb
blob: e760ab3f3bb7e551ae92b5caf50c0840229ed886 (plain)
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
Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C178A16F3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Feb 2019 23:24:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
	[209.85.221.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACA1B786
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Feb 2019 23:24:26 +0000 (UTC)
Received: by mail-wr1-f51.google.com with SMTP id r5so6795038wrg.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Feb 2019 15:24:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=mcQ/V/bLvSCLNNP4oBFSlJdrLv5Jp7k5mVBi8QgaXF0=;
	b=vMVzRsFgSkeVrwy709As61cAgjPeGwFOM9qd9kGXX+gNRcX/m+AtHjIcee65DeT1Ae
	BG6VwPZ1EC4h9LpWt7M13kSpJmwryATJmT/Jf6lM7n+wge1iZ3Wxc6TtcPoIFzaFQZyM
	OCImegC2v7OAK3x2yNDjXy57HDJhAm+pR4ulcEV1SHrQnd6n3xFNt46KjKwAfzWZYC/d
	qTwhHDnIfl3wB/vmP/Ya6UuAKf+UzMHqQwW0hcYwqQnK5NdI9nm7ya9uOFYHOZrHKBn7
	5EBBl/4eYSLRj9LCjICNPf1KRlel+SXWtlklZxLF4fm+810JQaaH7jJIQW6+/+ltr70d
	0xOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=mcQ/V/bLvSCLNNP4oBFSlJdrLv5Jp7k5mVBi8QgaXF0=;
	b=YDZsh6XqwsFq9vDs7QdBEX3JT8kCdWNli7aBvwVWNRl7ILAm+NSVbcElh8DD99tylU
	aqWD5VxuXdnqr1RQAdDFPBvU6sXpcfumS6Kzzz0sDCftB5qfakzkkWtCZ4P5eNr8PqzG
	Ub9bjvoHg09afflKjH1KeOME+GadhXbCk+CL6OtxuQdshP9GGtbszUVfAPDMD/4adl2/
	GB2fKcocHvVchIuwIq4jXfno4nyyp1zxtXyYbCgIvcQk1rF6M82LtkhAU9hoTe/MeR5A
	uf0Yl0ORNgNr0PqIoBubT0Z5mFhbqBa3/x5wz+HFIufdXRudvV5Meaf55lkrqanVht5n
	Q/Tg==
X-Gm-Message-State: AHQUAuZvk/DjJSoFY/LNeYJ2R+wYHpfkg6C6sAoc3ryA/efBxvcHZNKg
	cimeCKYRt/wWQB0yok60T1TAqMs7XgseV+sofVo=
X-Google-Smtp-Source: AHgI3Iah1yP1CDQE78qtgcVabE2GDg9r3Xkfuu9Fsyw42ngCY9ZB4Ep3TPJpOHoO9dyrij2Cgb5PASPpL8NE4HTJmUo=
X-Received: by 2002:adf:9c85:: with SMTP id d5mr4443061wre.68.1550532265089;
	Mon, 18 Feb 2019 15:24:25 -0800 (PST)
MIME-Version: 1.0
References: <CAK=nyAxXS6rQowFC6ENto+d+D9FzSf5WJLz-WM_vc2D5DQ2xQQ@mail.gmail.com>
	<5c7fac0f-818b-d78d-5d5f-7a029fdd05ef@gmail.com>
In-Reply-To: <5c7fac0f-818b-d78d-5d5f-7a029fdd05ef@gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Message-ID: <CAK=nyAztSeEbDL=98PTdx-sdqGOug26-3vyADA-tc5oxECyZPw@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000dfa27c0582336c31"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Wed, 06 Mar 2019 00:22:07 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal - Signatures of Messages using
 Bitcoin Private Keys
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>
Date: Mon, 18 Feb 2019 23:24:27 -0000
X-Original-Date: Mon, 18 Feb 2019 15:24:44 -0800
X-List-Received-Date: Mon, 18 Feb 2019 23:24:27 -0000

--000000000000dfa27c0582336c31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The proposal includes actual code that does verification, but I didn't
include code for signing. I thought it could be inferred, but I could at
least include a description of how to sign. I am not sure exactly what part
you are referring to by "keys speech", but the signatures are done by ECDSA
keys so it's hard to not include anything about keys even though that's not
the main topic. The "Background on ECDSA keys" section was mainly meant to
give background about what kind of keys Bitcoin uses, for people who
already know that they can easily skip this section so I would probably
think it's best just to leave in.  Maybe it should be at the end as an
addendum though. Yes, I did not invent any of this, I'm just documenting
what people actually seem to do because I had to verify signatures as part
of a project I'm working on. I would have liked to have had this document
when I started the project so I thought it might be useful to others since
as far as I can tell this was not specified anywhere. The reason for
including this data in the header is the same that compressed/uncompressed
is included in the header so that you know which type of key the signature
is from and you don't have to try all options to see if any matches. This
is why Trezor did that way and why I documented it. I'm sure there are
other ways to do this, but since this is out there in the field being used
and is a reasonable solution, I thought I'd write it up.

On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> Then, since you wrote this proposal, maybe you should add the very precis=
e
> description of the signing/verification process since it is documented
> nowhere
>
> I don't get the use of the speech regarding keys while it should focus on
> signatures which are summarized in a vague sentence inspired by your ref
> [2] with a not very logical link to the next paragraph stating that r,s
> should be 32B and the whole thing 65B with a header of 1B, you did not
> invent it, that's probably the rule, not sure where it is specified again
> and for what purpose, the header seems completely of no use especially wh=
en
> you extend to segwit/bech32 since you just have to check that related
> compressed key matches
> Le 17/02/2019 =C3=A0 15:14, Christopher Gilliard via bitcoin-dev a =C3=A9=
crit :
>
> I have written up a proposed BIP. It has to do with Signature formats whe=
n
> using Bitcoin Private keys. It is here:
> https://github.com/cgilliard/BIP/blob/master/README.md
>
> This BIP was written up as suggested in this github issue:
> https://github.com/bitcoin/bitcoin/issues/10542
>
> Note that the proposal is inline with the implementation that Trezor
> implemented in the above issue.
>
> Any feedback would be appreciated. Please let me know what the steps are
> with regards to getting a BIP number assigned or any other process steps
> required.
>
> Regards,
> Chris
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://list=
s.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
> Move your coins by yourself (browser version): https://peersm.com/wallet
> Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
> Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
> Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist: http://torrent-live.o=
rg
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>

--000000000000dfa27c0582336c31
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The proposal includes actual code that does verification, =
but I didn&#39;t include code for signing. I thought it could be inferred, =
but I could at least include a description of how to sign. I am not sure ex=
actly what part you are referring to by &quot;keys speech&quot;, but the si=
gnatures are done by ECDSA keys so it&#39;s hard to not include anything ab=
out keys even though that&#39;s not the main topic. The &quot;Background on=
 ECDSA keys&quot; section was mainly meant to give background about what ki=
nd of keys Bitcoin uses, for people who already know that they can easily s=
kip this section so I would probably think it&#39;s best just to leave in.=
=C2=A0 Maybe it should be at the end as an addendum though. Yes, I did not =
invent any of this, I&#39;m just documenting what people actually seem to d=
o because I had to verify signatures as part of a project I&#39;m working o=
n. I would have liked to have had this document when I started the project =
so I thought it might be useful to others since as far as I can tell this w=
as not specified anywhere. The reason for including this data in the header=
 is the same that compressed/uncompressed is included in the header so that=
 you know which type of key the signature is from and you don&#39;t have to=
 try all options to see if any matches. This is why Trezor did that way and=
 why I documented it. I&#39;m sure there are other ways to do this, but sin=
ce this is out there in the field being used and is a reasonable solution, =
I thought I&#39;d write it up.</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Mon, Feb 18, 2019 at 2:59 PM Aymeric Vitte=
 &lt;<a href=3D"mailto:vitteaymeric@gmail.com">vitteaymeric@gmail.com</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    <p>Then, since you wrote this proposal, maybe you should add the
      very precise description of the signing/verification process since
      it is documented nowhere</p>
    <p>I don&#39;t get the use of the speech regarding keys while it should
      focus on signatures which are summarized in a vague sentence
      inspired by your ref [2] with a not very logical link to the next
      paragraph stating that r,s should be 32B and the whole thing 65B
      with a header of 1B, you did not invent it, that&#39;s probably the
      rule, not sure where it is specified again and for what purpose,
      the header seems completely of no use especially when you extend
      to segwit/bech32 since you just have to check that related
      compressed key matches<br>
    </p>
    <div class=3D"gmail-m_416822245153225270moz-cite-prefix">Le 17/02/2019 =
=C3=A0 15:14, Christopher
      Gilliard via bitcoin-dev a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <div dir=3D"ltr">
        <div dir=3D"ltr">
          <div dir=3D"ltr">I have written up a proposed BIP. It has to do
            with Signature formats when using Bitcoin Private keys. It
            is here:=C2=A0<a href=3D"https://github.com/cgilliard/BIP/blob/=
master/README.md" target=3D"_blank">https://github.com/cgilliard/BIP/blob/m=
aster/README.md</a></div>
          <div dir=3D"ltr"><br>
          </div>
          <div>This BIP was written up as suggested in this github
            issue:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/issue=
s/10542" target=3D"_blank">https://github.com/bitcoin/bitcoin/issues/10542<=
/a></div>
          <div><br>
          </div>
          <div>Note that the proposal is inline with the implementation
            that Trezor implemented in the above issue.</div>
          <div dir=3D"ltr"><br>
          </div>
          <div>Any feedback would be=C2=A0appreciated. Please let me know
            what the steps are with regards to getting a BIP number
            assigned or any other process steps required.</div>
          <div><br>
          </div>
          <div>Regards,</div>
          <div>Chris</div>
        </div>
      </div>
      <br>
      <fieldset class=3D"gmail-m_416822245153225270mimeAttachmentHeader"></=
fieldset>
      <pre class=3D"gmail-m_416822245153225270moz-quote-pre">______________=
_________________________________
bitcoin-dev mailing list
<a class=3D"gmail-m_416822245153225270moz-txt-link-abbreviated" href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>
<a class=3D"gmail-m_416822245153225270moz-txt-link-freetext" href=3D"https:=
//lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank"=
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <pre class=3D"gmail-m_416822245153225270moz-signature" cols=3D"72">--=
=20
Move your coins by yourself (browser version): <a class=3D"gmail-m_41682224=
5153225270moz-txt-link-freetext" href=3D"https://peersm.com/wallet" target=
=3D"_blank">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class=3D"gmail-m_416822245153225270moz=
-txt-link-freetext" href=3D"https://github.com/Ayms/bitcoin-transactions" t=
arget=3D"_blank">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class=3D"gmail-m_416822245153225270moz-txt-li=
nk-freetext" href=3D"https://github.com/Ayms/zcash-wallets" target=3D"_blan=
k">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class=3D"gmail-m_416822245153225270moz-txt-=
link-freetext" href=3D"https://github.com/Ayms/bitcoin-wallets" target=3D"_=
blank">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class=3D"gmail-m_416822245153225270mo=
z-txt-link-freetext" href=3D"http://peersm.com/getblocklist" target=3D"_bla=
nk">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class=3D"gmail-m_416822245153225270moz-tx=
t-link-freetext" href=3D"http://peersm.com/findmyass" target=3D"_blank">htt=
p://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class=3D"gmail-m_416=
822245153225270moz-txt-link-freetext" href=3D"http://torrent-live.org" targ=
et=3D"_blank">http://torrent-live.org</a>
Peersm : <a class=3D"gmail-m_416822245153225270moz-txt-link-freetext" href=
=3D"http://www.peersm.com" target=3D"_blank">http://www.peersm.com</a>
torrent-live: <a class=3D"gmail-m_416822245153225270moz-txt-link-freetext" =
href=3D"https://github.com/Ayms/torrent-live" target=3D"_blank">https://git=
hub.com/Ayms/torrent-live</a>
node-Tor : <a class=3D"gmail-m_416822245153225270moz-txt-link-freetext" hre=
f=3D"https://www.github.com/Ayms/node-Tor" target=3D"_blank">https://www.gi=
thub.com/Ayms/node-Tor</a>
GitHub : <a class=3D"gmail-m_416822245153225270moz-txt-link-freetext" href=
=3D"https://www.github.com/Ayms" target=3D"_blank">https://www.github.com/A=
yms</a></pre>
  </div>

</blockquote></div>

--000000000000dfa27c0582336c31--