Inaba (OP)
Legendary
Offline
Activity: 1260
Merit: 1000
|
|
May 22, 2012, 08:10:41 PM |
|
SMF won't format tables properly (surprise!) ... I will reformat it if it's too confusing. Here is a first draft proposal for a JSON API standards for Bitcoin Pools: Generic keys: JSON Key | Description | version | Version of the API in use |
Pool keys: JSON Key | Description | round_duration | Duration of the current round | round_shares | Number of shares submitted in current round | hashrate | Total hashrate of the pool |
User keys: JSON Key | Description | round_shares |
Total shares submitted by user for current round Estimated reward the user will receive on next payout in BTC | hashrate | Total hashrate of the user | last_activity |
Last miner activity in GMT | btc_balance | Current available balance for the user in BTC | btc_unconfirmed | Unconfirmed/unavailable balance for the user in BTC | btc_paid | Total amount paid to the user in BTC | last_payout_amount | Last amount paid to the user in BTC | last_payout_time | Time user was paid in GTM |
|
If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.
|
|
|
flower1024
Legendary
Offline
Activity: 1428
Merit: 1000
|
|
May 22, 2012, 08:21:49 PM |
|
what do you think about adding a field about the payout-method used? and i would love to see standardized uris too.
|
|
|
|
Inaba (OP)
Legendary
Offline
Activity: 1260
Merit: 1000
|
|
May 22, 2012, 08:26:41 PM |
|
Uris?
What do you mean by payout method exactly?
|
If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.
|
|
|
Clipse
|
|
May 22, 2012, 08:31:03 PM |
|
I really like these suggestions, I will soon be adding proper json and may aswell make use of the suggested options once "finalised" in this thread I assume.
|
...In the land of the stale, the man with one share is king... >> ClipseWe pay miners at 130% PPS | Signup here : Bonus PPS Pool (Please read OP to understand the current process)
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
May 22, 2012, 08:31:17 PM |
|
I assume he mean reward method (PPS, SMPSS, DGM, etc)? Including things like fee %, payout tx fees, merge mining would make it possible to keep something like this actually up to date. https://en.bitcoin.it/wiki/Comparison_of_mining_pools
|
|
|
|
flower1024
Legendary
Offline
Activity: 1428
Merit: 1000
|
|
May 22, 2012, 08:32:50 PM |
|
I assume he mean reward method (PPS, SMPSS, DGM, etc)?
yes, thanks would be easy to develop an app to monitor multiple pools then
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
May 22, 2012, 08:42:21 PM |
|
|
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
|
May 22, 2012, 09:31:57 PM |
|
p_shep approves this message
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
May 22, 2012, 09:36:56 PM |
|
A standardised api for pool stat history would be nice.
|
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
|
May 22, 2012, 10:00:19 PM |
|
"rewardalgo" may have to go per worker. Some pools you can select what worker does what... EMC & Ozcoin allows this. Perhaps this field can be used to list available algorithms. I quite liked my idea for a round/block structure. Allows for block history to use the same structure repeated. And everyone likes re-using code
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
May 22, 2012, 10:40:58 PM |
|
For a pool history API, for pools like deepbit where pool history will be thousands of blocks there might need to be a protocol limiting the number of blocks to 100 recent blocks, and then have a slightly different url for blocks further back. I'd like to see a JSON or other API present a pool history table like this: Block height/hash | Block timestamp | Round duration | Total submitted shares | Current difficulty | <Payout method specific field>
Data should be standardised too. 'Round duration' should be in seconds and the timestamp should be in the standard unix %Y-%m-%d %H:%M:%S. Current difficulty is important to include. It's easily available elsewhere, but this being a block history API it's a pain for a miner to search the difficulty history for each and every block. The field for <Payout method specific field> can be used for any results specific to a payout method. I had SMPPS in mind (a field for buffer), but I'm sure other payout methods would find a use for it.
|
|
|
|
Graet
VIP
Legendary
Offline
Activity: 980
Merit: 1001
|
|
May 22, 2012, 11:54:35 PM |
|
A standardised api for pool stat history would be nice.
standardisation is slowly creeping into bitcoin - which is good Ozcoin shows per worker hashrate as well as total, this was on user request - I think it needs to be included for people that use API to monitor rigs up/down. e.g. our desktop widget will not work without separated worker hashrates. At Ozcoin payout method is by user not worker (this might change in the future) Currently we are doing some heavy development on the backend and site - whilst a great idea a standardised API is not high on our priorities.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
May 23, 2012, 12:58:06 AM |
|
Data should be standardised too. Agree 'Round duration' should be in seconds Agreed (as in integer unformated # of seconds) and the timestamp should be in the standard unix %Y-%m-%d %H:%M:%S. In my opinon formatting has no place in an API that is a presentation layer task. Unix/Posix time is better since it is an integer and every language has tools to format it. For example as of writing Unix/Posix time is 1337632227 Still the larger point is that data format should be part of the spec. Current difficulty is important to include. Agreed.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
May 23, 2012, 01:14:43 AM |
|
and the timestamp should be in the standard unix %Y-%m-%d %H:%M:%S. In my opinon formatting has no place in an API that is a presentation layer task. Unix/Posix time is better since it is an integer and every language has tools to format it. For example as of writing Unix/Posix time is 1337632227 I would definitely prefer it to be unixtime for my own purposes, although I get a seamless conversion when I need it. However I proposed the above format because I thought that the average miner might not be able to use unixtime so easily. Still the larger point is that data format should be part of the spec.
Yes, that's the main thing. Anyone wanting to - for example - create a website to list miner api results or pool history will need all data standardised if she or he's going to list all pools equally easily. Btc-poolwatch.com was a constant job for koo (the owner/writer) since adding an api meant writing a new code to interpret the api, and any api changes broke the service.
|
|
|
|
Inaba (OP)
Legendary
Offline
Activity: 1260
Merit: 1000
|
|
May 23, 2012, 02:19:24 AM |
|
I think UNIX timestamp is the way to go. If a pool wants to add extra "human" time, then that's easily done. I think the standard as UNIX time is the right choice. Really, all time should be given in unix time stamps and extra fields added for human time if desired.
So my proposal for the standard:
All time displays presented as UNIX epoc. This will also do away with the need for timezoning questions/issues. All hash rates presented as hashes per second. All BTC's presented as Satoshis
|
If you're searching these lines for a point, you've probably missed it. There was never anything there in the first place.
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
|
May 23, 2012, 03:29:11 AM |
|
I think UNIX timestamp is the way to go. If a pool wants to add extra "human" time, then that's easily done. I think the standard as UNIX time is the right choice. Really, all time should be given in unix time stamps and extra fields added for human time if desired.
So my proposal for the standard:
All time displays presented as UNIX epoc. This will also do away with the need for timezoning questions/issues. All hash rates presented as hashes per second. All BTC's presented as Satoshis
Sounds good to me
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
May 23, 2012, 06:14:07 AM |
|
I think UNIX timestamp is the way to go. If a pool wants to add extra "human" time, then that's easily done. I think the standard as UNIX time is the right choice. Really, all time should be given in unix time stamps and extra fields added for human time if desired.
So my proposal for the standard:
All time displays presented as UNIX epoc. This will also do away with the need for timezoning questions/issues. All hash rates presented as hashes per second. All BTC's presented as Satoshis
Good proposal Inaba, and thanks to Inaba and P_Shep for getting this going. Can I add: - All fields to be integer (no char, no added commas etc, no double)
- Apis should all be the same format (preferably JSON).
- The number and order of fields in each api should be standardised.
- The api call should be standardised -
eg the following could call worker stats:
poolname.com/api/workername - Any api call that includes historical data should include an option for selection of amount of data. Eg if X is the last X rounds of historical data:[\li]
poolname.com/api/username/history?X
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
May 23, 2012, 07:34:55 AM |
|
One more thing - a pool history request shouldn't require a key (Ahem maxbtc, I'm looking at you )
|
|
|
|
slush
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
May 23, 2012, 09:48:44 AM |
|
Estimated reward the user will receive on next payout in BTC What if user (or few of his workers) are PPS? null value? Last miner activity in GMT UTC, not GMT! GMT has summer/winter time, which is always pain in applications. btc_balance | Current available balance for the user in BTC | btc_unconfirmed | Unconfirmed/unavailable balance for the user in BTC | btc_paid | Total amount paid to the user in BTC |
Let's rename it to balance, balance_unconfirmed, balance_paid. Otherwise we'll rename those fields for NMC? :-)
|
|
|
|
slush
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
May 23, 2012, 09:54:21 AM |
|
I'm not against this initiative if it will need just to rename columns and URLs in my own API (which was - as Tycho mentioned - the first API, and there's no general issue with that). That means - I don't see any reason to change token management etc.
Also, we should define some standard on ask rate from clients. I'm caching API calls for 30 seconds, but still I see some stupid users fetching JSON data every second. That's not only annoying, that also needs much more transfers than mining itself of those users (especially when they're CPU miners).
|
|
|
|
|