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
|
Return-Path: <hearn@vinumeris.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CA251307
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 11:46:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com
[209.85.223.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3CBFE11A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 11:46:27 +0000 (UTC)
Received: by iebmu5 with SMTP id mu5so91990206ieb.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 18 Jul 2015 04:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=vinumeris.com; s=google;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=rbU4lSneCtG4Is6DdQvQq4hi0N/taKYLV2GCcoHmj9A=;
b=NfmgVYpgAOBrxmLmLi1KfbSHE2s0tWdF3d3nK0M9p0TntdglhBic+hultK3+XfxSNf
7IMhRm2JrT/L+igKgvCX7hkuY/nnM7wqrb/mdMDqtR/8nbfTxzmKh8n2zbiQO9zJzZsD
TdgawtKs53/C5JiGlDDvTVNgu1kqS55fdI/zY=
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:cc:content-type;
bh=rbU4lSneCtG4Is6DdQvQq4hi0N/taKYLV2GCcoHmj9A=;
b=LGNbiB6seYpig/HRypMm7Q6LEwtLZ2yok31xzfeGgt6vh6ukhgMi9fwKHZCsVM9fbZ
9VYI4UdLEWykha4Koi/w9cEDoQnPHhCEgaUcQXXMQ5c5JkjkyMxE2rayYeaqKqwxZ10H
UxqRthaJm0vEbE4ubCaYBffsmlSnAt6A5WA6JaxZhsCtcbHRKYq/k4/Gov0gTM2sEkWJ
sEXcwEdDmuqIlwhnS4tJQWap05+pZI50xsK/ZLKiBzoqWO1xN8bskkndsjOQFtSj7nF6
YB2WmHPesQS3rSpuvEMFbQQA/aJeI1OMPmHoDFW+8wzIh6gtUk1TIjTEIzqPPOgvLUdS
DV0w==
X-Gm-Message-State: ALoCoQkMG9Ww71yDWUnlFOd/KIDNBn57LYq4xo1jGjSX9CcM8RlOTMQ8+kYLt+OHuggqYY+QXl/T
MIME-Version: 1.0
X-Received: by 10.107.129.215 with SMTP id l84mr8005011ioi.78.1437219986692;
Sat, 18 Jul 2015 04:46:26 -0700 (PDT)
Received: by 10.50.108.111 with HTTP; Sat, 18 Jul 2015 04:46:26 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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
Cc: bitcoin-dev@lists.linuxfoundation.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 11:46:27 -0000
--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's surprisingly fa=
st - fast enough to be usable and I'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's slower of course.</div><div><br></div><div>With c=
old Tor caches it's indeed too slow. However, reaching "tor by def=
ault" 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 -> fallback to<br>
OpenAlias API pool (which can return DNSSEC data for verification) -><br=
>
fallback to default resolver.</blockquote><div><br></div><div>That seems re=
asonable for Electrum. I don'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--
|
