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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1RbdsA-0002yD-5s
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 19:55:14 +0000
X-ACL-Warn:
Received: from mail-ey0-f175.google.com ([209.85.215.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rbds8-0001kr-QY
for bitcoin-development@lists.sourceforge.net;
Fri, 16 Dec 2011 19:55:14 +0000
Received: by eaal1 with SMTP id l1so4690550eaa.34
for <bitcoin-development@lists.sourceforge.net>;
Fri, 16 Dec 2011 11:55:06 -0800 (PST)
Received: by 10.204.145.74 with SMTP id c10mr3302416bkv.62.1324065306405; Fri,
16 Dec 2011 11:55:06 -0800 (PST)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.204.168.15 with HTTP; Fri, 16 Dec 2011 11:54:35 -0800 (PST)
In-Reply-To: <4EEB7E98.8030006@dot-bit.org>
References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com>
<1323979147.27319.140661012141129@webmail.messagingengine.com>
<4EEB7E98.8030006@dot-bit.org>
From: slush <slush@centrum.cz>
Date: Fri, 16 Dec 2011 20:54:35 +0100
X-Google-Sender-Auth: N6AD_rTWx1IqEBmDPFk2EP9SdXs
Message-ID: <CAJna-HjXp4XEHnbmX0HKsMDmnxoWQQMmqujN+D9nLV0Zz_omcg@mail.gmail.com>
To: Khalahan <khal@dot-bit.org>
Content-Type: multipart/alternative; boundary=001517493b7c3f6a6c04b43afa99
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(slush[at]centrum.cz)
1.0 HTML_MESSAGE BODY: HTML included in message
0.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Rbds8-0001kr-QY
Cc: bitcoin-development@lists.sourceforge.net
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 19:55:14 -0000
--001517493b7c3f6a6c04b43afa99
Content-Type: text/plain; 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.
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
https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
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
On Fri, Dec 16, 2011 at 6:23 PM, Khalahan <khal@dot-bit.org> wrote:
> **
> 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.
>
>
--001517493b7c3f6a6c04b43afa99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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' po=
ol supporting merged mining), but I think there's really long way to pr=
ovide 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 addres=
ses into my fork of Electrum client. I did it in 15 minutes, it works as ex=
pected, it does the job and the implementation is really transparent, becua=
se implementation is 20 lines of code. There's no magic transformation,=
no forced "?handle=3D" parameters or whatever. And I don't c=
are if somebody provide URL <a href=3D"https://some.strange.domain/name-of-=
my-dog?myhandle=3D5678iop&anything_else=3DTrue">https://some.strange.do=
main/name-of-my-dog?myhandle=3D5678iop&anything_else=3DTrue</a></div>
<div><br></div><div>And everybody can do the same in their clients, in thei=
r 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 potenti=
al in PR. So far I understand it as some teoretic concept which is not supp=
orted by anything else right now. Give it few years until it matures and th=
en 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 b=
itcoin addresses for normal users. Using some superior technology, which is=
hard to implement or even understand won't solve the situation, becaus=
e it will ends up with some reference implementation in standard client onl=
y and nobody else will use it.</div>
<div><br></div><div>slush<br><br><div class=3D"gmail_quote">On Fri, Dec 16,=
2011 at 6:23 PM, Khalahan <span dir=3D"ltr"><<a href=3D"mailto:khal@dot=
-bit.org">khal@dot-bit.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">
<u></u>
=20
=20
=20
<div bgcolor=3D"#ffffff" text=3D"#000000"><div><div class=3D"h5">
Namecoin is a peer-to-peer generic name/value datastore system.<br>
Don't forget it's not limited to .bit usage ! So, directly mapp=
ing
things to .bit url would not be the optimal way of using namecoin.<br><=
br></div></div></div></blockquote></div></div></div>
--001517493b7c3f6a6c04b43afa99--
|
