Pool API Standard | Bitcointalksearch.org

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: kano on June 18, 2012, 07:56:54 AM

Elapsed should 'almost' never be used unless there is an actual specific reason for it
How long has a block been around is a good example of when it shouldn't be used - that should be a timestamp

It is a timestamp...

Quote from: kano on June 18, 2012, 07:56:54 AM

Also - I like float MH/s not H/s since that is what everyone thinks in nowadays and yeah in the future it will be even bigger
1 TH/s is 1000000000000 H/s - that number is just way too big already ...
1000000.000000 MH/s is 'nicer' IMO

1e12 is valid JSON.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

A suggestion (or 2) ... welcome to be ignored

Elapsed should 'almost' never be used unless there is an actual specific reason for it
How long has a block been around is a good example of when it shouldn't be used - that should be a timestamp
(and saying it makes it easier for recipient XYZ simply means you got it wrong)
Timestamp things and return those integer sec timestamps or float timeval if higher accuracy is required
Also, as I did in the cgminer API, include a 'now' with any data set that has timestamps
(the cgminer API STATUS header always has 'When' for that reason ... once I realised it was missing)
This resolves any issue of ever creating correct elapsed values if anyone wants to display them

Also - I like float MH/s not H/s since that is what everyone thinks in nowadays and yeah in the future it will be even bigger
1 TH/s is 1000000000000 H/s - that number is just way too big already ...
1000000.000000 MH/s is 'nicer' IMO

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: P_Shep on June 06, 2012, 03:47:08 PM

Quote from: Luke-Jr on June 06, 2012, 03:26:26 PM

Quote from: P_Shep on June 06, 2012, 03:22:25 PM

I (we!) missed a very important metric up there, invalid/stale shares. So I've tweaked it a bit.
Getting rather complicated now though! Didn't intend for it to go this way, but at least it's pretty complete!

https://bitcointalksearch.org/topic/m.921816

Did you update the wiki page with the specification?

I should probably do that...

Please try to edit the existing specification draft, rather than replace it entirely. I combined the two, but please double-check that I didn't miss anything. Note that JSON does not have Float or Time types, just Number.

I also made a quick pass over it to try to make it sensible for Bitcoin address mining.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: Luke-Jr on June 06, 2012, 09:37:57 PM

Quote from: -ck on June 06, 2012, 09:18:12 PM

Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.

That's why everything is optional.

Word.

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: -ck on June 06, 2012, 09:18:12 PM

Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.

That's why everything is optional.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: Tittiez on June 06, 2012, 04:35:59 PM

Reminds me of

Certainly does Cheesy

but no standard exists for this yet... all have been proprietary.

Tittiez

hero member

Activity: 686

Merit: 500

Reminds me of

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

Quote from: Luke-Jr on June 06, 2012, 03:26:26 PM

Quote from: P_Shep on June 06, 2012, 03:22:25 PM

I (we!) missed a very important metric up there, invalid/stale shares. So I've tweaked it a bit.
Getting rather complicated now though! Didn't intend for it to go this way, but at least it's pretty complete!

https://bitcointalksearch.org/topic/m.921816

Did you update the wiki page with the specification?

I should probably do that...

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: P_Shep on June 06, 2012, 03:22:25 PM

I (we!) missed a very important metric up there, invalid/stale shares. So I've tweaked it a bit.
Getting rather complicated now though! Didn't intend for it to go this way, but at least it's pretty complete!

https://bitcointalksearch.org/topic/m.921816

Did you update the wiki page with the specification?

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

I (we!) missed a very important metric up there, invalid/stale shares. So I've tweaked it a bit.
Getting rather complicated now though! Didn't intend for it to go this way, but at least it's pretty complete!

https://bitcointalksearch.org/topic/m.921816

JinTu

full member

Activity: 133

Merit: 100

Quote from: P_Shep on May 25, 2012, 11:41:20 AM

block =
{
   "currency" =
"id" = ,
   "duration" = ,
   "shares_total" = ,
   "shares_submitted" =
}

balance =
{
   "currency" = ,
   "confirmed" = =120 valid blocks) in Satoshis>,
   "unconfirmed" = ,
   "estimate" = ,
   "last_pay" = ,
   "last_pay_time" = ,
   "total_pay" = ,
   "threshold" =
}

worker =
{
   "id" = ,
   "name" = ,
   "hash_rate" = ,
   "last_activity" = ,
   "shares" = ,
   "shares_total" = ,
   "reward_algo" = ,
   "fee" =
}

user =
{
   "API" = 1.0.0
   "pool_MOTD" = ,
   "pool_hash_rate" = ,
   "pool_users" = ,
   "pool_workers" = ,
   "current_round" = {},
   "hash_rate" = ,
   "last_activity" = ,
   "balances" = {},
   "workers" = {}
}

