📅 Original date posted:2017-03-06
📝 Original message: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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:56:52
in reply to nevent1q…w68k
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:56:52Event JSON
{
"id": "5aff60a1b33e34c0581b7893d7f6b9d49125dd68c0e37bfb3fd536a1b4cb1e99",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686160612,
"kind": 1,
"tags": [
[
"e",
"7d71aaf3aaa91e1454a25f4f9688ba685bebb747e49a8ad14b817de1aa470d06",
"",
"root"
],
[
"e",
"b33883e20e0b6013151e06f860bf7bbfeb2e6d1919e2ede0fadcbd80922971ab",
"",
"reply"
],
[
"p",
"c6d7a400897460d9a2c07bbad58731b6d04267edd75af42af45f471b04581ec2"
]
],
"content": "📅 Original date posted:2017-03-06\n📝 Original message:On Monday, March 06, 2017 5:37:24 AM Tim Ruffing via bitcoin-dev wrote:\n\u003e But ignoring this, the server should be authenticated at a\n\u003e minimum. Otherwise manipulating exchange rates seems to be a nice\n\u003e way for the attacker on the wire to make money...\n\nHTTPS would be used for that. It's not something that needs to be at a higher \nlayer.\n\n\u003e Apart from that, my feeling is that it could be simplified. Is \n\u003e longpolling useful?\n\nI would think so, at least for Bitcoin since rates can change significantly in \na short period of time (or can they anymore? I haven't really watched lately.)\n\n\u003e And is the historical rate thing really necessary for typical applications?\n\nWhen displaying historical transactions, it doesn't really make sense to use \nthe current market rate, but rather the market rate at the time the payment \nwas made. While wallets might simply cache it with the transaction, it would \nbe perhaps nicer if it could be automatically restored for seed-only \nrecoveries. In any case, if a service/wallet doesn't want to provide/use \nhistorical information, it can simply not implement that part.\n\n\u003e If yes, the client should be allowed to decide on which time scale the\n\u003e data should be. (tick, min, hour, day, ...) That goes together with\n\u003e clearly defining the type field (something like low, high, open, close,\n\u003e but without flexibility). Think of a candle-stick chart basically.\n\nHow is the current draft insufficient for this?\n\n\u003e Also, pushing may be more appropriate for \"current\" rates than polling.\n\u003e Then no polling interval is necessary. On the other hand, this adds\n\u003e complexity in other places, e.g., state.\n\nPushing is what longpolling does.\n\nLuke",
"sig": "e4fc74acef35f3da354a3d1883010c65c137cb4daa3409228767b03265534eee39725b641d14d8000afd69b07382fa89887909c7ff7a73d7b2be95a72e649b16"
}