No Branch/Tag Specified
chat
custom_themes
danger
dev
duke
importviewkey
master
no_mining_until_synced
old_duke
onryo
recurring
0.4.0
0.4.1
0.4.2
0.4.3
0.5.0
0.5.1
0.5.10
0.5.11
0.5.3
0.5.4
0.5.5
0.6.0
0.6.1
0.6.10
0.6.11
0.6.2
0.6.3
0.6.4
0.6.5
0.6.6
0.6.7
0.6.8
0.6.9
0.7.0
0.7.1
0.7.2
0.7.3
0.7.4
0.7.5
0.7.6
0.7.7
0.7.9
1.4.2
v0.1.5
v0.1.6
v0.1.7
v0.1.8
v0.1.9
v0.2.0
v0.2.1
v0.2.2
v0.2.3
v0.2.4
v0.2.5
v0.2.6
v0.2.7
v0.2.8
v0.2.9
v0.3.0
v0.3.1
v0.3.2
v0.5.2
v0.5.6
v0.5.7
v0.5.8
v0.5.9
v0.7.5
v0.7.6
v0.7.7
v0.7.8
v0.8.0
v0.8.1
v0.8.2
v0.8.3
v0.9.0
v0.9.1
v0.9.2
v1.0.0
v1.1.0
v1.2.0
v1.3.0
v1.3.1
v1.4.0
v1.4.1
v1.4.2
Labels
bounty up to 500 HUSH 2001-5000 bounty
bounty between 2001 and 5000 HUSH 501-2000 bounty
bounty between 501 and 2000 HUSH arm
something doesn't work on arm beginners
for new developers bug
may or may not be a bug build
problems building documentation
not enough information feature
new feature high priority
high priority i2p
related to i2p low priority
low priority medium priority
medium priority question
something is not clear release
release label or issue related to it tor
related to tor translation
translation update windows
related to windows wontfix
this won't be fixed
Apply labels
Clear labels
0-500 bounty
bounty up to 500 HUSH 2001-5000 bounty
bounty between 2001 and 5000 HUSH 501-2000 bounty
bounty between 501 and 2000 HUSH arm
something doesn't work on arm beginners
for new developers bug
may or may not be a bug build
problems building documentation
not enough information feature
new feature high priority
high priority i2p
related to i2p low priority
low priority medium priority
medium priority question
something is not clear release
release label or issue related to it tor
related to tor translation
translation update windows
related to windows wontfix
this won't be fixed
No Label
0-500 bounty
2001-5000 bounty
501-2000 bounty
arm
beginners
bug
build
documentation
feature
high priority
i2p
low priority
medium priority
question
release
tor
translation
windows
wontfix
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Seems users may like to see different market data in the GUI. HACs are not fully supported to show any data, but basic support for DRGX was recently added in
3a160c1136
Connecting to CoinGecko's API is a source of meta leakage. Users should be required to opt in to fetch this data, rather than making API calls by default. I think this was already done via #106, but needs additional testing based on last comments. From what I checked briefly, the checkbox in GUI is disabled by default currently.
This tab does not contain much data and looks dismal. I changed from 2 to 8 decimal places, otherwise, with small numbers, it was showing 0. There are some other quirks with what data is displayed based on local currency setting, which seems to default to BTC.
Some ideas to improve this tab, which CoinGecko has calls for:
Line chart for historical price, market cap, and volume
Ticker data from exchanges (last price, volume, depth, etc)
An option to refresh or control refresh interval
Any other ideas?
I think there should be a vote or majority agreement on whether additional data is added here or if we remove the tab entirely since it's not very useful in its current state.
@fekt I like your ideas to add more data to the tab
@fekt one small idea I have for less metadata leakage is to always request both hush+dragonx data (the coingecko api key is
ids
which looks like it will accept multiple values). That means that instead of coingecko knowing you are using a Hush or DragonX wallet, they only know you are using one of them, but not exactly which. It's not much but it's something.@duke It looks like their API calls for this data require a single ID for the coin.
https://www.coingecko.com/api/documentation
Their
prices
endpoint is a little different and accepts multiple ids to obfuscate what we're after a little more, but doesn't return everything for more market-specific data. In recent commit, I copied the existing API call and modified for DRGX, but they could be merged with specifying multiple IDs and parse what we want.I am using their
market_chart
endpoint to grab price, market cap, and volume history. I have it generating a chart now only for the price like this. The x-axis doesn't make sense and is only a count currently because a unix timestamp is returned and QT seems to be converting it to a double like1.709485303342
. I need to figure that out or just hide the x-axis entirely.The placement of this data can be moved around and there will probably be a dropdown or something to switch between different charts.
@fekt thanks for looking into the API. The chart looks really good! Very nice to see the market tab getting some love
I figured out the issue with the the timestamps being converted to a double. It's a bug in QT that affects QJson only and think it was only fixed in QT 6, but not sure: https://bugreports.qt.io/browse/QTBUG-28560
https://forum.qt.io/topic/66153/qjsondocument-loses-accuracy-on-long-long-int64-data
A conversion worked so I should have a commit soon. Marketcap data for DRGX doesn't seem to be available yet so I need to do some more testing with HUSH instead.
I have a dropdown to switch between different charts. The API seems to get rate limited fairly quick though if switching between charts very fast. Seems like somewhere around only a dozen calls/minute.
Some of the data like volume may not be represented the best because it's returning hourly data instead of a 24 hour volume. This is based on the number of days specified below so I may let users change that eventually. For now it's better than nothing and nice to see a quick representation without having to check exchanges or aggregators.
1 day from current time = 5 minute interval data
2 - 90 days from current time = hourly data
above 90 days from current time = daily data
@fekt great to hear. As for dealing with rate limits, one idea I have is to cache data returned from the API on disk, with a timestamp. If a user switches between charts very quickly, the code would look for the data on disk first and if the timestamp is new enough, use that, else request from the API.
Initial commit is in
dev
branch now. No caching yet. Has new requirement to installlibqt5charts5-dev
. Probably good to test DRGX version while mining to see if it breaks anything.