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
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
|
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 <khal@dot-bit.org>) id 1Rbbm2-0002UG-6E
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 17:40:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of dot-bit.org
designates 178.32.102.200 as permitted sender)
client-ip=178.32.102.200; envelope-from=khal@dot-bit.org;
helo=srv01.web-sweet-web.net;
Received: from srv01.web-sweet-web.net ([178.32.102.200])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1Rbblz-00066Q-IY
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 17:40:45 +0000
Received: by srv01.web-sweet-web.net (Postfix, from userid 1000)
id D3E81165E007; Fri, 16 Dec 2011 18:23:48 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on
srv01.web-sweet-web.net
X-Spam-Level:
X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, AWL, HTML_MESSAGE
autolearn=ham version=3.2.5
Received: from [10.0.0.2] (sal69-2-82-241-217-146.fbx.proxad.net
[82.241.217.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits))
(No client certificate requested)
by srv01.web-sweet-web.net (Postfix) with ESMTPSA id C14F1165E005
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 18:23:36 +0100 (CET)
Message-ID: <4EEB7E98.8030006@dot-bit.org>
Date: Fri, 16 Dec 2011 18:23:36 +0100
From: Khalahan <khal@dot-bit.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<1323979147.27319.140661012141129@webmail.messagingengine.com>
In-Reply-To: <1323979147.27319.140661012141129@webmail.messagingengine.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/alternative;
boundary="------------060608040301030600010103"
X-Spam-Score: -1.0 (-)
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 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.5 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rbblz-00066Q-IY
Subject: Re: [Bitcoin-development] [BIP 15] Aliases
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 Dec 2011 17:40:46 -0000
This is a multi-part message in MIME format.
--------------060608040301030600010103
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Namecoin is a peer-to-peer generic name/value datastore system.
Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.
Namecoin is *specificaly designed to map things to names* in a fully
decentralized way. So, it's the perfect starting point to map names to
other things (a public bitcoin address, an url, etc)
You won't have all the advantages of namecoin when using other systems
like DNS and HTTP(S) as the first entry point.
What is namecoin ?
* proven technology :
- do not mix the namecoin technology and the dot-bit namespace with .bit
domains (dot-bit domains needs dot-bit compatible dns servers or proxies
+ namecoin and have a small visibility due to the nature of
top-to-bottom domain name system controlled by ICANN, namecoin needs
only namecoin to store data !)
- as proven and secure as bitcoin
- merged mining provides a secure network
* decentralized :
- a lot of nodes, and you can have your own node
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider
- everybody can become a name provider (register for your friends and
resell names).
* no single point of failure :
- DNS and HTTPS have several limitations (Man in the Middle attacks, no
reliable authority of certifications, domain seizure, ...)
* designed for that :
- namecoin uses a system of namespaces to separate each usages :
http://dot-bit.org/Main_Page#Namespaces.
For example, the "personal namespace" draft
(http://dot-bit.org/Personal_Namespace) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used if
prefered (the "bitcoin/" or "alias/" or "map/" prefixes for example).
* easily connectable to bitcoin
- they both use RPC and json to exchange informations, so connecting one
to the other is really easy
- bitcoin could even allow registration of names by sending an RPC
request to namecoin
* extensible and not limited :
- you are not forced to store a bitcoin address directly in namecoin,
you can also store an url or a domain name
- allows additional security : add a certificate fingerprint combined
with an https url (so, using DNS or HTTP(S) is not a major problem
anymore if the first point of entry is really secure and configurable
[and you use and self-signed certificate])
- really easy to update
- simple for simple cases
- possibility to use a nick, an email address or a domain as name
- other methods to get bitcoins addresses can be added later, protocol
is extensible
Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :
* An individual person with well known public addresses :
"p/*khal*":
{
"email": "khal@dot-bit.org",
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}
* Another individual person with well known public addresses :
"p/*khal@dot-bit.org*":
{
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"
}
* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :
"p/*mymerchant.com*":
{
"bitcoin": {
"url": "https://payto.mymerchant.com/bitcoin/",
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
"cert": "https://payto.mymerchant.com/certificate.pem",
},
"namecoin": {
"url": "https://payto.mymerchant.com/namecoin/",
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"
},
"paypal": "xxxxxx@yyyyyyyyy.zzz",
"othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
* A merchant with a public address, an url to generate custom addresses
and a domain name (not sure if this case is really usefull, maybe as
fallback)
"p/*mymerchant2*":
{
"bitcoin": {
"url": "https://payto.mymerchant.com/bitcoin/",
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",
"dns": "_bitcoin.payto.mymerchant.com",
"address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",
}
}
* How to use it in bitcoin ?
Several possibilities of address syntax :
- khal, khal@dot-bit.org, mymerchant.com, mymerchant2 : no syntax limit
- mymerchant2@bitcoin : will conflict with names already containing a @
- mymerchant2@namecoin : same
- namecoin:mymerchant2 : strange syntax, confusing with the "uri scheme"
- namecoin://mymerchant2 : same
- other ?
Here is how things would be processed when people put an address to pay
to in the bitcoin client :
* address : khal
-> RPC to namecoin for "p/khal"
-> json processing for "p/khal->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
* address : khal@dot-bit.org
-> RPC to namecoin for "p/khal@dot-bit.org"
-> json processing for "p/khal@dot-bit.org->bitcoin"
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T
* address : mymerchant.com
-> RPC to namecoin for "p/mymerchant.com"
-> json processing for "p/mymerchant.com->bitcoin"
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy
* address : mymerchant2
-> RPC to namecoin for "p/mymerchant2"
-> json processing for "p/mymerchant2->bitcoin"
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"
-> https request to "https://payto.mymerchant.com/bitcoin/"
-> result : error (website unavailable, page not found, timeout, etc)
-> json processing for "p/mymerchant2->bitcoin->dns"
-> dns request for "_bitcoin.payto.mymerchant.com"
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy
Le 15/12/2011 20:59, theymos a =E9crit :
> Bitcoin already has code and a protocol for transactions to IP
> addresses. Why not reuse that for dynamic address lookup? Just a few
> changes are necessary to enable complete user@server.com handling:
> - Extend the protocol so that "reply" messages can be signed by a fixed
> public key
> - Extend "checkorder" messages so they can specify an account to
> send BTC to. Or standardize on how to put the account into the
> message field.
> - Enable DNS lookups for IP transactions. The DNS-only proposals could
> also be used here to avoid having to use the IP transaction protocol
> sometimes. The public key for signing "reply" messages can be gotten
> from TXT records. This will be safe with DNSSEC and Namecoin. With
> plain DNS Bitcoin could take a SSH-like approach and ask the user to
> verify the public key the first time it is used, remembering it later=
.
>
> DoS attacks are already handled by the IP transactions code: the same I=
P
> address is always given the same bitcoin address until it pays to that
> bitcoin address.
>
> -----------------------------------------------------------------------=
-------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs. =20
> But none more important than the need to reduce IT complexity=20
> while improving strategic productivity. Learn More!=20
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--=20
Best Regards,
Khalahan
http://dot-bit.org/
--------------060608040301030600010103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Namecoin is a peer-to-peer generic name/value datastore system.<br>
Don't forget it's not limited to .bit usage ! So, directly mapping
things to .bit url would not be the optimal way of using namecoin.<br>
<br>
Namecoin is <b>specificaly designed to map things to names</b> in a
fully decentralized way. So, it's the perfect starting point to map
names to other things (a public bitcoin address, an url, etc)<br>
You won't have all the advantages of namecoin when using other
systems like DNS and HTTP(S) as the first entry point.<br>
<br>
What is namecoin ?<br>
<br>
* proven technology :<br>
- do not mix the namecoin technology and the dot-bit namespace with
.bit domains (dot-bit domains needs dot-bit compatible dns servers
or proxies + namecoin and have a small visibility due to the nature
of top-to-bottom domain name system controlled by ICANN, namecoin
needs only namecoin to store data !)<br>
- as proven and secure as bitcoin<br>
- merged mining provides a secure network<br>
<br>
* decentralized :<br>
- a lot of nodes, and you can have your own node<br>
- everybody can register his own name, by itself with the namecoin
software (bitcoin could even allow registration directly from it,
easily) or by using a name provider<br>
- everybody can become a name provider (register for your friends
and resell names).<br>
<br>
* no single point of failure :<br>
- DNS and HTTPS have several limitations (Man in the Middle attacks,
no reliable authority of certifications, domain seizure, ...)<br>
<br>
* designed for that :<br>
- namecoin uses a system of namespaces to separate each usages :
<a class="moz-txt-link-freetext" href="http://dot-bit.org/Main_Page#Namespaces">http://dot-bit.org/Main_Page#Namespaces</a>.<br>
For example, the "personal namespace" draft
(<a class="moz-txt-link-freetext" href="http://dot-bit.org/Personal_Namespace">http://dot-bit.org/Personal_Namespace</a>) could be extended to support
mapping to a bitcoin address, or a dedicated namespace can be used
if prefered (the "bitcoin/" or "alias/" or "map/" prefixes for
example).<br>
<br>
* easily connectable to bitcoin<br>
- they both use RPC and json to exchange informations, so connecting
one to the other is really easy<br>
- bitcoin could even allow registration of names by sending an RPC
request to namecoin<br>
<br>
* extensible and not limited :<br>
- you are not forced to store a bitcoin address directly in
namecoin, you can also store an url or a domain name<br>
- allows additional security : add a certificate fingerprint
combined with an https url (so, using DNS or HTTP(S) is not a major
problem anymore if the first point of entry is really secure and
configurable [and you use and self-signed certificate])<br>
- really easy to update<br>
- simple for simple cases<br>
- possibility to use a nick, an email address or a domain as name<br>
- other methods to get bitcoins addresses can be added later,
protocol is extensible<br>
<br>
<br>
Examples of possible registered names in namecoin with the "personal
namespace" (with the "p/" prefix) :<br>
<br>
* An individual person with well known public addresses :<br>
"p/<b>khal</b>":<br>
{<br>
"email": <a class="moz-txt-link-rfc2396E" href="mailto:khal@dot-bit.org">"khal@dot-bit.org"</a>,<br>
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",<br>
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"<br>
}<br>
<br>
* Another individual person with well known public addresses :<br>
"p/<b><a class="moz-txt-link-abbreviated" href="mailto:khal@dot-bit.org">khal@dot-bit.org</a></b>":<br>
{<br>
"bitcoin": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",<br>
"namecoin": "N1KHAL5C1CRzy58NdJwp1tbLze3XrkFxx9"<br>
}<br>
<br>
* A merchant accepting payments in bitcoin, namecoin, paypal or
othercoin (to show you how the whole namespace could be used) :<br>
"p/<b>mymerchant.com</b>":<br>
{<br>
"bitcoin": {<br>
"url": <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/bitcoin/">"https://payto.mymerchant.com/bitcoin/"</a>,<br>
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"<br>
"cert": <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/certificate.pem">"https://payto.mymerchant.com/certificate.pem"</a>,<br>
},<br>
"namecoin": {<br>
"url": <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/namecoin/">"https://payto.mymerchant.com/namecoin/"</a>,<br>
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926"<br>
},<br>
"paypal": <a class="moz-txt-link-rfc2396E" href="mailto:xxxxxx@yyyyyyyyy.zzz">"xxxxxx@yyyyyyyyy.zzz"</a>,<br>
"othercoin": "oxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"<br>
}<br>
<br>
* A merchant with a public address, an url to generate custom
addresses and a domain name (not sure if this case is really
usefull, maybe as fallback)<br>
"p/<b>mymerchant2</b>":<br>
{<br>
"bitcoin": {<br>
"url": <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/bitcoin/">"https://payto.mymerchant.com/bitcoin/"</a>,<br>
"fpr": "54FFA829023FC4DEF26B9339E07F7A743DF9F926",<br>
"dns": "_bitcoin.payto.mymerchant.com",<br>
"address": "1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T",<br>
}<br>
}<br>
<br>
<br>
* How to use it in bitcoin ?<br>
<br>
Several possibilities of address syntax :<br>
- khal, <a class="moz-txt-link-abbreviated" href="mailto:khal@dot-bit.org">khal@dot-bit.org</a>, mymerchant.com, mymerchant2 : no syntax
limit<br>
- mymerchant2@bitcoin : will conflict with names already containing
a @<br>
- mymerchant2@namecoin : same<br>
- namecoin:mymerchant2 : strange syntax, confusing with the "uri
scheme"<br>
- namecoin://mymerchant2 : same<br>
- other ?<br>
<br>
<br>
Here is how things would be processed when people put an address to
pay to in the bitcoin client :<br>
<br>
* address : khal<br>
-> RPC to namecoin for "p/khal"<br>
-> json processing for "p/khal->bitcoin"<br>
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T<br>
<br>
* address : <a class="moz-txt-link-abbreviated" href="mailto:khal@dot-bit.org">khal@dot-bit.org</a><br>
-> RPC to namecoin for <a class="moz-txt-link-rfc2396E" href="mailto:p/khal@dot-bit.org">"p/khal@dot-bit.org"</a><br>
-> json processing for "<a class="moz-txt-link-abbreviated" href="mailto:p/khal@dot-bit.org">p/khal@dot-bit.org</a>->bitcoin"<br>
-> result : 1KHAL8bUjnkMRMg9yd2dNrYnJgZGH8Nj6T<br>
<br>
* address : mymerchant.com<br>
-> RPC to namecoin for "p/mymerchant.com"<br>
-> json processing for "p/mymerchant.com->bitcoin"<br>
-> json processing for "p/mymerchant.com->bitcoin->url" and
"p/mymerchant.com->bitcoin->fpr"<br>
-> https request to <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/bitcoin/">"https://payto.mymerchant.com/bitcoin/"</a><br>
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy<br>
<br>
* address : mymerchant2<br>
-> RPC to namecoin for "p/mymerchant2"<br>
-> json processing for "p/mymerchant2->bitcoin"<br>
-> json processing for "p/mymerchant2->bitcoin->url" and
"p/mymerchant2->bitcoin->fpr"<br>
-> https request to <a class="moz-txt-link-rfc2396E" href="https://payto.mymerchant.com/bitcoin/">"https://payto.mymerchant.com/bitcoin/"</a><br>
-> result : error (website unavailable, page not found, timeout,
etc)<br>
-> json processing for "p/mymerchant2->bitcoin->dns"<br>
-> dns request for "_bitcoin.payto.mymerchant.com"<br>
-> result : 1xyxyxyxyxyxyxyxyxyxyxyxyxyxy<br>
<br>
<br>
Le 15/12/2011 20:59, theymos a écrit :
<blockquote
cite="mid:1323979147.27319.140661012141129@webmail.messagingengine.com"
type="cite">
<pre wrap="">Bitcoin already has code and a protocol for transactions to IP
addresses. Why not reuse that for dynamic address lookup? Just a few
changes are necessary to enable complete <a class="moz-txt-link-abbreviated" href="mailto:user@server.com">user@server.com</a> handling:
- Extend the protocol so that "reply" messages can be signed by a fixed
public key
- Extend "checkorder" messages so they can specify an account to
send BTC to. Or standardize on how to put the account into the
message field.
- Enable DNS lookups for IP transactions. The DNS-only proposals could
also be used here to avoid having to use the IP transaction protocol
sometimes. The public key for signing "reply" messages can be gotten
from TXT records. This will be safe with DNSSEC and Namecoin. With
plain DNS Bitcoin could take a SSH-like approach and ask the user to
verify the public key the first time it is used, remembering it later.
DoS attacks are already handled by the IP transactions code: the same IP
address is always given the same bitcoin address until it pays to that
bitcoin address.
------------------------------------------------------------------------------
10 Tips for Better Server Consolidation
Server virtualization is being driven by many needs.
But none more important than the need to reduce IT complexity
while improving strategic productivity. Learn More!
<a class="moz-txt-link-freetext" href="http://www.accelacomm.com/jaw/sdnl/114/51507609/">http://www.accelacomm.com/jaw/sdnl/114/51507609/</a>
_______________________________________________
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>
<br>
<pre class="moz-signature" cols="72">--
Best Regards,
Khalahan
<a class="moz-txt-link-freetext" href="http://dot-bit.org/">http://dot-bit.org/</a></pre>
</body>
</html>
--------------060608040301030600010103--
|