Published on: 2017-03-13T18:10:57+00:00
The Bitcoin developer community is exploring the inclusion of fiat currency information in Bitcoin Knots. Currently, there is a lack of a common format for this data, resulting in multiple implementations in Electrum. To address this issue, Luke Dashjr has drafted a Bitcoin Improvement Proposal (BIP) that aims to standardize the process. The draft suggests using XBT (as BTC) for Bitcoin amounts, although it may not be the ideal option as satoshis do not have a pseudo-ISO currency code. The format of JSON used in the API is called JSON Streaming, and as long as exchanges adhere to the BIP and maintain one JSON object per line, decoding will not be an issue. Clients should word-wrap long lines and use JSON escapes for newlines. In a discussion on the bitcoin-dev mailing list, Tim Ruffing questioned the necessity of historical rate information for typical applications. However, it was argued that this feature is indeed necessary as all incoming transactions are historical, and wallets are often offline when these transactions occur. This highlights the importance of understanding the technical details and requirements of cryptocurrency applications.Furthermore, Ruffing suggested the need for a standardized way of indicating connection status to clients, including an "out-of-date" warning. However, he later corrected himself, realizing that he had mixed up two separate issues: keepalive for longpolling and the definition of low and high. Regarding keepalive for longpolling, Ruffing expressed uncertainty about whether it's better solved with TCP keepalive or on a higher layer. For defining low and high, he felt that providing exact definitions in the BIP would not be detrimental since it's a minor issue overall.Luke Dashjr addressed privacy concerns related to requesting specific timestamps, suggesting that when from/to don't have an exact record, the previous/next (respectively) should be provided. He also mentioned the potential usefulness of a standardized way of indicating the meaning of user-defined values in the type field.Ruffing brought up the need for a periodic message system in longpolling, as without it, clients cannot distinguish between a situation where the value is still within requested bounds and when the connection has dropped. Another participant in the discussion pointed out that this was actually the job of TCP and questioned the necessity of an explicit keepalive configuration.In terms of displaying historical transactions, Ruffing suggested that the exchange rate at the time of payment would be useful but there is currently no query to retrieve the value closest to a specific timestamp. Ruffing specified that when from/to don't have an exact record, the previous/next (respectively) should be provided. However, the client or server cannot specify granularity in the current draft, leading to potential issues with timezone and daylight saving time. Ruffing also proposed defining precise values for the type field and suggesting that the server should specify the meaning of "low" in the description of the currency-pair feed.The Bitcoin Improvement Proposal (BIP) aims to reduce workload during implementation and allow for more data to be shown to users without implementing proprietary APIs. Longpolling is seen as useful for Bitcoin due to the significant fluctuations in rates over a short period. However, there are concerns about public API connections reaching their maximum limit. The historical rate feature is deemed necessary for displaying historical transactions, but its usefulness is questionable. The ability to choose the time scale of data and clearly define the type field is considered important. Pushing may be more suitable for "current" rates than polling, but it adds complexity in other areas such as state. Authentication of servers and the use of HTTPS to prevent manipulation of exchange rates were discussed as important factors. There is a need for a query that retrieves the closest value to a specific timestamp, allowing the market rate at the time of payment to be displayed. However, it was mentioned that not all clients want to download and process a large amount of historical data. The current draft is insufficient for specifying granularity, raising issues with timezone and daylight saving time. Luke Dashjr proposed the BIP to standardize fiat currency information in Bitcoin Knots, aiming to simplify interoperability between exchange rate providers and wallets or other software. However, there are still concerns about missing critical components and improving the interface.
Updated on: 2023-08-01T19:42:24.341628+00:00