summaryrefslogtreecommitdiff
path: root/7c/549cebd165a315fd9b39c7c3a0f106ef2ce1c1
blob: e29f8db3afce7c5c3b17adb8190cbcaeef5d1d70 (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
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
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
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 B66E5CF1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Feb 2019 00:29:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com
	[209.85.221.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2110C79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 19 Feb 2019 00:29:17 +0000 (UTC)
Received: by mail-wr1-f41.google.com with SMTP id l5so19177366wrw.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 18 Feb 2019 16:29:16 -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=8TOwKCKszG7P1VOpqfA+SPElrmyA8xGdaqhtWAcFFYU=;
	b=JcpGftbZ29Xas31OKNuXUsvsws3Cr/yuP3pEXVPDTo2sIKa+wJFqykR4wWaqvBFVhZ
	Jeud7aHd5urJF2b3OozXJzf2zHpkVBQxhU4TM5y8qoK1IhaHbHKqjDRBuhdAfOddOY7X
	LTAw9ODy6IiWicpUYd/UJEivKq960eyccSl6E12lJp2B+FcFeL11LMVv2meeHS6E08Ez
	DxmfVBpOyRsUBy0v926z4mh2OLnzNiixAG8MRGRdy5p1yZkqnStAiugwcwkRn824sv/7
	1mWPIc6SYjCImmj+UJ9jX9a7dC26t9HTs17Vng+o4Gvag8x1uYZ/gyZ1rdRTYokbHQoW
	xqKg==
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=8TOwKCKszG7P1VOpqfA+SPElrmyA8xGdaqhtWAcFFYU=;
	b=ld3cYuHsRpyjPNvkjRaNRl0wuLPLulkydDgrFuKze21+h7+tajrV6Wms3/liHfXpA0
	JYAl0JKERF8LyZb9YLajnkPCP5xacPKdd8J+DMFLcbEBdJTmi4gYxRE5eNqMmpZ4W+PK
	Dxi7oR8dX8g2cnRLI+7KyOvgI1JrGWD9FMveGgzO4LxLVoEjlf3u1i0VvsWS2xQK24dx
	+u2pA0c26a0Zk2y4BNXpI8mla8oMS6IhPuuC34lCQsNNWPpz0PofOslZL42Z0iIb4Xuc
	TEL8tZm0sqWpt+HAqDzg8XKVPir5zHgnNCnsbve4gyo+uVZPZ28Mxy8/vsm+PXVBTazd
	e9GA==
X-Gm-Message-State: AHQUAuYs2EYuJfx4xcpUC0VLbtjZ39U8Z3KrZS19OtRJ263J7k30/t+O
	QiqCFxlf4DNVlF3wUcy056ATn3zEW2Ps5Rn6bn8=
X-Google-Smtp-Source: AHgI3IYWjofisT9lq+lGbfBzewLH4MLA8fmLSzhhITSEyv4FFqdySWrAFtGT2ktX9AZ/oORKPxv2GTY7h0TCTwPpfnc=
X-Received: by 2002:adf:9c85:: with SMTP id d5mr4558971wre.68.1550536155609;
	Mon, 18 Feb 2019 16:29:15 -0800 (PST)
MIME-Version: 1.0
References: <CAK=nyAxXS6rQowFC6ENto+d+D9FzSf5WJLz-WM_vc2D5DQ2xQQ@mail.gmail.com>
	<5c7fac0f-818b-d78d-5d5f-7a029fdd05ef@gmail.com>
	<CAK=nyAztSeEbDL=98PTdx-sdqGOug26-3vyADA-tc5oxECyZPw@mail.gmail.com>
	<4cfebb7d-42b3-0095-f3ac-dacfff29084d@gmail.com>
In-Reply-To: <4cfebb7d-42b3-0095-f3ac-dacfff29084d@gmail.com>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Mon, 18 Feb 2019 16:29:34 -0800
Message-ID: <CAK=nyAwFtdV1e4ecu8hq+efDo0TXqrVDw=rLRCur0t8_07O-CA@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c4406a058234546b"
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>
X-List-Received-Date: Tue, 19 Feb 2019 00:29:18 -0000

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

Trying the four possible options (p2pkh compressed, p2pkh uncompressed,
seg3, and bech32) is certainly a possibility and in fact, that's what I
ended up doing because not every wallet implements something like this, but
if there is a header field currently in use, it seemed reasonable to me to
use it specify which type of key is being used. If the header includes
whether the key is compressed or not compressed it seems logical to include
all data about what type of key it is and not just this one type of
information. That's why I thought the solution made sense and I wrote it up=
.

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

> Ah, OK, that's of course a good thing to document this undocumented (and
> strange) stuff, as a matter of fact I implemented it after reading your
> post (because this was on my todo list since some time) and got annoyed
> quickly, mainly by what is doing formatMessageForSigning (which is quite
> trivial when you know it but would be good to document precisely)
>
> So, yes, it's a good idea to write this, regarding the header I still
> don't see the use, testing the different possibilities is not a big deal,
> why the signature format is not the same as transactions one is mysteriou=
s
> too
> Le 19/02/2019 =C3=A0 00:24, Christopher Gilliard a =C3=A9crit :
>
> 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 pa=
rt
> you are referring to by "keys speech", but the signatures are done by ECD=
SA
> keys so it's hard to not include anything about keys even though that's n=
ot
> the main topic. The "Background on ECDSA keys" section was mainly meant t=
o
> 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 par=
t
> 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 sinc=
e
> 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/uncompresse=
d
> is included in the header so that you know which type of key the signatur=
e
> 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 use=
d
> 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
>> precise 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 o=
n
>> 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 agai=
n
>> and for what purpose, the header seems completely of no use especially w=
hen
>> 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=
=A9crit :
>>
>> I have written up a proposed BIP. It has to do with Signature formats
>> when 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://lis=
ts.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-transa=
ctions
>> 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.=
org
>> 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
>>
>> --
> 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
>
>

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

<div dir=3D"ltr">Trying the four possible options (p2pkh compressed, p2pkh =
uncompressed, seg3, and bech32) is certainly a possibility and in fact, tha=
t&#39;s what I ended up doing because not every wallet implements something=
 like this, but if there is a header field currently in use, it seemed reas=
onable to me to use it specify which type of key is being used. If the head=
er includes whether the key is compressed or not compressed it seems logica=
l to include all data about what type of key it is and not just this one ty=
pe of information. That&#39;s why I thought the solution made sense and I w=
rote it up.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Mon, Feb 18, 2019 at 3:50 PM Aymeric Vitte &lt;<a href=3D"mai=
lto:vitteaymeric@gmail.com">vitteaymeric@gmail.com</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF">
    <p>Ah, OK, that&#39;s of course a good thing to document this
      undocumented (and strange) stuff, as a matter of fact I
      implemented it after reading your post (because this was on my
      todo list since some time) and got annoyed quickly, mainly by what
      is doing formatMessageForSigning (which is quite trivial when you
      know it but would be good to document precisely)</p>
    <p>So, yes, it&#39;s a good idea to write this, regarding the header I
      still don&#39;t see the use, testing the different possibilities is
      not a big deal, why the signature format is not the same as
      transactions one is mysterious too<br>
    </p>
    <div class=3D"gmail-m_3218010408267466317moz-cite-prefix">Le 19/02/2019=
 =C3=A0 00:24, Christopher
      Gilliard a =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote type=3D"cite">
     =20
      <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 exactly what part you are
        referring to by &quot;keys speech&quot;, but the signatures are don=
e by
        ECDSA keys so it&#39;s hard to not include anything about 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 kind of
        keys Bitcoin uses, for people who already know that they can
        easily skip 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 addendu=
m
        though. Yes, I did not invent any of this, I&#39;m just documenting
        what people actually seem to do because I had to verify
        signatures as part of a project I&#39;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&#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
        since 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" ta=
rget=3D"_blank">vitteaymeric@gmail.com</a>&gt; wrote:<br>
        </div>
        <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <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 i=
t
              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_3218010408267466317gmail-m_41682224515322=
5270moz-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">
              <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://githu=
b.com/cgilliard/BIP/blob/master/README.md" target=3D"_blank">https://github=
.com/cgilliard/BIP/blob/master/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/bitcoi=
n/bitcoin/issues/10542" target=3D"_blank">https://github.com/bitcoin/bitcoi=
n/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 m=
e
                    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_3218010408267466317gmail-m_4168222=
45153225270mimeAttachmentHeader"></fieldset>
              <pre class=3D"gmail-m_3218010408267466317gmail-m_416822245153=
225270moz-quote-pre">_______________________________________________
bitcoin-dev mailing list
<a class=3D"gmail-m_3218010408267466317gmail-m_416822245153225270moz-txt-li=
nk-abbreviated" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"gmail-m_3218010408267466317gmail-m_416822245153225270moz-txt-li=
nk-freetext" href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev</a>
</pre>
            </blockquote>
            <pre class=3D"gmail-m_3218010408267466317gmail-m_41682224515322=
5270moz-signature" cols=3D"72">--=20
Move your coins by yourself (browser version): <a class=3D"gmail-m_32180104=
08267466317gmail-m_416822245153225270moz-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_3218010408267466317gm=
ail-m_416822245153225270moz-txt-link-freetext" href=3D"https://github.com/A=
yms/bitcoin-transactions" target=3D"_blank">https://github.com/Ayms/bitcoin=
-transactions</a>
Zcash wallets made simple: <a class=3D"gmail-m_3218010408267466317gmail-m_4=
16822245153225270moz-txt-link-freetext" href=3D"https://github.com/Ayms/zca=
sh-wallets" target=3D"_blank">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class=3D"gmail-m_3218010408267466317gmail-m=
_416822245153225270moz-txt-link-freetext" href=3D"https://github.com/Ayms/b=
itcoin-wallets" target=3D"_blank">https://github.com/Ayms/bitcoin-wallets</=
a>
Get the torrent dynamic blocklist: <a class=3D"gmail-m_3218010408267466317g=
mail-m_416822245153225270moz-txt-link-freetext" href=3D"http://peersm.com/g=
etblocklist" target=3D"_blank">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class=3D"gmail-m_3218010408267466317gmail=
-m_416822245153225270moz-txt-link-freetext" href=3D"http://peersm.com/findm=
yass" target=3D"_blank">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class=3D"gmail-m_321=
8010408267466317gmail-m_416822245153225270moz-txt-link-freetext" href=3D"ht=
tp://torrent-live.org" target=3D"_blank">http://torrent-live.org</a>
Peersm : <a class=3D"gmail-m_3218010408267466317gmail-m_416822245153225270m=
oz-txt-link-freetext" href=3D"http://www.peersm.com" target=3D"_blank">http=
://www.peersm.com</a>
torrent-live: <a class=3D"gmail-m_3218010408267466317gmail-m_41682224515322=
5270moz-txt-link-freetext" href=3D"https://github.com/Ayms/torrent-live" ta=
rget=3D"_blank">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class=3D"gmail-m_3218010408267466317gmail-m_41682224515322527=
0moz-txt-link-freetext" href=3D"https://www.github.com/Ayms/node-Tor" targe=
t=3D"_blank">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class=3D"gmail-m_3218010408267466317gmail-m_416822245153225270m=
oz-txt-link-freetext" href=3D"https://www.github.com/Ayms" target=3D"_blank=
">https://www.github.com/Ayms</a></pre>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <pre class=3D"gmail-m_3218010408267466317moz-signature" cols=3D"72">--=
=20
Move your coins by yourself (browser version): <a class=3D"gmail-m_32180104=
08267466317moz-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_3218010408267466317mo=
z-txt-link-freetext" href=3D"https://github.com/Ayms/bitcoin-transactions" =
target=3D"_blank">https://github.com/Ayms/bitcoin-transactions</a>
Zcash wallets made simple: <a class=3D"gmail-m_3218010408267466317moz-txt-l=
ink-freetext" href=3D"https://github.com/Ayms/zcash-wallets" target=3D"_bla=
nk">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class=3D"gmail-m_3218010408267466317moz-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_3218010408267466317m=
oz-txt-link-freetext" href=3D"http://peersm.com/getblocklist" target=3D"_bl=
ank">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class=3D"gmail-m_3218010408267466317moz-t=
xt-link-freetext" href=3D"http://peersm.com/findmyass" target=3D"_blank">ht=
tp://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class=3D"gmail-m_321=
8010408267466317moz-txt-link-freetext" href=3D"http://torrent-live.org" tar=
get=3D"_blank">http://torrent-live.org</a>
Peersm : <a class=3D"gmail-m_3218010408267466317moz-txt-link-freetext" href=
=3D"http://www.peersm.com" target=3D"_blank">http://www.peersm.com</a>
torrent-live: <a class=3D"gmail-m_3218010408267466317moz-txt-link-freetext"=
 href=3D"https://github.com/Ayms/torrent-live" target=3D"_blank">https://gi=
thub.com/Ayms/torrent-live</a>
node-Tor : <a class=3D"gmail-m_3218010408267466317moz-txt-link-freetext" hr=
ef=3D"https://www.github.com/Ayms/node-Tor" target=3D"_blank">https://www.g=
ithub.com/Ayms/node-Tor</a>
GitHub : <a class=3D"gmail-m_3218010408267466317moz-txt-link-freetext" href=
=3D"https://www.github.com/Ayms" target=3D"_blank">https://www.github.com/A=
yms</a></pre>
  </div>

</blockquote></div>

--000000000000c4406a058234546b--