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
|
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 <khal@dot-bit.org>) id 1RbfhR-0005bm-L2
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 21:52:17 +0000
Received-SPF: pass (sog-mx-1.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-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RbfhQ-000846-3a
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 21:52:17 +0000
Received: by srv01.web-sweet-web.net (Postfix, from userid 1000)
id 43ABB165E00A; Fri, 16 Dec 2011 22:52:09 +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.5 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 AF94D165E007
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 22:52:05 +0100 (CET)
Message-ID: <4EEBBD84.6020907@dot-bit.org>
Date: Fri, 16 Dec 2011 22:52:04 +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>
<4EEB7E98.8030006@dot-bit.org>
<CAJna-HjXp4XEHnbmX0HKsMDmnxoWQQMmqujN+D9nLV0Zz_omcg@mail.gmail.com>
In-Reply-To: <CAJna-HjXp4XEHnbmX0HKsMDmnxoWQQMmqujN+D9nLV0Zz_omcg@mail.gmail.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/alternative;
boundary="------------040408060708060107090801"
X-Spam-Score: -0.7 (/)
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.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RbfhQ-000846-3a
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 21:52:17 -0000
This is a multi-part message in MIME format.
--------------040408060708060107090801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The number of proposals <https://en.bitcoin.it/wiki/BIP_0015> is not
infinite, here are their problems :
- FirstBits : centralized
- DNS TXT Records : DNSSEC is required to have a minimum of security,
limits usage to engineers, limits usage to some domain names (i won't be
able to use a gmail address for example, because i don't control the
gmail.com domain)
- Server Service (DNS + a daemon) : Same as DNS TXT records
- HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be able
to check the full certificate chain and access a list of up-to-date
certificate authorities (installed on the OS or provided with bitcoin).
And don't forget the CA model is not 100% reliable (several CA hacked
this year + possible government control...).
- IP Transactions : /This proposal seeks to enable DNS lookups for IP
transactions/ =3D> same as above
I know that providing a namecoin daemon with bitcoin is not the lighter
solution, but, if a better one existed i guess it would have already
been integrated into bitcoin... (see in what state is my first attempt
with the HTTPS proposal : Send payments to emails, urls and domains in
GUI <https://github.com/bitcoin/bitcoin/pull/174> - /khalahan opened
this pull request April 20, 2011/)
So, what's next ?
Le 16/12/2011 20:54, slush a =E9crit :
> Khalahan, honestly, using namecoin for aliases is (for me) clean
> example of over-engineering. I mean - it will definitely work if
> implemented properly. I played with a namecoin a bit (as my pool was
> the first 'big' pool supporting merged mining), but I think there's
> really long way to provide such alias system in namecoin and *cleanly
> integrate it with bitcoin*. Don't forget that people who want to do
> lookup need to maintain also namecoin blockchain with their bitcoin
> client. It goes against my instinct of keeping stuff easy.
>
> For example, yesterday I implemented HTTPS lookup for addresses into
> my fork of Electrum client. I did it in 15 minutes, it works as
> expected, it does the job and the implementation is really
> transparent, becuase implementation is 20 lines of code. There's no
> magic transformation, no forced "?handle=3D" parameters or whatever. An=
d
> I don't care if somebody provide URL
> https://some.strange.domain/name-of-my-dog?myhandle=3D5678iop&anything_=
else=3DTrue
> <https://some.strange.domain/name-of-my-dog?myhandle=3D5678iop&anything=
_else=3DTrue>
>
> And everybody can do the same in their clients, in their merchant
> solutions, websites or whatever. Everybody can do HTTPS lookup. But
> try to explain DNS, Namecoin, IIBAN, email aliases to other programmers=
...
>
> Those IIBAN - well, why not. At least I see the potential in PR. So
> far I understand it as some teoretic concept which is not supported by
> anything else right now. Give it few years until it matures and then
> add IIBAN alias to Bitcoin client too.
>
> Maybe I'm repeating myself already, but the way to go is to make
> aliases as easy as possible, so everybody can implement it in their
> own solution and thus practially remove the need of using standard
> bitcoin addresses for normal users. Using some superior technology,
> which is hard to implement or even understand won't solve the
> situation, because it will ends up with some reference implementation
> in standard client only and nobody else will use it.
>
> slush
--=20
Best Regards,
Khalahan
http://dot-bit.org/
--------------040408060708060107090801
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">
The <a href="https://en.bitcoin.it/wiki/BIP_0015">number of
proposals</a> is not infinite, here are their problems :<br>
<br>
- FirstBits : centralized<br>
- DNS TXT Records : DNSSEC is required to have a minimum of
security, limits usage to engineers, limits usage to some domain
names (i won't be able to use a gmail address for example, because i
don't control the gmail.com domain)<br>
- Server Service (DNS + a daemon) : Same as DNS TXT records<br>
- HTTPS Web service : relies on HTTPS and CA, bitcoin needs to be
able to check the full certificate chain and access a list of
up-to-date certificate authorities (installed on the OS or provided
with bitcoin). And don't forget the CA model is not 100% reliable
(several CA hacked this year + possible government control...).<br>
- IP Transactions : <i>This proposal seeks to enable DNS lookups
for IP transactions</i> => same as above<br>
<br>
I know that providing a namecoin daemon with bitcoin is not the
lighter solution, but, if a better one existed i guess it would have
already been integrated into bitcoin... (see in what state is my
first attempt with the HTTPS proposal : <a
href="https://github.com/bitcoin/bitcoin/pull/174">Send payments
to emails, urls and domains in GUI</a> - <i>khalahan opened this
pull request April 20, 2011</i>)<br>
<br>
So, what's next ?<br>
<br>
Le 16/12/2011 20:54, slush a écrit :
<blockquote
cite="mid:CAJna-HjXp4XEHnbmX0HKsMDmnxoWQQMmqujN+D9nLV0Zz_omcg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
Khalahan, honestly, using namecoin for aliases is (for me) clean
example of over-engineering. I mean - it will definitely work if
implemented properly. I played with a namecoin a bit (as my pool
was the first 'big' pool supporting merged mining), but I think
there's really long way to provide such alias system in namecoin
and *cleanly integrate it with bitcoin*. Don't forget that people
who want to do lookup need to maintain also namecoin blockchain
with their bitcoin client. It goes against my instinct of keeping
stuff easy.
<div>
<br>
</div>
<div>For example, yesterday I implemented HTTPS lookup for
addresses into my fork of Electrum client. I did it in 15
minutes, it works as expected, it does the job and the
implementation is really transparent, becuase implementation is
20 lines of code. There's no magic transformation, no forced
"?handle=" parameters or whatever. And I don't care if somebody
provide URL <a moz-do-not-send="true"
href="https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True">https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True</a></div>
<div><br>
</div>
<div>And everybody can do the same in their clients, in their
merchant solutions, websites or whatever. Everybody can do HTTPS
lookup. But try to explain DNS, Namecoin, IIBAN, email aliases
to other programmers...<br>
<div><br>
</div>
<div>Those IIBAN - well, why not. At least I see the potential
in PR. So far I understand it as some teoretic concept which
is not supported by anything else right now. Give it few years
until it matures and then add IIBAN alias to Bitcoin client
too.</div>
<div><br>
</div>
<div>Maybe I'm repeating myself already, but the way to go is to
make aliases as easy as possible, so everybody can implement
it in their own solution and thus practially remove the need
of using standard bitcoin addresses for normal users. Using
some superior technology, which is hard to implement or even
understand won't solve the situation, because it will ends up
with some reference implementation in standard client only and
nobody else will use it.</div>
<div><br>
</div>
<div>slush<br>
</div>
</div>
</blockquote>
<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>
--------------040408060708060107090801--
|
