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
|
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 D069C8A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 05:37:27 +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 B951186
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 05:37:26 +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=T82MYKH+jBDgq4qIzKco7LVwouLlKMuPIlOhAfmBW28=;
b=nkrtucxRCiGeoqprpkB2NtdhwwgUUB2TTB0KiOqsb4QTlnVV0fRPOzOVn/qwtsxFJU09g3Lthj4tIEeQ6ZgZ0yYcUmF4KleZNBelsIRGZkFRaXByS8kJ22wQttOivovs2tqUObB6pV4Zh81Ra78p89oMZ26YJqbbCtjJ1a+Dub0=;
Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:40190)
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 1cklKj-0000eB-D6
for bitcoin-dev@lists.linuxfoundation.org;
Mon, 06 Mar 2017 06:37:24 +0100
Received: from c-50-165-129-212.hsd1.in.comcast.net ([50.165.129.212]:55818
helo=[10.0.0.7]) 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 1cklKi-000DqS-Rg
for bitcoin-dev@lists.linuxfoundation.org;
Mon, 06 Mar 2017 06:37:21 +0100
Message-ID: <1488778644.2205.1.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Mon, 06 Mar 2017 00:37:24 -0500
In-Reply-To: <201703040827.33798.luke@dashjr.org>
References: <201703040827.33798.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 05:37:28 -0000
I'm not sure if a BIP is the right thing in that case, given that the
provided functionality is not special to Bitcoin and can be used in
other contexts as well.
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...
Apart from that, my feeling is that it could be simplified. Is
longpolling useful? And is the historical rate thing really necessary
for typical applications?
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.
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.
Tim
On Sat, 2017-03-04 at 08:27 +0000, Luke Dashjr via bitcoin-dev wrote:
> Investigating what it would take to add fiat currency information to
> Bitcoin
> Knots, I noticed Electrum currently has many implementations, one for
> each
> exchange rate provider, due to lack of a common format for such data.
>
> Therefore, I put together an initial draft of a BIP that could
> standardise
> this so wallets (or other software) and exchange rate providers can
> simply
> interoperate without a lot of overhead reimplementing the same thing
> many
> ways.
>
> One thing I am unsure about, is that currently this draft requires
> using XBT
> (as BTC) for Bitcoin amounts. It would seem nicer to use satoshis,
> but those
> don't really have a pseudo-ISO currency code to fit in nicely...
>
> Current draft here:
> https://github.com/luke-jr/bips/blob/bip-xchgrate/bip-xchgrate.me
> diawiki
>
> Thoughts? Anything critical missing? Ways to make the interface
> better?
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
