public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
	Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
Subject: Re: [bitcoin-dev] Currency/exchange rate information API
Date: Mon, 6 Mar 2017 07:09:39 +0000	[thread overview]
Message-ID: <201703060709.40311.luke@dashjr.org> (raw)
In-Reply-To: <1488778644.2205.1.camel@mmci.uni-saarland.de>

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.

> Apart from that, my feeling is that it could be simplified. Is 
> longpolling useful?

I would think so, at least for Bitcoin since rates can change significantly in 
a short period of time (or can they anymore? I haven't really watched lately.)

> And is the historical rate thing really necessary for typical applications?

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.

> 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?

> Also, pushing may be more appropriate for "current" rates than polling.
> Then no polling interval is necessary. On the other hand, this adds
> complexity in other places, e.g., state.

Pushing is what longpolling does.

Luke


  reply	other threads:[~2017-03-06  7:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-04  8:27 [bitcoin-dev] Currency/exchange rate information API Luke Dashjr
2017-03-04 15:18 ` アルム カールヨハン
2017-03-06  5:37 ` Tim Ruffing
2017-03-06  7:09   ` Luke Dashjr [this message]
2017-03-06  8:14     ` Jonas Schnelli
2017-03-06 21:54     ` Tim Ruffing
2017-03-06 22:02       ` Tim Ruffing
2017-03-06 22:21         ` Luke Dashjr
2017-03-06 22:14       ` Luke Dashjr
2017-03-06 22:30         ` Tim Ruffing
2017-03-06 22:38           ` Tim Ruffing
2017-03-06 23:14   ` Andreas Schildbach
2017-03-07  9:29 ` Marcel Jamin
2017-03-13 18:10   ` Andrew LeCody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201703060709.40311.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tim.ruffing@mmci.uni-saarland.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox