From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4B8F4282 for ; 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 ; Mon, 27 Jul 2015 22:47:10 +0000 (UTC) Received: by vnav141 with SMTP id v141so36590708vna.0 for ; 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 Date: Tue, 28 Jul 2015 00:46:50 +0200 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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