Pool API Standard

[Luke-Jr]

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.

[1714813769]

1714813769

[P_Shep]

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]

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

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.

[kano]

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]

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

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.