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
|
Return-Path: <thomasv@electrum.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B09E65
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 13:29:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net
[217.70.183.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E9FD8D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 13:29:44 +0000 (UTC)
Received: from mfilter47-d.gandi.net (mfilter47-d.gandi.net [217.70.178.178])
by relay5-d.mail.gandi.net (Postfix) with ESMTP id 0DB7F41C05A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 15:29:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter47-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197])
by mfilter47-d.gandi.net (mfilter47-d.gandi.net [::ffff:10.0.15.180])
(amavisd-new, port 10024) with ESMTP id QT7y2PUafb78
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 15:29:40 +0200 (CEST)
X-Originating-IP: 78.51.246.170
Received: from [192.168.1.2] (f051246170.adsl.alicedsl.de [78.51.246.170])
(Authenticated sender: thomasv@electrum.org)
by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 6722A41C054
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 15:29:40 +0200 (CEST)
Message-ID: <55AA54C3.7010806@electrum.org>
Date: Sat, 18 Jul 2015 15:29:39 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <CABqynx+YAgt404zXAqwq9_AjvmX6J0=vBi=xK_56AdsR8nMF+A@mail.gmail.com>
In-Reply-To: <CABqynx+YAgt404zXAqwq9_AjvmX6J0=vBi=xK_56AdsR8nMF+A@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 18 Jul 2015 13:29:45 -0000
Le 14/07/2015 19:29, Justin Newton a =E9crit :
> Hi there. You are correct that we are a company providing a service,
> however, that service is also based on an open standard which we are
> proposing. I'll be honest that we haven't done the greatest job in
> promoting the standard so far. More coming soon on that front. Any
> of the Open Source Wallet Name resolvers that we have created do
> lookups against the standard record formats, and not directly against
> our servers in any way. Information on the record formats as well as
> links to the lookup API server and some early libraries can be found
> here: https://www.netki.com/#/developers and here:
> https://github.com/netkicorp
>=20
Sorry to answer late, and thanks for the clarification. After talking
with you, I believe that it will not be difficult to agree on a common
standard, that gives maximum freedom to everyone.
I also believe that it is in Netki's interest to convey the message that
they are actively promoting an open standard, and not pushing a private
solution. For this reason, and assuming that the future standard
satisfies you fully, will you mind if that standard carries a neutral
name (such as "OpenAlias v2", or "BIP xx"), instead of being named after
your company? I reckon that is purely a PR issue.
> To break it down briefly, we have an open lookup standard based on
> both the namecoin blockchain as well as traditional DNSSEC. (You can
> choose your own adventure of using namecoin based names or traditional
> ICANN names).
I would rather not make Namecoin part of the standard, because .bit
records cannot be verified easily by lightweight/spv wallets; they would
need a copy of the Namecoin blockchain for that.
> Differences:
>=20
> 1> We do not use DNSCrypt. I understand why you chose to, but we were
> concerned about broad interoperability and easy broad distribution of
> hosting, so decided not to use it. We have other ways of achieving
> privacy, using HD Wallets and Payment Requests.
>=20
As far as Electrum is concerned, I do not see DNSCrypt as something
usable in the short term. I do not think it should be mandated, because
there are other ways of achieving privacy, as you say.
> 2> We have the option of storing a URL rather than just a wallet
> address in the TXT record. This allows a second level lookup against
> the URL to get back a unique HD Wallet address or Payment Request each
> time, further protecting user privacy and security. Using Wallet
> Names with Payment Requests allows for the user experience of typing
> in an easy to remember name and getting back the "green lock" and who
> the validated recipient is. This also provides an auto audit of the
> end to end DNS SEC process, in the case the path were somehow
> compromised, the signature on the payment request can provide an
> additional check.
>=20
I see value in the ability to store differerent types of strings in TXT
records. In particular, I have the need to store an email address, and
more than one Bitcoin address or xpubkey per alias.
> 3> We use a 2 tier lookup format. The first lookup returns a list of
> currencies or payment types supported by the Wallet Name. The second
> lookup goes to a record specific to that currency type to get the
> address to go to. We believe this to be a more scalable solution in a
> world where someone can have both multiple digital currency types, but
> then also multiple types of colored coins, and wants a simple way to
> share a single name for all of those different addresses. This allows
> the wallet to do the work behind the scene of choosing the currency it
> wants to send, and automatically getting back the right address to
> send to, without the user having to do anything different.
>=20
This seems to be a major difference, and I believe it makes sense to do
it the way you describe. Does that solution fully replace the tags used
in OpenAlias, or does it make sense to combine these two systems?
> 4> We mandate DNSSEC while you make it optional. We did this because
> we believe giving the user the option of NOT using DNSSEC is like
> letting them order a car with no brakes. We weren't sure how we would
> explain to them why their money was gone when they really didn't
> understand the risks they were taking up front. We had a lot of
> discussion about it before coming to the decision we did, and I can
> see why you went the other way, although I do believe we made the
> right choice.
I agree on this; there is no point using OpenAlias without DNSSEC.
Wallets can use fallback servers if the default DNS does not have DNSSEC.
>=20
>=20
> Additionally, we just released another open source API server to help
> with the "other half" of the lookup problem. Its in its infancy, and
> we are certainly taking feedback on it at this time. It is called
> Addressimo <https://github.com/netkicorp/addressimo> and will serve
> unique HD Wallet addresses or Payment Requests for every lookup, thus
> allowing a user to have a private, secure way to share a Wallet Name
> that can be used to send them any digital currency.
>=20
> I'd love to talk here or offline about merging standards going
> forward. As an FYI, Verisign has also delivered a standard to the
> IETF using DNSSEC to pass payment information here:
> https://tools.ietf.org/html/draft-wiley-paymentassoc-00 We have
> started discussions with them about merging standards as well.
>=20
That is nice, but may be out of scope here. Isn't there a risk that
involving the IETF would make the process a lot slower? Of course it
would be great, but maybe we should try to reach consensus at our level
first (the bitcoin level), before trying to merge with them.
>=20
> They actually have a really nice way in their standard to encode email
> addresses that more or less ensures that there won't be name space
> collision in the case that there is already a record "joe.user.com"
> and you want to create one for "joe@user.com" that we are looking at
> adding to what we are doing in the next update to our record formats.
>=20
>=20
> In any case, I'd much rather we had one effort going forward than
> multiples, so let's talk!
>=20
|
