📅 Original date posted:2017-03-06
📝 Original message: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
Tim Ruffing [ARCHIVE] /
npub1cm…dwkls
2023-06-07 17:56:54
in reply to nevent1q…ym05
Author Public Key
npub1cmt6gqyfw3sdngkq0wadtpe3kmgyyeld6ad0g2h5tar3kpzcrmpqddwklsPublished at
2023-06-07 17:56:54Event JSON
{
"id": "f4c97882f23dbe66a22373f42d2828f6e392ddfd53049694a93648aa1c3f2290",
"pubkey": "c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2",
"created_at": 1686160614,
"kind": 1,
"tags": [
[
"e",
"7d71aaf3aaa91e1454a25f4f9688ba685bebb747e49a8ad14b817de1aa470d06",
"",
"root"
],
[
"e",
"8a43cfb9dbd6c42f60253d5003903deb16d70f8b3f1d65450ba55cd476bd60dc",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-03-06\n📝 Original message:On Mon, 2017-03-06 at 22:14 +0000, Luke Dashjr wrote:\n\u003e It would be a privacy leak to request only the specific timestamps,\n\u003e but I \n\u003e suppose many wallets lack even basic privacy to begin with.\n\u003e \n\u003e To address the bounds issue, I have specified that when from/to don't\n\u003e have an \n\u003e exact record, that the previous/next (respectively) is provided.\n\u003e \n\u003e Hopefully this addresses both concerns?\nYes, that solves it. You're right with the privacy concern however.\n\n\u003e \n\u003e \u003e In the current draft the client or the server cannot specify\n\u003e \u003e granularity. If the clients only wants one value per day but for an\n\u003e \u003e entire year, then it has to perform many requests or download and\n\u003e \u003e process a very large response.\n\u003e \n\u003e That's what the \"timedelta\" field solves, no?\n\u003e If you want one value per day, you'd put 86400.\nOh sure, I had overlooked that.\n\n\u003e \n\u003e \u003e Also, I think it's okay that the type field allows for arbitrary\n\u003e user-\n\u003e \u003e defined values, but it should also have some precisely defined\n\u003e values\n\u003e \u003e (e.g. the mentioned low/high/open/close/typical).\n\u003e \u003e For example, it's not clear currently what \"low\" means for a\n\u003e timestamp\n\u003e \u003e (as opposed to a time span). Is it the low of the entire day or the\n\u003e low\n\u003e \u003e since the previous record or something different?\n\u003e \n\u003e Is it not sufficient for the server to specify this in the\n\u003e description of the \n\u003e given currency-pair feed?\nThat works but a standardized way of indicating that piece of\ninformation to the client is useful. Then the client can display a\n\"connection status\" to the user, e.g., an \"possible out-of-date\"\nwarning like the warning sign in the Qt GUI when Bitcoin Core is\ncatching up the network.\n\n\nTim",
"sig": "1ff7508f2c807672bb8f89e0d715467c9a182ca5160d47ec246df87bea3dfc0a7b3a1406405d350d8ad93bd86f997aa95062473712a2aa4dd64323f0ea77921a"
}