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 a
> 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
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.
___
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
On Mon, 2017-03-06 at 22:14 +, 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, th
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 (min
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 th
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 clie
On Mon, 2017-03-06 at 07:09 +, 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
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
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 someth
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 th
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
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
14 matches
Mail list logo
