Message-ID: <1488837256.2134.1.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Luke Dashjr <luke@dashjr.org>, 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"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] Currency/exchange rate information API
Precedence: list

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