path: root/e4/5655b3282130ead283b9149895ba9b0602e1d2

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 C9695BA2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 01:01:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com
	[209.85.214.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A9B2126
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 01:01:21 +0000 (UTC)
Received: by obre1 with SMTP id e1so57661301obr.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 18:01:20 -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:cc:content-type;
	bh=qyLIIZd3hUYm5YdtCBTzSLuVd+xX9+a+HRoBtuu9cBY=;
	b=GGvtPTuIdWkfh1vnfMm74wH+LY9Q4ZXcM5T3ulbdqNx05hBAiMhR5L94ehCXJKEYUP
	5B/T3rnNi1tjI16QoV3rjAOSz96Se9ijSokAx6OgHL9Q94GXbJsGTe+06u3caQAVM6Wh
	HdyLMq3AXFzffLbN8J5QLTW0wSnaU8qBG7spovpCCPUz7yaIul6IKg7UgY+2WyZC6QnO
	TdZMDM2m+D0C5fBL3MnakEgwkxk79sp7vDhori7Y/Bn2lq0fBVC+pGi1FUh816WHH/Gm
	2IuXU5vs36It6gxsmtv+w/fQ7Sf6NoFjer6hFP3oWLuCtwTmFx1w4ea3O8ybCNkI59lJ
	M8Ng==
X-Gm-Message-State: ALoCoQmDJP1eijTkXgo4K6bx3Ile+tUJvZkgdzATK0Vtn3G7Jaj3F+cXPvqqe9WqZorAOohD2NYU
MIME-Version: 1.0
X-Received: by 10.182.86.39 with SMTP id m7mt8792774obz.18.1437094880785; Thu,
	16 Jul 2015 18:01:20 -0700 (PDT)
Received: by 10.202.221.66 with HTTP; Thu, 16 Jul 2015 18:01:20 -0700 (PDT)
In-Reply-To: <CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
References: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
	<CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
Date: Thu, 16 Jul 2015 18:01:20 -0700
Message-ID: <CABqynxL5AhEPLSw8TYjn9CVTc42+OHihKPGY6X3GP5W6u6TZaQ@mail.gmail.com>
From: Justin Newton <justin@netki.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0141a93ce0f0b0051b07b91c
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no 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: Fri, 17 Jul 2015 01:01:22 -0000

--089e0141a93ce0f0b0051b07b91c
Content-Type: text/plain; charset=UTF-8

[continued]



> 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.
>>
>
> We do the same thing, except in a single call. Here's an example of a
> record that has both XMR and BTC addresses:
> https://api.openalias.org/donate.getmonero.org?view=full (here are the
> DNS records for that:
> http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.org&run=toolpage
> )
>


We looked at doing this in a single lookup as you did.  With one or two
currencies this can be potentially more efficient.  As the number of
supported currencies and addresses under a single name grows, however, this
solution becomes potentially more problematic.  Please follow the use cases
below:

Use case 1:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

The only currency supported is bitcoin, and there are no colored coin
formats supported.

OpenAlias case:

1 packet lookup to "bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 1a:

The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets

In this use case we might create more traffic, but it could also be reduced
by doing smart lookups.


Use case 2:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

Many currencies and colored coin addresses are supported under the same
name, lets say 100.  When you count different currencies and colored coin
types, it could easily be hundreds, or over a thousand.


OpenAlias case:

1 packet lookup to "bob.foo.bar"
100 packet responses with various addresses

= 101 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 2a:

The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


While you may end doing "less lookups" under Open Alias, as it scales, you
end up causing a significant amount of extra, unnecessary traffic.

In addition to the obvious impact of being orders of magnitude more
wasteful than necessary, it also creates privacy "leakage" by returning
someone 100 different addresses when they only asked for one.

