Bitcoin Forum
December 10, 2016, 03:03:37 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: Pool API Standard  (Read 3488 times)
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
May 23, 2012, 12:50:56 PM
 #21

Quote
The number and order of fields in each api should be standardised.

JSON makes both of these immaterial.  No need to have them ordered and it would impose an undue burden on the pool side.  The number of fields would also be immaterial, just discard the fields you don't want to use.  That way it allows a pool to provide additional information beyond the standard.

Quote
The api call should be standardised -
eg the following could call worker stats:

This is nice in theory, but I'm not sure it can work in practice, given all the different systems out there. In your example it would create a supremely difficult problem for me to provide since I'm not setup to handle calls in that fashion.  If we are going to standardize in this fashion, HTTP GET is probably the best solution, since it should be universally compatible.

Quote
What if user (or few of his workers) are PPS? null value?

Zero would be the logical amount, since it would be an accurate value.

Quote
UTC, not GMT! GMT has summer/winter time, which is always pain in applications.

Yes!  Sorry I meant UTC not GMT!

Quote
Let's rename it to balance, balance_unconfirmed, balance_paid. Otherwise we'll rename those fields for NMC?

I did that specifically so you could add nmc_balance, nmc_unconfirmed, and nmc_paid.  Although I suppose we could make them a sub array of BTC: or NMC: (or whatever other currency) and then just use balance, unconfirmed, paid.

Quote
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).

Yes, I absolutely agree.  I see the same things.


If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
1481382217
Hero Member
*
Offline Offline

Posts: 1481382217

View Profile Personal Message (Offline)

Ignore
1481382217
Reply with quote  #2

1481382217
Report to moderator
1481382217
Hero Member
*
Offline Offline

Posts: 1481382217

View Profile Personal Message (Offline)

Ignore
1481382217
Reply with quote  #2

1481382217
Report to moderator
1481382217
Hero Member
*
Offline Offline

Posts: 1481382217

View Profile Personal Message (Offline)

Ignore
1481382217
Reply with quote  #2

1481382217
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481382217
Hero Member
*
Offline Offline

Posts: 1481382217

View Profile Personal Message (Offline)

Ignore
1481382217
Reply with quote  #2

1481382217
Report to moderator
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
May 23, 2012, 04:20:56 PM
 #22

Have you guys seen Luke's BIP?

https://en.bitcoin.it/wiki/BIP_PoolAPI

Some interesting ideas on displaying balances. Very generic, so can be used for any currency.

Things like the API call and call rate I should think can be totally up to the pool. I don't think there's any need to standardise these.
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
May 23, 2012, 05:08:13 PM
 #23

I did that specifically so you could add nmc_balance, nmc_unconfirmed, and nmc_paid.  Although I suppose we could make them a sub array of BTC: or NMC: (or whatever other currency) and then just use balance, unconfirmed, paid.

Having currency name in variable doesn't look smart. Then I prefer - separate calls completely (and have an api for every currency) or have separate section for every currency, like ...'balance': {'BTC': {'unconfirmed': 0, 'confirmed': 0, 'paid': 0}, 'NMC': {...}} ...

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
May 23, 2012, 05:10:57 PM
 #24

Have you guys seen Luke's BIP?

Yes and I see it overcomplicated, especially that "collab" construction. Better to have more APIs than one huge monster, isn't it? I even think that current API should be split into more calls like account state (balances, address, etc) and worker states.

P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
May 23, 2012, 05:43:10 PM
 #25

Yes and I see it overcomplicated, especially that "collab" construction.
Yes it is rather. I didn't intend such complexity.

Better to have more APIs than one huge monster, isn't it? I even think that current API should be split into more calls like account state (balances, address, etc) and worker states.

That was my original suggestion Smiley

but having structure:
balance =
{
  type = BTC
  confirmed = xxx
  unconfimed = xxx
  ...etc...
}

As an array inside the main structure also works for me.

user =
{
    ...
    balances = {array of balance}
    ...
}
kinlo
Sr. Member
****
Offline Offline

Activity: 263


Pool operator of Triplemining.com


View Profile
May 23, 2012, 10:18:16 PM
 #26

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.
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
May 24, 2012, 01:12:32 AM
 #27

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.


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
May 24, 2012, 06:13:43 AM
 #28

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).

Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
May 24, 2012, 12:40:42 PM
 #29

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

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
kinlo
Sr. Member
****
Offline Offline

Activity: 263


Pool operator of Triplemining.com


View Profile
May 24, 2012, 01:58:08 PM
 #30

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...
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
May 24, 2012, 03:27:43 PM
 #31

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.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
May 24, 2012, 04:21:51 PM
 #32

CSV for block data sounds reasonable to me.
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
May 25, 2012, 04:41:20 PM
 #33

shares =
{
    "submitted" = <shares submitted>,
    "stale" = <shares deemed stale by pool>,
    "invalid" = <shares deemed invalid by pool>
}

