Great!

to get it working in openwrt, i had to manually specify the location of the lib.

LIBCURL_CFLAGS=-L/path/to/lib LIBCURL_LIBS=-lcurl

No?

I don't know, I think success should return success, and failure should return failure.
In this case, it terminates a successful conversion with failure.

Also, I changed it in my code to || last night... still working fine for me

See 5 posts back

I'm bug chasing, so I edited the code to use the return value.

CSV for block data sounds reasonable to me.

Thing is, the BFL uses hex2bin the other way round: the string is longer than p. The BFL returns a string of nonces, hex2bin is used to extract these nonces. There's no null terminator on each nonce, so hex2bin is returning an error, even though everything is fine.

Should the return value not be || rather than &&?

Is it possible to request data through the API on an address, but without all the tx's?
That's quite a lot of data there I don't need.

Yes it is rather. I didn't intend such complexity.


That was my original suggestion

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

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.

Sounds good to me

"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

p_shep approves this message

Good to see my pro-active attempt gained some interest (Sorry if it was spammy!)

OK, how about something like this:
(We'll leave workers and previous blocks for later versions.)

block =
{
    "duration" = <seconds>,
    "shares_total" = <total shares submitted so far for round>,
    "shares_submitted" = <shares submitted by user (all workers)>,
    "reward" = <estimated reward for current round or actual reward for previous rounds in Satoshis>
}

user =
{
    "API" = 1.0.0
    "current_round" = {<active block (as defined above)>},
    "hash_rate" = <current hash rate in MH/s for all workers - implementation pool dependent>,
    "last_activity" = <last submitted share time in unix time>,
    "confirmed_reward" = <confirmed reward (>=120 valid blocks) in Satoshis>,
    "unconfirmed_reward" = <unconfirmed reward (<120 valid blocks) in Satoshis>,
    "total_payout" = <total amount of BTC payed out to user (could be reset by user? - up to pool)>,
    "last_payout_value" = <value of last payout in Satoshis>,
    "last_payout_time" = <time of last payout in unix time>,
    "send_threshold" = <min confirmed reward before auto payout in Satoshis. 0 for no auto payment>,
    "workers" = {<TBC>}
}

Some elements take from Slush here.

So to retrieve BTC info, the URL would be something like:
http://<pool>/api.php?key=<API key>&currency=btc
or
http://<pool>/json/btc/<API key>

Then namecoin stats would be retrieved separately.
No real need (that I can think of) for URLs to be common/deterministic, down to the pool operator I should say.
At my end, I'd just use the entire URL in Anubis and deal with the data, not try and form the url.

 

My garage is getting quite warm.
One of my BFLs is up to 60C.

No desire to do this at all from anyone?

 

My suggested info:

API version
Current round duration
Current round shares total
Current round shares submitted
Current round estimated reward BTC
Current hash rate
Last activity
Confirmed BTC
Unconfirmed BTC
Total payout BTC
Last payout BTC
Last payout time
Payout threshold

I made them myself, but you can buy some from cablez:
https://bitcointalk.org/index.php?topic=74397.0

Yep, everything. No inefficient, messy, bulky wall-wart PSUs here