Where:
All time displays presented as UNIX epoc.
All hash rates presented as hashes per second.
'Satoshis' is the smallest value for the associated currency. i.e. For USD this would be 1c.

+1

I would love to see this implemented.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

shares =
{
   "submitted" = ,
   "stale" = ,
   "invalid" =
}

block =
{
   "currency" =
   "id" = ,
   "duration" = ,
   "shares_round" = {<'shares' for entire pool for the round (as defined above)>},
   "shares_user" = {<'shares' for all workers of the user for the round (as defined above)>}
}

balance =
{
   "currency" = ,
   "confirmed" = =120 valid blocks) in Satoshis>,
   "unconfirmed" = ,
   "estimate" = ,
   "last_pay" = ,
   "last_pay_time" = ,
   "total_pay" = ,
   "threshold" =
}

worker =
{
   "id" = ,
   "name" = ,
   "hashrate" = ,
   "last_activity" = ,
   "shares_round" = {<'shares' for current round (as defined above)>},
   "shares_reset" = {<'shares' since last user reset (as defined above)>},
   "shares_total" = {<'shares' for all time (as defined above)>},
   "reward_algo" = ,
   "fee" =
}

user =
{
   "API" = 1.0.0
   "pool_MOTD" = ,
   "pool_hashrate" = ,
   "pool_users" = ,
   "pool_workers" = ,
   "current_round" = {},
   "user_hashrate" = ,
   "last_activity" = ,
   "balances" = {},
   "workers" = {}
}

Where:
All time displays presented as UNIX epoc.
All hash rates presented as hashes per second.
'Satoshis' is the smallest value for the associated currency. i.e. For USD this would be 1c.

P_Shep

legendary

Activity: 1795

Merit: 1208

This is not OK.

CSV for block data sounds reasonable to me.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: kinlo on May 24, 2012, 08:58:08 AM

Quote from: Inaba on May 24, 2012, 07:40:42 AM

I would agree, historical data is better provided as CSV. The API should be for relevant current information that changes frequently.

Json has overhead compared to csv. However, csv is not extensible, and the information isn't that big, so the overhead doesn't matter that much. I would prefer json over csv. A simple (online) convertor can still be made for those that prefer to work with csv instead of json. If it is a standard, such a convertor would be easy to write for all pools at once...

csv is only considered for historical data that would be easier to manipulate as a dataframe and needs updating only when a block is found.

kinlo

sr. member

Activity: 263

Merit: 250

Pool operator of Triplemining.com

Quote from: Inaba on May 24, 2012, 07:40:42 AM

I would agree, historical data is better provided as CSV. The API should be for relevant current information that changes frequently.

Json has overhead compared to csv. However, csv is not extensible, and the information isn't that big, so the overhead doesn't matter that much. I would prefer json over csv. A simple (online) convertor can still be made for those that prefer to work with csv instead of json. If it is a standard, such a convertor would be easy to write for all pools at once...

Inaba

legendary

Activity: 1260

Merit: 1000

I would agree, historical data is better provided as CSV. The API should be for relevant current information that changes frequently.

slush

legendary

Activity: 1386

Merit: 1097

Quote from: organofcorti on May 23, 2012, 08:12:32 PM

As Inaba said the number and order of fields in JSON is immaterial

To be exact, this is true only for keys of an array. Lists (and history of blocks should be definitely stored in list) are ordered. But I see your point. Actually I'm for defining JSON API as an standard, because it's usually easier to handle in applications, and provide alternate CSV API with block history only (from pool side it's just an iteration over original JSON and columns with expected order).

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

I think pool round history is probably better as a .csv than in JSON. It's much easier to use a dataframe when working with aggregates of data. Also much easier for the poor sods using excel to get a feel for their pool's recent history.

As Inaba said the number and order of fields in JSON is immaterial, but that's not the case in a dataframe, especially if you want to perform exactly the same operations on different dataframes from different pools.

kinlo

sr. member

Activity: 263

Merit: 250

Pool operator of Triplemining.com

I'd suggest providing 2 API's/url's

One API that requires an API key, showing all the information related to that user.

A second api/url containing the pool data, global data that is not related to a specific user, so it can be retrieved by any user without an API key. Examples are global hashrate, found blocks history and such.

Seperating them would make it easy for people to get full data on any pool without an account...

Perhaps a third url can be made like /standard_api_locations.txt where the location of both those url's are placed, so the user doesn't have to enter anything except the main pool url.

Topic: Pool API Standard (Read 4462 times)