Finally, because a single packet UDP transaction for a DNS lookup can
create possibly hundreds of packets in response, the service can
essentially become an amplifier for DDoS attacks.  (If I spoof the source
address of my target with a query to a lookup that issues hundreds of
packets in response to one packet, and I can have a real impact :( )




>
>
>> 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.
>>
>
> With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm
> the address. The reasons are threefold:
>
> 1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones
> include some biggies like .sg, .za, and .to
>

I think this is a good point, and one we weighed.  When we were making our
original decisions.  Given the importance of ensuring that the lookups
return the correct value, and the known vulnerabilities in DNS without
DNSSEC, coupled with the fact that ICANN has mandated all zones and
registries move to DNSSEC, our belief was and is that it was worth the
trade off that there were cases where existing domains would not work.


It is important to note, that ICANN has "required" for some years that
registrars and registries support DNSSEC on the domains they register.  I
personally believe we shouldn't delay use of DNSSEC until their registries
had come up to current required Internet standards.  (Here are ICANN's
registrar requirements showing the DNSSEC requirement, btw:
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation
)

That said, what do others in the industry think?  We are basing our current
standard on our believed best practices, and defaulted to "first, lose no
money", given the irreversibility of bitcoin.



> 2. Even if the zone *is* signed, DNSSEC deployment is hard. Unmanaged
> DNSSEC deployment is out of scope for probably 99.9% of users, even the
> usually-technically-ok Bitcoin crowd. Managed DNSSEC is available, but is
> quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are the three big
> providers, and of those three only GoDaddy has a consumer-affordable
> product.
>


I think "DNSSEC is hard" is a bit of a boogey man that's not really true.
We are working on developing registrar by registrar instructions of how to
do this, and we have typically found that if you are setting up DNS by
yourself, adding DNSSEC doesn't take a lot of additional time, maybe an
hour or so depending on your registrar.

This known concern, however, is why when we launched our product (based on
our standard record formats) that we wanted to launch it with a variety of
options for people.

In addition to these options there are also other hosting providers, and
certain registrars that will allow you to setup DNSSEC on their DNS
platforms.


1> One could choose the "0 click" installation process of just getting a
free Wallet Name underneath their provider's name space.  This option has
been free to end users in all cases so far, and I expect it always will be
in the future (although that is up to the partner, so some may choose to
charge).

2> If they wanted some provider independence, but someone to manage things
for them, they can register a name through us and manage everything via our
web interface.  This can cost them as little as $1.95/yr through us.

3> Finally, for the "do it yourselfer" who wants full control themselves,
they can simply follow the formats on our developer page and do the whole
thing themselves.  If they do this by registering their own ".bit" this
will cost them less than $0.25.  If they have an existing domain name, even
less.






>
> 3. ThomasV and I have done a stack of testing behind residential and
> commercial routers where DNSSEC simply fails (eg. the router runs a really
> outdated DNS server that doesn't provide RRSIGs in its response, or the ISP
> doesn't care about DNSSEC). Unsurprisingly, this can be fixed by...you
> guessed it...doing the lookup via DNSCrypt.
>

That's some interesting data, and runs counter to the research of the IETF
DNS working group.  If you are willing to share your data, I can put you in
touch with the appropriate folks there to share your research.  I'd also
love to see it!



>
> Until we are closer to the bulk of all TLDs being signed, and DNSSEC
> becomes at least a little more ubiquitous, we can't lock out huge portions
> of the Internet, because then we're not really providing a useful and
> usable solution. All we can is make it more difficult to pay an unverified
> domain.
>
> Of course, if your aim is to force people to use you as a domain
> registrar, then it makes total sense why you'd lock people out;)
>

I'd argue that we aren't locking "huge portions" of the Internet.  You are
correct that about 15% of TLD's are not yet signed, even though they were
required to be by ICANN.

As I said above, I believe the requirement to not lose money and the fact
that other options are available for those running on TLD's that are out of
compliance, is worth the trade off that some existing names won't work
until their TLD's come into compliance with current Internet standards.

And, as we covered above, we don't force anyone to use our registrar, nor
any of our services in order for Wallet Names to work for them.  We never
have.  It's just not who we are.

--089e0141a93ce0f0b0051b07b91c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size:13px">[continued]</span><div styl=
e=3D"font-size:13px"><br></div><div style=3D"font-size:13px"><br></div><div=
 style=3D"font-size:13px"><span class=3D"im"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">3&gt; We use a 2 tier lookup format.=C2=A0 The first lookup =
returns a list of<br>currencies or payment types supported by the Wallet Na=
me.=C2=A0 The second<br>lookup goes to a record specific to that currency t=
ype to get the<br>address to go to.=C2=A0 We believe this to be a more scal=
able solution in a<br>world where someone can have both multiple digital cu=
rrency types, but<br>then also multiple types of colored coins, and wants a=
 simple way to<br>share a single name for all of those different addresses.=
=C2=A0 This allows<br>the wallet to do the work behind the scene of choosin=
g the currency it<br>wants to send, and automatically getting back the righ=
t address to<br>send to, without the user having to do anything different.<=
br></blockquote><div><br></div><div>We do the same thing, except in a singl=
e call. Here&#39;s an example of a record that has both XMR and BTC address=
es:=C2=A0<a href=3D"https://api.openalias.org/donate.getmonero.org?view=3Df=
ull" target=3D"_blank">https://api.openalias.org/donate.getmonero.org?view=
=3Dfull</a>=C2=A0(here are the DNS records for that:=C2=A0<a href=3D"http:/=
/mxtoolbox.com/SuperTool.aspx?action=3Dtxt%3adonate.getmonero.org&amp;run=
=3Dtoolpage" target=3D"_blank">http://mxtoolbox.com/SuperTool.aspx?action=
=3Dtxt%3adonate.getmonero.org&amp;run=3Dtoolpage</a>)</div></div></div></di=
v></blockquote><div><br></div><div><div></div></div></span><div><div class=
=3D"adm"><div id=3D"q_14e99999a9b01669_3" class=3D"ajR h4"><div class=3D"aj=
T" style=3D"opacity: 0.3;"></div></div></div><div class=3D"h5"><div><br></d=
iv><div><div>We looked at doing this in a single lookup as you did.=C2=A0 W=
ith one or two currencies this can be potentially more efficient.=C2=A0 As =
the number of supported currencies and addresses under a single name grows,=
 however, this solution becomes potentially more problematic.=C2=A0 Please =
follow the use cases below:</div><div><br></div><div>Use case 1: =C2=A0Wall=
et Name =3D &quot;bob.foo.bar&quot; or OpenAlias =3D &quot;bob.foo.bar&quot=
;</div><div><br></div><div>The only currency supported is bitcoin, and ther=
e are no colored coin formats supported.</div><div><br></div><div>OpenAlias=
 case:=C2=A0</div><div><br></div><div>1 packet lookup to &quot;bob.foo.bar&=
quot;</div><div>1 packet response with bitcoin address</div><div><br></div>=
<div>=3D 2 packets</div><div><br></div><div><br></div><div>Wallet Name case=
:</div><div><br></div><div>1 packet lookup to &quot;_wallet.bob.foo.bar&quo=
t;</div><div>1 packet response with supported address types</div><div>1 pac=
ket lookup to &quot;_btc._wallet.bob.foo.bar&quot;</div><div>1 packet respo=
nse with bitcoin address</div><div><br></div><div>=3D 4 packets</div><div><=
br></div><div>Wallet Name Case 1a:</div><div><br></div><div>The wallet doin=
g the lookup knows it wants bitcoin, so it skips the supported addresses lo=
okup</div><div><br></div><div>1 packet lookup to &quot;_btc._wallet.bob.foo=
.bar&quot;</div><div>1 packet response with bitcoin address</div><div><br><=
/div><div>=3D 2 packets</div><div><br></div><div>In this use case we might =
create more traffic, but it could also be reduced by doing smart lookups.</=
div><div><br></div><div><br></div><div><div>Use case 2: =C2=A0Wallet Name =
=3D &quot;bob.foo.bar&quot; or OpenAlias =3D &quot;bob.foo.bar&quot;</div><=
div><br></div><div>Many currencies and colored coin addresses are supported=
 under the same name, lets say 100.=C2=A0 When you count different currenci=
es and colored coin types, it could easily be hundreds, or over a thousand.=
</div><div><br></div><div><br></div><div>OpenAlias case:=C2=A0</div><div><b=
r></div><div>1 packet lookup to &quot;bob.foo.bar&quot;</div><div>100 packe=
t responses with various addresses</div><div><br></div><div>=3D 101 packets=
</div><div><br></div><div><br></div><div>Wallet Name case:</div><div><br></=
div><div>1 packet lookup to &quot;_wallet.bob.foo.bar&quot;</div><div>1 pac=
ket response with supported address types</div><div>1 packet lookup to &quo=
t;_btc._wallet.bob.foo.bar&quot;</div><div>1 packet response with bitcoin a=
ddress</div><div><br></div><div>=3D 4 packets</div><div><br></div><div><div=
>Wallet Name Case 2a:</div><div><br></div><div>The wallet doing the lookup =
knows it wants bitcoin, so it skips the supported addresses lookup</div><di=
v><br></div><div>1 packet lookup to &quot;_btc._wallet.bob.foo.bar&quot;</d=
iv><div>1 packet response with bitcoin address</div><div><br></div><div>=3D=
 2 packets</div></div></div><div><br></div><div><br></div><div>While you ma=
y end doing &quot;less lookups&quot; under Open Alias, as it scales, you en=
d up causing a significant amount of extra, unnecessary traffic. =C2=A0</di=
v><div><br></div><div>In addition to the obvious impact of being orders of =
magnitude more wasteful than necessary, it also creates privacy &quot;leaka=
ge&quot; by returning someone 100 different addresses when they only asked =
for one. =C2=A0</div><div><br></div><div>Finally, because a single packet U=
DP transaction for a DNS lookup can create possibly hundreds of packets in =
response, the service can essentially become an amplifier for DDoS attacks.=
 =C2=A0(If I spoof the source address of my target with a query to a lookup=
 that issues hundreds of packets in response to one packet, and I can have =
a real impact :( )</div></div><div><br></div><div><br></div><div>=C2=A0</di=
v></div></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex">4&gt; We manda=
te DNSSEC while you make it optional.=C2=A0 We did this because<span class=
=3D"im"><br>we believe giving the user the option of NOT using DNSSEC is li=
ke<br>letting them order a car with no brakes.=C2=A0 We weren&#39;t sure ho=
w we would<br>explain to them why their money was gone when they really did=
n&#39;t<br>understand the risks they were taking up front. We had a lot of<=
br>discussion about it before coming to the decision we did, and I can<br>s=
ee why you went the other way, although I do believe we made the<br>right c=
hoice.<br></span></blockquote><span class=3D"im"><div><br></div><div>With O=
penAlias a DNSSEC fail is a soft fail, and the user has to confirm the addr=
ess. The reasons are threefold:</div><div><br></div><div>1. At the moment o=
nly 83.5% of the TLDs are signed [2]. The unsigned ones include some biggie=
s like .sg, .za, and .to</div></span></div></div></div></blockquote><div><b=
r></div><span class=3D"im"><div>I think this is a good point, and one we we=
ighed.=C2=A0 When we were making our original decisions.=C2=A0 Given the im=
portance of ensuring that the lookups return the correct value, and the kno=
wn vulnerabilities in DNS without DNSSEC, coupled with the fact that ICANN =
has mandated all zones and registries move to DNSSEC, our belief was and is=
 that it was worth the trade off that there were cases where existing domai=
ns would not work.=C2=A0</div><div><br></div><div><br></div><div>It is impo=
rtant to note, that ICANN has &quot;required&quot; for some years that regi=
strars and registries support DNSSEC on the domains they register.=C2=A0 I =
personally believe we shouldn&#39;t delay use of DNSSEC until their registr=
ies had come up to current required Internet standards. =C2=A0(Here are ICA=
NN&#39;s registrar requirements showing the DNSSEC requirement, btw:=C2=A0<=
a href=3D"https://www.icann.org/resources/pages/approved-with-specs-2013-09=
-17-en#operation" target=3D"_blank">https://www.icann.org/resources/pages/a=
pproved-with-specs-2013-09-17-en#operation</a>)</div><div><br></div><div>Th=
at said, what do others in the industry think?=C2=A0 We are basing our curr=
ent standard on our believed best practices, and defaulted to &quot;first, =
lose no money&quot;, given the irreversibility of bitcoin.=C2=A0</div></spa=
n><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote">2. Even if the zone *is* s=
igned, DNSSEC deployment is hard. Unmanaged DNSSEC deployment is out of sco=
pe for probably 99.9% of users, even the usually-technically-ok Bitcoin cro=
wd. Managed DNSSEC is available, but is quite pricey. UltraDNS, Dyn, and Go=
Daddy (ikr?) are the three big providers, and of those three only GoDaddy h=
as a consumer-affordable product.</div></div></div></blockquote><div class=
=3D"yj6qo ajU"><div id=3D":w9" class=3D"ajR" tabindex=3D"0"><img class=3D"a=
jT" src=3D"https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif" st=
yle=3D"opacity: 0.3;"></div></div><div class=3D"adL"><br></div><div class=
=3D"adL"><br></div><div class=3D"adL"><span class=3D"im"><div>I think &quot=
;DNSSEC is hard&quot; is a bit of a boogey man that&#39;s not really true.=
=C2=A0 We are working on developing registrar by registrar instructions of =
how to do this, and we have typically found that if you are setting up DNS =
by yourself, adding DNSSEC doesn&#39;t take a lot of additional time, maybe=
 an hour or so depending on your registrar.=C2=A0</div><div><br></div><div>=
This known concern, however, is why when we launched our product (based on =
our standard record formats) that we wanted to launch it with a variety of =
options for people. =C2=A0</div><div><br></div><div>In addition to these op=
tions there are also other hosting providers, and certain registrars that w=
ill allow you to setup DNSSEC on their DNS platforms.</div><div><br></div><=
div><br></div><div>1&gt; One could choose the &quot;0 click&quot; installat=
ion process of just getting a free Wallet Name underneath their provider&#3=
9;s name space.=C2=A0 This option has been free to end users in all cases s=
o far, and I expect it always will be in the future (although that is up to=
 the partner, so some may choose to charge).</div><div><br></div><div>2&gt;=
 If they wanted some provider independence, but someone to manage things fo=
r them, they can register a name through us and manage everything via our w=
eb interface.=C2=A0 This can cost them as little as $1.95/yr through us. =
=C2=A0</div><div><br></div><div>3&gt; Finally, for the &quot;do it yourself=
er&quot; who wants full control themselves, they can simply follow the form=
ats on our developer page and do the whole thing themselves.=C2=A0 If they =
do this by registering their own &quot;.bit&quot; this will cost them less =
than $0.25.=C2=A0 If they have an existing domain name, even less.</div></s=
pan><div><br></div><div><br></div><div><br></div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><div><br></div><span class=3D"im">3. ThomasV and I have =
done a stack of testing behind residential and commercial routers where DNS=
SEC simply fails (eg. the router runs a really outdated DNS server that doe=
sn&#39;t provide RRSIGs in its response, or the ISP doesn&#39;t care about =
DNSSEC). Unsurprisingly, this can be fixed by...you guessed it...doing the =
lookup via DNSCrypt.</span></div></div></div></blockquote><div><br></div><s=
pan class=3D"im">That&#39;s some interesting data, and runs counter to the =
research of the IETF DNS working group.=C2=A0 If you are willing to share y=
our data, I can put you in touch with the appropriate folks there to share =
your research.=C2=A0 I&#39;d also love to see it!</span><div><br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div><br></div><span class=3D"im"><div>Until we a=
re closer to the bulk of all TLDs being signed, and DNSSEC becomes at least=
 a little more ubiquitous, we can&#39;t lock out huge portions of the Inter=
net, because then we&#39;re not really providing a useful and usable soluti=
on. All we can is make it more difficult to pay an unverified domain.</div>=
<div><br></div><div>Of course, if your aim is to force people to use you as=
 a domain registrar, then it makes total sense why you&#39;d lock people ou=
t;)</div></span></div></div></div></blockquote><div><br></div><span class=
=3D"im"><div>I&#39;d argue that we aren&#39;t locking &quot;huge portions&q=
uot; of the Internet.=C2=A0 You are correct that about 15% of TLD&#39;s are=
 not yet signed, even though they were required to be by ICANN. =C2=A0</div=
><div><br></div><div>As I said above, I believe the requirement to not lose=
 money and the fact that other options are available for those running on T=
LD&#39;s that are out of compliance, is worth the trade off that some exist=
ing names won&#39;t work until their TLD&#39;s come into compliance with cu=
rrent Internet standards.</div><div><br></div><div>And, as we covered above=
, we don&#39;t force anyone to use our registrar, nor any of our services i=
n order for Wallet Names to work for them.=C2=A0 We never have.=C2=A0 It&#3=
9;s just not who we are.</div></span><div><br></div><div><br></div><div><br=
></div><div>=C2=A0</div></div></div></div>

--089e0141a93ce0f0b0051b07b91c--