* [bitcoin-dev] Currency/exchange rate information API
@ 2017-03-04 8:27 Luke Dashjr
2017-03-04 15:18 ` アルム カールヨハン
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Luke Dashjr @ 2017-03-04 8:27 UTC (permalink / raw)
To: bitcoin-dev
Cc: support, contacto, info, index, btcparalelo, support, support,
support, team, kontakt, contact, support, info, support
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.mediawiki
Thoughts? Anything critical missing? Ways to make the interface better?
Luke
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-04 8:27 [bitcoin-dev] Currency/exchange rate information API Luke Dashjr @ 2017-03-04 15:18 ` アルム カールヨハン 2017-03-06 5:37 ` Tim Ruffing 2017-03-07 9:29 ` Marcel Jamin 2 siblings, 0 replies; 14+ messages in thread From: アルム カールヨハン @ 2017-03-04 15:18 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion I am surprised nothing like this exists already, so am all for the idea. Maybe I am misunderstanding, but I'm not sure you want to have thousand separators and other locale stuff in there. All currencies including USD are often shown in Swedish using space or dot as thousand separator and comma as decimal separator, e.g. "1.234,56 USD" or "1 234,56 USD". I.e. this is something that the locale of the user's environment defines, not something the server should have opinions about. It is also not ideal to propose a given format based on the user's locale, as some users have preferences for this (I personally use US locale for numbers, and a US person who is visiting Sweden wouldn't want this to suddenly change). -Kalle. On Sat, Mar 4, 2017 at 12:27 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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.mediawiki > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-04 8:27 [bitcoin-dev] Currency/exchange rate information API Luke Dashjr 2017-03-04 15:18 ` アルム カールヨハン @ 2017-03-06 5:37 ` Tim Ruffing 2017-03-06 7:09 ` Luke Dashjr 2017-03-06 23:14 ` Andreas Schildbach 2017-03-07 9:29 ` Marcel Jamin 2 siblings, 2 replies; 14+ messages in thread From: Tim Ruffing @ 2017-03-06 5:37 UTC (permalink / raw) To: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 5:37 ` Tim Ruffing @ 2017-03-06 7:09 ` Luke Dashjr 2017-03-06 8:14 ` Jonas Schnelli 2017-03-06 21:54 ` Tim Ruffing 2017-03-06 23:14 ` Andreas Schildbach 1 sibling, 2 replies; 14+ messages in thread From: Luke Dashjr @ 2017-03-06 7:09 UTC (permalink / raw) To: bitcoin-dev, Tim Ruffing 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 7:09 ` Luke Dashjr @ 2017-03-06 8:14 ` Jonas Schnelli 2017-03-06 21:54 ` Tim Ruffing 1 sibling, 0 replies; 14+ messages in thread From: Jonas Schnelli @ 2017-03-06 8:14 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2481 bytes --] 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’s not directly Bitcoin specific (example: BIP32 is also not Bitcoin specific), but I think a BIP is the right way for this. > >> 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.) 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’s solvable. > >> 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. I’m also not sure how useful historical datapoint are. I don’t 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’s optional. > >> 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. Agree with Luke. A „real“ push (though I’d say long-polling is the real push, AFAIK it’s also the technique behind Apple’s iOS push channel) would require a complex server setup that complicates many things like load-balancer, mem-caching, etc. </jonas> [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 7:09 ` Luke Dashjr 2017-03-06 8:14 ` Jonas Schnelli @ 2017-03-06 21:54 ` Tim Ruffing 2017-03-06 22:02 ` Tim Ruffing 2017-03-06 22:14 ` Luke Dashjr 1 sibling, 2 replies; 14+ messages in thread From: Tim Ruffing @ 2017-03-06 21:54 UTC (permalink / raw) To: Luke Dashjr, bitcoin-dev On Mon, 2017-03-06 at 07:09 +0000, Luke Dashjr wrote: > 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. Sure, HTTPS is the way to go. But I think that should be required or at least noted in the BIP, because people could miss easily, e.g., "I don't need TLS, all the data is public anyway." > 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. > Having the rate at the time of payment is indeed very useful, yes. However that requires just a single value per payment, and there is no query that tells the server "give me the value closest to timestamp t" or similar. Of course the client can download and keep a large part of history and extract the information on its own but I can imagine that not every clients wants to do that, and also the client does not know in advance the bounds (from, to) that it must query. > > 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? > In the current draft the client or the server cannot specify granularity. If the clients only wants one value per day but for an entire year, then it has to perform many requests or download and process a very large response. Also, I think it's okay that the type field allows for arbitrary user- defined values, but it should also have some precisely defined values (e.g. the mentioned low/high/open/close/typical). For example, it's not clear currently what "low" means for a timestamp (as opposed to a time span). Is it the low of the entire day or the low since the previous record or something different? One has to be careful not to add too much complexity though. As soon as one moves away from timestamps to something like hours or days, all kind of issues with timezone, daylight saving time etc. appear. Maybe a simple way to let the client ask "give me one value for every interval of 3600 seconds" or similar. > Pushing is what longpolling does. > That makes a lot of sense, yes. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 21:54 ` Tim Ruffing @ 2017-03-06 22:02 ` Tim Ruffing 2017-03-06 22:21 ` Luke Dashjr 2017-03-06 22:14 ` Luke Dashjr 1 sibling, 1 reply; 14+ messages in thread From: Tim Ruffing @ 2017-03-06 22:02 UTC (permalink / raw) To: Tim Ruffing, Bitcoin Protocol Discussion On Mon, 2017-03-06 at 16:54 -0500, Tim Ruffing via bitcoin-dev wrote: > > > Pushing is what longpolling does. > > > > That makes a lot of sense, yes. > Forgot one thing: For longpolling, maybe we would like to have the possibility to request some periodic message from the server. Otherwise clients cannot distinguish between the situations 1. "value is still in the requested bounds (minrate, maxrate)" and 2. "connection has dropped". So the user may take a wrong decision because he assumed that the value is still in bounds holds but actually the server has died. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 22:02 ` Tim Ruffing @ 2017-03-06 22:21 ` Luke Dashjr 0 siblings, 0 replies; 14+ messages in thread From: Luke Dashjr @ 2017-03-06 22:21 UTC (permalink / raw) To: bitcoin-dev, Tim Ruffing On Monday, March 06, 2017 10:02:53 PM Tim Ruffing via bitcoin-dev wrote: > For longpolling, maybe we would like to have the possibility to request > some periodic message from the server. Otherwise clients cannot > distinguish between the situations 1. "value is still in the requested > bounds (minrate, maxrate)" and 2. "connection has dropped". So the user > may take a wrong decision because he assumed that the value is still > in bounds holds but actually the server has died. That's the job of TCP. Do you think we need to explicitly specify a keepalive configuration? Seems like that would vary based on client or network. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 21:54 ` Tim Ruffing 2017-03-06 22:02 ` Tim Ruffing @ 2017-03-06 22:14 ` Luke Dashjr 2017-03-06 22:30 ` Tim Ruffing 1 sibling, 1 reply; 14+ messages in thread From: Luke Dashjr @ 2017-03-06 22:14 UTC (permalink / raw) To: Tim Ruffing; +Cc: bitcoin-dev On Monday, March 06, 2017 9:54:16 PM Tim Ruffing wrote: > Having the rate at the time of payment is indeed very useful, yes. > However that requires just a single value per payment, and there is no > query that tells the server "give me the value closest to timestamp t" > or similar. > Of course the client can download and keep a large part of history and > extract the information on its own but I can imagine that not every > clients wants to do that, and also the client does not know in advance > the bounds (from, to) that it must query. It would be a privacy leak to request only the specific timestamps, but I suppose many wallets lack even basic privacy to begin with. To address the bounds issue, I have specified that when from/to don't have an exact record, that the previous/next (respectively) is provided. Hopefully this addresses both concerns? > In the current draft the client or the server cannot specify > granularity. If the clients only wants one value per day but for an > entire year, then it has to perform many requests or download and > process a very large response. That's what the "timedelta" field solves, no? If you want one value per day, you'd put 86400. > Also, I think it's okay that the type field allows for arbitrary user- > defined values, but it should also have some precisely defined values > (e.g. the mentioned low/high/open/close/typical). > For example, it's not clear currently what "low" means for a timestamp > (as opposed to a time span). Is it the low of the entire day or the low > since the previous record or something different? Is it not sufficient for the server to specify this in the description of the given currency-pair feed? Luke ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 22:14 ` Luke Dashjr @ 2017-03-06 22:30 ` Tim Ruffing 2017-03-06 22:38 ` Tim Ruffing 0 siblings, 1 reply; 14+ messages in thread From: Tim Ruffing @ 2017-03-06 22:30 UTC (permalink / raw) To: Luke Dashjr, bitcoin-dev On Mon, 2017-03-06 at 22:14 +0000, Luke Dashjr wrote: > It would be a privacy leak to request only the specific timestamps, > but I > suppose many wallets lack even basic privacy to begin with. > > To address the bounds issue, I have specified that when from/to don't > have an > exact record, that the previous/next (respectively) is provided. > > Hopefully this addresses both concerns? Yes, that solves it. You're right with the privacy concern however. > > > In the current draft the client or the server cannot specify > > granularity. If the clients only wants one value per day but for an > > entire year, then it has to perform many requests or download and > > process a very large response. > > That's what the "timedelta" field solves, no? > If you want one value per day, you'd put 86400. Oh sure, I had overlooked that. > > > Also, I think it's okay that the type field allows for arbitrary > user- > > defined values, but it should also have some precisely defined > values > > (e.g. the mentioned low/high/open/close/typical). > > For example, it's not clear currently what "low" means for a > timestamp > > (as opposed to a time span). Is it the low of the entire day or the > low > > since the previous record or something different? > > Is it not sufficient for the server to specify this in the > description of the > given currency-pair feed? That works but a standardized way of indicating that piece of information to the client is useful. Then the client can display a "connection status" to the user, e.g., an "possible out-of-date" warning like the warning sign in the Qt GUI when Bitcoin Core is catching up the network. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 22:30 ` Tim Ruffing @ 2017-03-06 22:38 ` Tim Ruffing 0 siblings, 0 replies; 14+ messages in thread From: Tim Ruffing @ 2017-03-06 22:38 UTC (permalink / raw) To: Tim Ruffing, Bitcoin Protocol Discussion On Mon, 2017-03-06 at 17:30 -0500, Tim Ruffing via bitcoin-dev wrote: > > That works but a standardized way of indicating that piece of > information to the client is useful. Then the client can display a > "connection status" to the user, e.g., an "possible out-of-date" > warning like the warning sign in the Qt GUI when Bitcoin Core is > catching up the network. Wait, forget this reply, I mixed up the two issues of keepalive and definition of low, high etc... -.- 1. Keepalive for longpolling: As I said, this can be useful for an out-of-date warning. I don't know if this is better solved with TCP keepalive or on the higher layer. 2. Definition of low, high: My feeling is that there is nothing wrong with providing exact definitions in the BIP, i.e.., giving up the flexibility does not too hurt much. However all of this is a minor issue after all. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-06 5:37 ` Tim Ruffing 2017-03-06 7:09 ` Luke Dashjr @ 2017-03-06 23:14 ` Andreas Schildbach 1 sibling, 0 replies; 14+ messages in thread From: Andreas Schildbach @ 2017-03-06 23:14 UTC (permalink / raw) To: bitcoin-dev On 03/06/2017 06:37 AM, Tim Ruffing via bitcoin-dev wrote: > And is the historical rate thing really necessary > for typical applications? Yes, it is. Basically all incoming transactions are historical, as your wallet is likely not online when it happens. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-04 8:27 [bitcoin-dev] Currency/exchange rate information API Luke Dashjr 2017-03-04 15:18 ` アルム カールヨハン 2017-03-06 5:37 ` Tim Ruffing @ 2017-03-07 9:29 ` Marcel Jamin 2017-03-13 18:10 ` Andrew LeCody 2 siblings, 1 reply; 14+ messages in thread From: Marcel Jamin @ 2017-03-07 9:29 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion > Why are multiple results separated by a line-feed rather than using a JSON Array? > * Clients ought to cache historical data, and using a line-feed format allows them to simply append to a cache file. > * Parsing JSON typically requires the entire data parsed together as a single memory object. Using simple lines to separate results, however, allows parsing a single result at a time. > What if long descriptions require line and paragraph breaks? > * Clients should word-wrap long lines, and JSON escapes newlines as "\n" which can be used doubly ("\n\n") for paragraph breaks. I'd file this under premature optimization at the cost of interoperability. If you use JSON, then please use it properly. I'd also say it's the job of the parser to offer a way of doing that, e.g. in .NET you can easily achieve that with Newtonsoft's JSON parser: http://stackoverflow.com/questions/20374083/deserialize-json-array-stream-one-item-at-a-time. On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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.mediawiki > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [bitcoin-dev] Currency/exchange rate information API 2017-03-07 9:29 ` Marcel Jamin @ 2017-03-13 18:10 ` Andrew LeCody 0 siblings, 0 replies; 14+ messages in thread From: Andrew LeCody @ 2017-03-13 18:10 UTC (permalink / raw) To: Marcel Jamin, Bitcoin Protocol Discussion, Luke Dashjr [-- Attachment #1: Type: text/plain, Size: 2783 bytes --] This formatting of JSON isn't unheard of though, it's typically called JSON Streaming[1]. As long as exchanges implementing the API actually follow the BIP and keep one JSON object per line, it shouldn't be a problem to decode. 1. https://en.wikipedia.org/wiki/JSON_Streaming On Tue, Mar 7, 2017 at 8:07 AM Marcel Jamin via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > > Why are multiple results separated by a line-feed rather than using a > JSON Array? > > * Clients ought to cache historical data, and using a line-feed format > allows them to simply append to a cache file. > > * Parsing JSON typically requires the entire data parsed together as a > single memory object. Using simple lines to separate results, however, > allows parsing a single result at a time. > > What if long descriptions require line and paragraph breaks? > > * Clients should word-wrap long lines, and JSON escapes newlines as "\n" > which can be used doubly ("\n\n") for paragraph breaks. > > I'd file this under premature optimization at the cost of > interoperability. If you use JSON, then please use it properly. > > I'd also say it's the job of the parser to offer a way of doing that, > e.g. in .NET you can easily achieve that with Newtonsoft's JSON > parser: > http://stackoverflow.com/questions/20374083/deserialize-json-array-stream-one-item-at-a-time > . > > On 4 March 2017 at 09:27, Luke Dashjr via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> 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.mediawiki > > > > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4983 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-03-13 18:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-04 8:27 [bitcoin-dev] Currency/exchange rate information API Luke Dashjr 2017-03-04 15:18 ` アルム カールヨハン 2017-03-06 5:37 ` Tim Ruffing 2017-03-06 7:09 ` Luke Dashjr 2017-03-06 8:14 ` Jonas Schnelli 2017-03-06 21:54 ` Tim Ruffing 2017-03-06 22:02 ` Tim Ruffing 2017-03-06 22:21 ` Luke Dashjr 2017-03-06 22:14 ` Luke Dashjr 2017-03-06 22:30 ` Tim Ruffing 2017-03-06 22:38 ` Tim Ruffing 2017-03-06 23:14 ` Andreas Schildbach 2017-03-07 9:29 ` Marcel Jamin 2017-03-13 18:10 ` Andrew LeCody
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox