From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9CDE1259 for ; 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 ; 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 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 , Bitcoin Protocol Discussion In-Reply-To: <201703060709.40311.luke@dashjr.org> Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. --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--