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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
