1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
Return-Path: <tim.ruffing@mmci.uni-saarland.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EC114BE4
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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
<tim.ruffing@mmci.uni-saarland.de>)
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
<tim.ruffing@mmci.uni-saarland.de>)
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 <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"
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
