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 EC114BE4 for ; Mon, 6 Mar 2017 21:54:18 +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 0AD7CA1 for ; Mon, 6 Mar 2017 21:54:17 +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=xXWInkameGXDm6+oMCq8wp0/xVueNKGE2NBcLku9Gz4=; b=egHGpwADHe7TTgVwaIa0eV2YUOrjR8cfjJOgYCFAzVh/7PX2ZPWtORcAjfKlBU9U3wZR6w/2TWs9GCkkfjTE4HqpTkJn1sWsYhaSFrak7MxHyNEVUb6Y55dPPZdXERv5bwUK4irOd59cficFN+Im0xF35dnGLdw6SjRTQz2+8UE=; Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:56968) by hera.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) id 1cl0a5-0006nn-5V; Mon, 06 Mar 2017 22:54:15 +0100 Received: from [192.31.0.5] (port=57572 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 1cl0a4-0003nM-JV; Mon, 06 Mar 2017 22:54:12 +0100 Message-ID: <1488837256.2134.1.camel@mmci.uni-saarland.de> From: Tim Ruffing To: Luke Dashjr , bitcoin-dev@lists.linuxfoundation.org Date: Mon, 06 Mar 2017 16:54:16 -0500 In-Reply-To: <201703060709.40311.luke@dashjr.org> References: <201703040827.33798.luke@dashjr.org> <1488778644.2205.1.camel@mmci.uni-saarland.de> <201703060709.40311.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 21:54:19 -0000 On Mon, 2017-03-06 at 07:09 +0000, Luke Dashjr wrote: > On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev > wrote: > > But ignoring this, the server should be authenticated at a > > minimum. Otherwise manipulating exchange rates seems to be a nice > > way for the attacker on the wire to make money... > > HTTPS would be used for that. It's not something that needs to be at > a higher  > layer. Sure, HTTPS is the way to go. But I think that should be required or at least noted in the BIP, because people could miss easily, e.g., "I don't need TLS, all the data is public anyway." > When displaying historical transactions, it doesn't really make sense > to use  > the current market rate, but rather the market rate at the time the > payment  > was made. While wallets might simply cache it with the transaction, > it would  > be perhaps nicer if it could be automatically restored for seed-only  > recoveries. In any case, if a service/wallet doesn't want to > provide/use  > historical information, it can simply not implement that part. > Having the rate at the time of payment is indeed very useful, yes. However that requires just a single value per payment, and there is no query that tells the server "give me the value closest to timestamp t" or similar. Of course the client can download and keep a large part of history and extract the information on its own but I can imagine that not every clients wants to do that, and also the client does not know in advance the bounds (from, to) that it must query. > > If yes, the client should be allowed to decide on which time scale > the > > data should be. (tick, min, hour, day, ...) That goes together with > > clearly defining the type field (something like low, high, open, > close, > > but without flexibility). Think of a candle-stick chart basically. > > How is the current draft insufficient for this? > 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. 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? One has to be careful not to add too much complexity though. As soon as one moves away from timestamps to something like hours or days, all kind of issues with timezone, daylight saving time etc. appear. Maybe a simple way to let the client ask "give me one value for every interval of 3600 seconds" or similar. > Pushing is what longpolling does. > That makes a lot of sense, yes. Tim