summaryrefslogtreecommitdiff
path: root/ab/60e3d6828d611ed9e91dd85d55a7da54dc43f1
blob: 3b7852b37177762563958de449e0ed9188885ec7 (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
Return-Path: <justin@netki.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 523F8305
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 18 Jul 2015 23:01:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com
	[209.85.214.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB90312D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 18 Jul 2015 23:01:40 +0000 (UTC)
Received: by obbgp5 with SMTP id gp5so83921817obb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 18 Jul 2015 16:01:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type:content-transfer-encoding;
	bh=Z1TAKnapjjMw9N+kVkgNj3I3kb2lBlAfKu9iCUeQAyE=;
	b=Mh4h8rt5VKAbamL1wdR+G95+v28E96mwemXv1iPBoxjkfa90TIXIrsAfDBf6hYLSy0
	WfS2PyFzjxvMKUXnb9CIYOTXFTV0IalAxhYTiFZPawuHgfsG/oVJsto0qqTZUGjZ3vtg
	ll914WlWu5Sh1jghq4eN+zVgFR5NFZhThOe+tRhVSMzP9Zc+hm+dHaZP16Fs+sOqoKIu
	uUWvgkrrt/cFOlslztgAK6yAEXQe+MhVzyQRvou3QgXKhIs8vO5Rl0QFvpoQfyCKu1j7
	BWub3cUCnVtfwbijWD19NPiXtNwcCOKtVE+waXtnrXjTyAr/WIMGXLUH8fblNH1WCgeT
	EpjA==
X-Gm-Message-State: ALoCoQlK/mj4Tzsl0fz6WJsViy2uc8nPRhZWxhvoEph/grzVormUaS7vVB93/oGmB7dN7IVJJCcc
MIME-Version: 1.0
X-Received: by 10.182.86.39 with SMTP id m7mr20373551obz.18.1437260500025;
	Sat, 18 Jul 2015 16:01:40 -0700 (PDT)
Received: by 10.202.221.66 with HTTP; Sat, 18 Jul 2015 16:01:39 -0700 (PDT)
In-Reply-To: <55AA54C3.7010806@electrum.org>
References: <CABqynx+YAgt404zXAqwq9_AjvmX6J0=vBi=xK_56AdsR8nMF+A@mail.gmail.com>
	<55AA54C3.7010806@electrum.org>
Date: Sat, 18 Jul 2015 16:01:39 -0700
Message-ID: <CABqynx+X9j3UviQGp-Vaf77gKM9TAJZxnWkfA3DgmSELxu1RhQ@mail.gmail.com>
From: Justin Newton <justin@netki.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
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 23:01:42 -0000

On Sat, Jul 18, 2015 at 6:29 AM, Thomas Voegtlin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Le 14/07/2015 19:29, Justin Newton a =C3=A9crit :
>

>
> 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.

100% agreed.

>
> 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 be clear, the current name of the service is Wallet Name Service,
Netki has tended to be tagged to it as people are associating the
service with us.  We also intend to offer more services than just
this, so its actually not really good for us to think of Netki as the
service name.  I have no issues with a neutral name for the lookup
standard.


>
>
> > 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.

You are the second person to raise this.  Clearly this is an item that
requires some discussion before anything is decided for sure.  We had
gone this direction (and I assume Riccardo did as well) to provide a
censor resistant option as well as one that would be low cost for
individuals to be able register their own names.  This also allows for
lookups that never leave the local network.  The trade off there for
mobile wallets was one I feel we failed to properly consider.


<SNIPPING AREAS OF APPARENT AGREEMENT>
>
> > 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.
> >
>
> 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?

I think combining formats to use both the two level lookups and tags
could have value.  Tags could include information like versioning, as
well as whether what is being returned is an address, URL for further
lookup, or other piece of information.



<SNIPPING MORE AGREEMENT>

>
> > 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.
> >
>
> 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.

I concur with this approach.  I think it makes sense for us to stay in
contact and communication with the IETF side with the hope of ending
up with something that is, in the end the same, or at least
compatible.  I also agree that we shouldn't wait on the IETF to move
ahead ourselves, more stay in communication with them so that we don't
end up accidentally going in opposite directions, and also so we can
learn best practices from each other along the way.

As you can see, this has been our approach up until now where we have
gone ahead and built and expanded our "standard" based on our
discussions and integrations with other industry participants.

Thanks for the feedback!

Justin




--=20

Justin W. Newton
Founder/CEO
NetKi, Inc.

justin@netki.com
+1.818.261.4248