Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 11279955 for ; Mon, 6 Mar 2017 22:31:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from hera.mpi-klsb.mpg.de (infao0809.mpi-klsb.mpg.de [139.19.1.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 699F9147 for ; Mon, 6 Mar 2017 22:30:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mmci.uni-saarland.de; s=mail200803; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=oIcnrJa6VOZN/GJPTmpDx9okIxYqn1v4qDYWicVj91g=; b=V0eAhz+tdwTg7RhApk8xldpC2OqjNq9jcOT1PGQIbKWC/br8fVefBurlOXxBfaP2oo4tc69SAxlq5Dvzem2RkmD4/82A7lPC2cn5jF0LANnrBZZXi+lGRwRpLBnYOQ9bXSuPiGtsdQ8xjBO8uNSPjRmSx0DmZa5sC2/sr150MDc=; Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:58142) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) id 1cl19b-0004Lo-G7; Mon, 06 Mar 2017 23:30:57 +0100 Received: from [192.31.0.5] (port=58280 helo=[192.168.25.175]) by sam.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) id 1cl19b-000M5z-0z; Mon, 06 Mar 2017 23:30:55 +0100 Message-ID: <1488839459.2134.5.camel@mmci.uni-saarland.de> From: Tim Ruffing To: Luke Dashjr , bitcoin-dev@lists.linuxfoundation.org Date: Mon, 06 Mar 2017 17:30:59 -0500 In-Reply-To: <201703062214.47660.luke@dashjr.org> References: <201703040827.33798.luke@dashjr.org> <201703060709.40311.luke@dashjr.org> <1488837256.2134.1.camel@mmci.uni-saarland.de> <201703062214.47660.luke@dashjr.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MPI-Local-Sender: true X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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] Currency/exchange rate information API X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 22:31:00 -0000 On Mon, 2017-03-06 at 22:14 +0000, Luke Dashjr wrote: > It would be a privacy leak to request only the specific timestamps, > but I  > suppose many wallets lack even basic privacy to begin with. > > To address the bounds issue, I have specified that when from/to don't > have an  > exact record, that the previous/next (respectively) is provided. > > Hopefully this addresses both concerns? Yes, that solves it. You're right with the privacy concern however. > > > In the current draft the client or the server cannot specify > > granularity. If the clients only wants one value per day but for an > > entire year, then it has to perform many requests or download and > > process a very large response. > > That's what the "timedelta" field solves, no? > If you want one value per day, you'd put 86400. Oh sure, I had overlooked that. > > > Also, I think it's okay that the type field allows for arbitrary > user- > > defined values, but it should also have some precisely defined > values > > (e.g. the mentioned low/high/open/close/typical). > > For example, it's not clear currently what "low" means for a > timestamp > > (as opposed to a time span). Is it the low of the entire day or the > low > > since the previous record or something different? > > Is it not sufficient for the server to specify this in the > description of the  > given currency-pair feed? That works but a standardized way of indicating that piece of information to the client is useful. Then the client can display a "connection status" to the user, e.g., an "possible out-of-date" warning like the warning sign in the Qt GUI when Bitcoin Core is catching up the network. Tim