Bitcoin Forum
May 25, 2017, 02:15:22 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Pool API Standard  (Read 3773 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2170



View Profile
June 07, 2012, 02:37:57 AM
 #41

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.

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

Posts: 1495721722

View Profile Personal Message (Offline)

Ignore
1495721722
Reply with quote  #2

1495721722
Report to moderator
P_Shep
Legendary
*
Offline Offline

Activity: 994


View Profile WWW
June 07, 2012, 02:44:32 AM
 #42

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
*
Offline Offline

Activity: 2170



View Profile
June 07, 2012, 03:22:29 AM
 #43

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
Legendary
*
Online Online

Activity: 2100


Linux since 1997 RedHat 4


View Profile
June 18, 2012, 12:56:54 PM
 #44

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


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 Smiley

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2170



View Profile
June 18, 2012, 01:34:04 PM
 #45

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 Smiley
1e12 is valid JSON.

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!