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 BE98DA5E for ; Mon, 6 Mar 2017 07:10:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 5F6CC8E for ; Mon, 6 Mar 2017 07:10:22 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 29E2938ABEB4; Mon, 6 Mar 2017 07:09:41 +0000 (UTC) X-Hashcash: 1:25:170306:bitcoin-dev@lists.linuxfoundation.org::Ep5jCNLWeq5hXFQc:cGE5/ X-Hashcash: 1:25:170306:tim.ruffing@mmci.uni-saarland.de::+4aMmNJ5O7staJ2n:ceu0= From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Tim Ruffing Date: Mon, 6 Mar 2017 07:09:39 +0000 User-Agent: KMail/1.13.7 (Linux/4.4.45-gentoo; KDE/4.14.28; x86_64; ; ) References: <201703040827.33798.luke@dashjr.org> <1488778644.2205.1.camel@mmci.uni-saarland.de> In-Reply-To: <1488778644.2205.1.camel@mmci.uni-saarland.de> X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201703060709.40311.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 07:10:22 -0000 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. > Apart from that, my feeling is that it could be simplified. Is > longpolling useful? 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.) > And is the historical rate thing really necessary for typical applications? 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. > 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? > 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. Pushing is what longpolling does. Luke