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
|
Return-Path: <ric@spagni.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B8F4282
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Jul 2015 22:47:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vn0-f45.google.com (mail-vn0-f45.google.com
[209.85.216.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CCE4214
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Jul 2015 22:47:10 +0000 (UTC)
Received: by vnav141 with SMTP id v141so36590708vna.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Jul 2015 15:47:09 -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:from:date:message-id:subject:to
:content-type;
bh=xAB1TY5+Z/+avZ8yLpABuDbkVEjL9vvTIn0nAEuRBbE=;
b=nHYu0pHZjjNsx+60U+eDKknqeCB2o2qw010YlmdsHbauiE6D6PqjMHPGhIJpvLBHXW
OcjqkjDfkDHMO+l5+HBBZT2m4tmBREya/JC7iS1OgAem1Dr4OVU/wWQhqF1SVQlfZjAw
dRNjyEr9l8+Ni2QOR6Xa1R2ha3wOmfeB+XDuQoQ6Jz4nws/STreKcR4EdTwGD0W2QhIv
mkds/o8SN13c6ZnqaBDbaPwXOLIEfW576BCwM2PPTVke1k2cZTN4PrakeJqneZ6Pzc9w
k71KRFkCQ+k23TOH2mqbzvHFbk+PLDy1gJqhaSh8ySBwQE/CvnCbYKBhWa89atHEDaML
iEIg==
X-Gm-Message-State: ALoCoQn+P/N/UklqCcdBLUT4uobZ9YrWUCjBSOgo1Pvfsyf7dSlwedADWwoCbDugIZkcTYQRbbld
X-Received: by 10.52.138.50 with SMTP id qn18mr25923348vdb.72.1438037229501;
Mon, 27 Jul 2015 15:47:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.92.197 with HTTP; Mon, 27 Jul 2015 15:46:50 -0700 (PDT)
From: Riccardo Spagni <ric@spagni.net>
Date: Tue, 28 Jul 2015 00:46:50 +0200
Message-ID: <CADhj2oTj91fqe3wvNNfS1yEp2faijmmQOGzj64z6_QsGHGsnuw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
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: Mon, 27 Jul 2015 22:47:11 -0000
There are several reasons why we rejected doing it this way with OpenAlias:
1. It adds complexity for the alias creator. This may seem
unimportant, but the OpenAlias standard was created to empower people
to create their own aliases as simply as possible, not to make it
overly complex.
2. It's harder to mess things up by dropping a sub-record; you either
have the complete, valid record, or you don't. With a "tiered" system
you can claim that you support a particular alias, but then lack all
or some of the records for it.
3. You retain both forward and backwards compatibility (no need to
introduce a new OA version unnecessarily), as you can have an "old" KV
pair and a "new" KV pair within the same record. The addition of KV
pairs doesn't require the application to know the new pairs exist,
which makes it more extensible.
4. Even better - since an application gets the whole record it can
start off with a minimum viable product that merely gets the address,
and then at a later stage when support is added for additional
metadata *it already has the metadata* and can interpret it.
5. You can still do DNS delegation (proper, SOA delegation) or you can
do delegation via a KV pair of some sort (say, a reroute= pair or
something). In both cases delegation requires an additional lookup, so
there's nothing saved or improved with the two-tier system.
In this instance, as in many others, simplicity trumps complexity, and
the bonus is that the simpler solution is more extensible and
flexible.
Riccardo
> Thinking about it, I think that it would be better to separate those two
> operations: on one hand, the listing of TXT records under a name, and on
> the other hand, the possibility to use Zone Delegation.
>
> For example, let us use the "_oa2" name (Openalias version 2) when we
> need to introduce an intermediate level, and "_oa2_keys" for key listing.
>
> Here is an example:
>
> _oa2_keys.sample 3600 IN TXT "btc ltc email fullname"
> _btc.sample 3600 IN TXT "bitcoinaddress"
> _ltc.sample 3600 IN TXT "litecoinaddress"
> _btc.sample 3600 IN TXT "otherbitcoinaddress"
> _email.sample 3600 IN TXT "john.smith@googlemail.com"
> _fullname.sample 3600 IN TXT "John Smith"
>
> Zone Delegation: Let us assume example.com wants to delegate all its
> Bitcoin aliases to Netki. We introduce an intermediate level, with the
> "_oa2" name. In the alias, this string is translated as "@"
>
> john._oa2.example.com <-- will be looked up as john@example.com
> _btc.john._oa2.example.com <-- bitcoin address of john@example.com
|
