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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
|
Return-Path: <dev@jonasschnelli.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9CDE1259
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 08:14:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from server3 (server3.include7.ch [144.76.194.38])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C1FC1D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Mar 2017 08:14:28 +0000 (UTC)
Received: by server3 (Postfix, from userid 115)
id A5E4C2E600C8; Mon, 6 Mar 2017 09:14:27 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, FSL_HELO_NON_FQDN_1
autolearn=ham version=3.3.1
Received: from [10.0.1.31] (cable-static-140-182.teleport.ch [87.102.140.182])
by server3 (Postfix) with ESMTPSA id 114B52D0034C;
Mon, 6 Mar 2017 09:14:27 +0100 (CET)
From: Jonas Schnelli <dev@jonasschnelli.ch>
Content-Type: multipart/signed;
boundary="Apple-Mail=_F4CA6240-6E9C-469E-AA73-22342FB78DEB";
protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Mon, 6 Mar 2017 09:14:23 +0100
References: <201703040827.33798.luke@dashjr.org>
<1488778644.2205.1.camel@mmci.uni-saarland.de>
<201703060709.40311.luke@dashjr.org>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <201703060709.40311.luke@dashjr.org>
Message-Id: <A9659D64-96A3-45B4-90FA-15F35BAE9676@jonasschnelli.ch>
X-Mailer: Apple Mail (2.3259)
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 08:14:29 -0000
--Apple-Mail=_F4CA6240-6E9C-469E-AA73-22342FB78DEB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
I like the BIP. It can reduce workload during implementation on both =
sides of the API and it allows to show the user more data without =
implementing tons of proprietary APIs.
It=E2=80=99s not directly Bitcoin specific (example: BIP32 is also not =
Bitcoin specific), but I think a BIP is the right way for this.
>=20
>> Apart from that, my feeling is that it could be simplified. Is
>> longpolling useful?
>=20
> 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.)
Long polling is a simple push concept that works on most type of network =
configurations (NAT, proxy, etc.).
The only concern I see here is that an public API will quickly fill up =
the maximum allowed httpd connections.
But it=E2=80=99s solvable.
>=20
>> And is the historical rate thing really necessary for typical =
applications?
>=20
> 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.
I=E2=80=99m also not sure how useful historical datapoint are. I don=E2=80=
=99t think the use case where someone wants to restore from a seed and =
get all exchange rates during the time of the payment is something users =
are looking for.
However, It=E2=80=99s optional.
>=20
>> 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.
>=20
> How is the current draft insufficient for this?
>=20
>> 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.
>=20
> Pushing is what longpolling does.
Agree with Luke. A =E2=80=9Ereal=E2=80=9C push (though I=E2=80=99d say =
long-polling is the real push, AFAIK it=E2=80=99s also the technique =
behind Apple=E2=80=99s iOS push channel) would require a complex server =
setup that complicates many things like load-balancer, mem-caching, etc.
</jonas>
--Apple-Mail=_F4CA6240-6E9C-469E-AA73-22342FB78DEB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEyhopCNzi8TB0xizeHrd2uwPHki0FAli9Gl8ACgkQHrd2uwPH
ki0i3A/7BfE2bRJXjK7UUFV4AeQKyKMs1ymBZ9NioFb71ipEeX2C45B1zz0vE1qv
/0oV6T8xVDPfEYYUDUD4bZDd7CgrAi0tJUDkEAvkLHP2goIuQ+LGbuNEVAwguWOq
jtaGPil+pFPedfb67PKyTk6DQ7ZqGirZqbY8fpxf52zOddZ9ncbtwI0h8+74gaVE
epDlOvc9JsR4BexmCiooZAPVug4rPS8zOf1E1Sksf/JTInrdA9xYosoV4FQlZgZh
CXegvGpAmplZRoUqH4P8NhGYdFwF5+Pfkq846+ZRlF+FNN9CJ6ApUI5B0QP6Qta/
iUa5EpJWmANiJj5jzwxng3zcF802iUkPSx1mwTM1xokaxv7EBtGp+eku1I3Vppzr
vUXydOcP8RGZQTT8JXpr+BImQqWdRVDRZUrZw4Kn2nPzoDdUgdeSfA5y4fPWx4Zj
8K74bzHU6fLwElUYPfk2xuEDQ4qrifPP8ZdL5CHzLgMWth0ilv8A/WFXGk8V1Qu1
6G0jdlaZJr5ziDQnICASLRt236gmeSAHu1KVUMIHjQ44IpcDUmk01bX+dK6Rpwd2
IOXJgDsUYIbM1agzslssykzhqxC0y7gwtLe+z8swlqN8yXjtFokITz8FbEEHRd0k
yLXBFVhvO04kIFZUYAaqBHYlXHxUFQg0eiek7TyK414wd7oqq1o=
=V6o5
-----END PGP SIGNATURE-----
--Apple-Mail=_F4CA6240-6E9C-469E-AA73-22342FB78DEB--
|
