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 CA251307 for ; 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 ; Sat, 18 Jul 2015 11:46:27 +0000 (UTC) Received: by iebmu5 with SMTP id mu5so91990206ieb.1 for ; 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: References: Date: Sat, 18 Jul 2015 13:46:26 +0200 Message-ID: From: Mike Hearn To: Riccardo Spagni 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 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.

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.

=C2=A0
My current thinking with Electrum (that ThomasV and I have bounced<= br> 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 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
--001a113ec6acc578d4051b24da12--