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>
Subject: Re: [bitcoin-dev] Currency/exchange rate information API
Precedence: list


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