block =
{
    "currency" = <BTC, NMC, etc...>
    "id" = <block ID>,
    "duration" = <seconds>,
    "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" = <BTC, NameCoin, Ix, iO, etc.>,
    "confirmed" = <confirmed reward (>=120 valid blocks) in Satoshis>,
    "unconfirmed" = <unconfirmed reward (<120 valid blocks) in Satoshis>,
    "estimate" = <estimated reward for current round>,
    "last_pay" = <value of last payout in Satoshis>,
    "last_pay_time" = <time of last payout in unix time>,
    "total_pay" = <total value of payout in Satoshis>,
    "threshold" = <min confirmed reward before auto payout in Satoshis. 0 for no auto payment>
}

worker =
{
    "id" = <unique identifier>,
    "name" = <name / description>,
    "hashrate" = <worker hashrate>,
    "last_activity" = <last submitted share time in unix time>,
    "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" = <reward algorithm identifier>,
    "fee" = <fee multiplier (1% = 0.01)>
}

user =
{
    "API" = 1.0.0
    "pool_MOTD" = <whatever the pool wants to tell us>,
    "pool_hashrate" = <entire pool current hashrate>,
    "pool_users" = <number of active users on the pool>,
    "pool_workers" = <number of active workers on the pool>,
    "current_round" = {<array of active 'block' (as defined above)>},
    "user_hashrate" = <current hashrate in H/s for all workers - implementation pool dependent>,
    "last_activity" = <last submitted share time in unix time>,
    "balances" = {<array of 'balance' (as defined above)>},
    "workers" = {<array of 'worker' (as defined above)>}
}

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.
JinTu
Full Member
***
Offline Offline

Activity: 132


Hopping down the bunny trail


View Profile
June 01, 2012, 10:26:05 PM
 #34

block =
{
    "currency" = <BTC, NMC, etc...>
    "id" = <block ID>,
    "duration" = <seconds>,
    "shares_total" = <total shares submitted so far for round>,
    "shares_submitted" = <shares submitted by user (all workers)>
}

balance =
{
    "currency" = <BTC, NameCoin, Ix, iO, etc.>,
    "confirmed" = <confirmed reward (>=120 valid blocks) in Satoshis>,
    "unconfirmed" = <unconfirmed reward (<120 valid blocks) in Satoshis>,
    "estimate" = <estimated reward for current round>,
    "last_pay" = <value of last payout in Satoshis>,
    "last_pay_time" = <time of last payout in unix time>,
    "total_pay" = <total value of payout in Satoshis>,
    "threshold" = <min confirmed reward before auto payout in Satoshis. 0 for no auto payment>
}

worker =
{
    "id" = <unique identifier>,
    "name" = <name / description>,
    "hash_rate" = <worker hash rate>,
    "last_activity" = <last submitted share time in unix time>,
    "shares" = <shares submitted by worker in current round>,
    "shares_total" = <total shares submitted by worker (may be resetable by pool?)>,
    "reward_algo" = <reward algorithm identifier>,
    "fee" = <fee multiplier (1% = 0.01)>
}

user =
{
    "API" = 1.0.0
    "pool_MOTD" = <whatever the pool wants to tell us>,
    "pool_hash_rate" = <entire pool current hash rate>,
    "pool_users" = <number of active users on the pool>,
    "pool_workers" = <number of active workers on the pool>,
    "current_round" = {<array of active 'block' (as defined above)>},
    "hash_rate" = <current hash rate in H/s for all workers - implementation pool dependent>,
    "last_activity" = <last submitted share time in unix time>,
    "balances" = {<array of 'balance' (as defined above)>},
    "workers" = {<array of 'worker' (as defined above)>}
}

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.

Please donate if this was helpful: 14CLqCNphUJ54ro2PtqQWJDmW3Eic1WmUd
Cacti templates for pool, GPU and CGMINER monitoring.
GPU monitoring with SNMP
P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
June 06, 2012, 08:22:25 PM
 #35

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://bitcointalk.org/index.php?topic=83027.msg921816#msg921816
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
June 06, 2012, 08:26:26 PM
 #36

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://bitcointalk.org/index.php?topic=83027.msg921816#msg921816
Did you update the wiki page with the specification?

P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
June 06, 2012, 08:47:08 PM
 #37

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://bitcointalk.org/index.php?topic=83027.msg921816#msg921816
Did you update the wiki page with the specification?

I should probably do that...
Tittiez
Hero Member
*****
Offline Offline

Activity: 686



View Profile
June 06, 2012, 09:35:59 PM
 #38

Reminds me of

P_Shep
Legendary
*
Offline Offline

Activity: 924


View Profile WWW
June 06, 2012, 10:08:22 PM
 #39

Reminds me of



Certainly does Cheesy

but no standard exists for this yet... all have been proprietary.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
June 07, 2012, 02:18:12 AM
 #40

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!