MIME-Version: 1.0
In-Reply-To: <CADhj2oTosATt1hgMqRyBofg0XQ3qPzPzJoUqesKKuR4bETYiNg@mail.gmail.com>
References: <CADhj2oTosATt1hgMqRyBofg0XQ3qPzPzJoUqesKKuR4bETYiNg@mail.gmail.com>
Date: Sat, 18 Jul 2015 13:46:26 +0200
Message-ID: <CA+w+GKRSCX8QsfvwkHBASH6aa2Y0JTMYFqMsJbEhOD7Aj3kXpg@mail.gmail.com>
From: Mike Hearn <hearn@vinumeris.com>
To: Riccardo Spagni <ric@spagni.net>
Content-Type: multipart/alternative; boundary=001a113ec6acc578d4051b24da12
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Precedence: list

--001a113ec6acc578d4051b24da12
Content-Type: text/plain; charset=UTF-8

>
> Agreed, although I guess the bootstrap time for that is a little on
> the high side, and maybe a little too chunky on mobile devices


With warm Tor directory caches it's surprisingly fast - fast enough to be
usable and I'm a notorious stickler for low latency UX. If you want to do
LOTS of lookups so you can cross-check and merge their answers, that's
slower of course.

With cold Tor caches it's indeed too slow. However, reaching "tor by
default" is a part time hobby of the bitcoinj project for a while now and
there are plenty of ideas for how to make things fast enough. For instance,
using a cold cache whilst simultaneously refreshing it in the background,
doing nightly refreshes when charging, lengthening the expiry time, and the
Tor guys I believe want to implement directory differentials too which
would also help.


> My current thinking with Electrum (that ThomasV and I have bounced
> around) is to make the default policy DNSCrypt -> fallback to
> OpenAlias API pool (which can return DNSSEC data for verification) ->
> fallback to default resolver.


That seems reasonable for Electrum. I don't strongly care about these
protocols myself (and Justin knows this already), but whatever is decided
should give maximum freedom to wallet developers who disagree with you and
wish to explore other tradeoffs.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">Agreed, although I guess the bootstrap time for =
that is a little on<br>
the high side, and maybe a little too chunky on mobile devices</blockquote>=
<div><br></div><div>With warm Tor directory caches it&#39;s surprisingly fa=
st - fast enough to be usable and I&#39;m a notorious stickler for low late=
ncy UX. If you want to do LOTS of lookups so you can cross-check and merge =
their answers, that&#39;s slower of course.</div><div><br></div><div>With c=
old Tor caches it&#39;s indeed too slow. However, reaching &quot;tor by def=
ault&quot; is a part time hobby of the bitcoinj project for a while now and=
 there are plenty of ideas for how to make things fast enough. For instance=
, using a cold cache whilst simultaneously refreshing it in the background,=
 doing nightly refreshes when charging, lengthening the expiry time, and th=
e Tor guys I believe want to implement directory differentials too which wo=
uld also help.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">My current thinking with Electrum (that ThomasV and I have bounced<=
br>
around) is to make the default policy DNSCrypt -&gt; fallback to<br>
OpenAlias API pool (which can return DNSSEC data for verification) -&gt;<br=
>
fallback to default resolver.</blockquote><div><br></div><div>That seems re=
asonable for Electrum. I don&#39;t strongly care about these protocols myse=
lf (and Justin knows this already), but whatever is decided should give max=
imum freedom to wallet developers who disagree with you and wish to explore=
 other tradeoffs. =C2=A0</div></div></div></div>

--001a113ec6acc578d4051b24da12--