Try this: <?php $json = '{"e":5.01}'; var_dump(json_decode($json)); ?>
Output: object(stdClass)#1 (1) { ["e"]=> float(5.01) }
|
|
|
upload it to youtube. it has an option to set the default image.
|
|
|
1) Bitcoin's mainstream acceptance is not that important. An idea would be quite useless if it has to convince every single person in the world in order to be efficient. I don't want to rely on other people's smartness and awareness, because it would be hopeless.
E-o
|
|
|
This week I should have an exchange running. I'm in talks now with a company trying to legalise everything. Probably we'll have a demo site for trading small amounts this month, and then once we gain the license, they want to setup a proper operation. You can preview it here, http://fishysnax.com/intersango/(not the final site & an older version) And source code is open too, http://gitorious.org/intersango/master/trees/master
|
|
|
Also, instead of the age you should have asked about the birth year imo.
+1 Nah, the OP has a timestamp on it. So you can always calculate it. And who cares whether it's +/- 3 years? I just want a general idea of the demographic.
|
|
|
You're right. In that case, it seems that going with strings is the only option.
All serious institutions (like banks) never use floats for currency calculations because they know the dangers. If we want to be seen as "serious", float is not an option. Yep but it's a problem with the json decoding in PHP/Perl/Python. The actual precision for the number in a JSON is accurate AFAIK.
|
|
|
It's nothing to do with Esperanto (except there's a translation of it). It's just a random (Esperanto) name picked for another Bitcoin client, http://en.wikipedia.org/wiki/SpesmiloThe Spesmilo was supposed to be a world currency to go with the world language of Esperanto :p Thought that the name had similar connotations with Bitcoin. BTW, I somewhat agree with luke-jr now I think about it. There's only one bitcoin.org, and having only 1 official version is exclusionary to all other competing implementations. In the same way email.org wouldn't only be about one program called Email but have links to a bunch of different versions.
|
|
|
I'm actually curious about this data. It'd be useful for people to know, so we can provide better services for each other.
My prediction: A few 13-16 year olds, majority 20-25, large portion of ~30, and some 35-50 year olds.
20-25 ~30 35-50 13-16
|
|
|
You're right. In that case, it seems that going with strings is the only option. Still it might be a good idea to have API versions (bitcoin.getinfo()["rpcversion"]) and take an optional -rpcversion command line argument. When you create a new API, then the old one is deprecated for at least one release cycle, allowing compatibility. When a new RPC version is created (lets call new version 1 and old version 0 for example) then: bitcoind The RPC version (0) in this release is DEPRECATED! Re-run bitcoind -rpcversion=1 for the new version. RPC changes can be found at http://bitcoin.org/rpcapi.htmlbitcoind stop bitcoind -rpcversion=1 bitcoind getinfo ... "rpcversion": 1 ... The policy would be to deprecate only when the API becomes backwards incompatible. Otherwise it's silently upgraded and becomes the default.
|
|
|
<?php $json = '{"a":1,"b":2,"c":3,"d":4.08,"e":5}'; var_dump(json_decode($json)); ?>
Output: object(stdClass)#1 (5) { ["a"]=> int(1) ["b"]=> int(2) ["c"]=> int(3) ["d"]=> float(4.08) ["e"]=> int(5) }
Why don't why put in a new number like nAPIVersion and call the current API 0. Then we can make nAPIVersion 0.5 supporting the int64 with appended .0 as luke-jr has done in his gitorious branch. Then I want to make an API version 1.0 which puts in a strict naming convention for the methods (getblaa, action instead of the current messy names) and use namespaces.
|
|
|
centrally planned = facebook federated/decentralised = email
|
|
|
The HTTP error codes are encoded into the JSON. But there are other errors like wrong username/password combination or status updates like new address added. You can't use HTTP header codes for those.
|
|
|
Anyone that prefers a saner API (because they're using PHP) should check out my branch, https://github.com/genjix/bitcoin/tree/strrpcValues are returned as int64 strings. function numstr_to_internal($numstr) { return bcmul($numstr, pow(10, 8), 0); } function internal_to_numstr($num, $precision=8) { $repr = gmp_strval($num); $repr = bcdiv($repr, pow(10, 8), $precision); # now tidy output... # trim trailing 0s $repr = rtrim($repr, '0'); # and a trailing . if it exists $repr = rtrim($repr, '.'); return $repr; }
Those are the 2 functions I use to convert from internal values to display/user input values (numstr). I updated the wiki, https://en.bitcoin.it/wiki/API_tutorial_%28JSON-RPC%29#PHP
|
|
|
I'm thinking that on first usage, it seamlessly creates a new account and uploads the public key of the first bitcoin address in your wallet. Then you sign further POST requests using that key. That way the server can verify that you are who you claim to be.
Should a person need to have their public key changed/removed (because they lost their wallet) then they can contact the server admins and they can decide how/whether to delete their account so they can create a new one.
|
|
|
Seems that domain names doesn't need to be part of your web browser. Why not do: BAR=$(grep google /etc/hosts | split 1) firefox $BAR You know it's not the same.
|
|
|
import urllib import decimal import json
class JSONRPCException(Exception): def __init__(self, rpcError): Exception.__init__(self) self.error = rpcError class ServiceProxy(object): def __init__(self, serviceURL, serviceName=None): self.__serviceURL = serviceURL self.__serviceName = serviceName
def __getattr__(self, name): if self.__serviceName != None: name = "%s.%s" % (self.__serviceName, name) return ServiceProxy(self.__serviceURL, name)
def __call__(self, *args): postdata = json.dumps({"method": self.__serviceName, 'params': args, 'id':'jsonrpc'}) respdata = urllib.urlopen(self.__serviceURL, postdata).read() resp = json.loads(respdata, parse_float=decimal.Decimal) if resp['error'] != None: raise JSONRPCException(resp['error']) else: return resp['result']
This should work in Python is anybody ever needs it. I've updated the wiki, https://en.bitcoin.it/wiki/API_tutorial_%28JSON-RPC%29#PythonIt's based off the old lib.
|
|
|
Usernames are case insensitive and can contain any character. Urls can have port numbers and paths attached. **@genjix@** rules@fishysnax.com:443/path/to/ That's a valid address. The username = "**@genjix@** rules" Now the URL is called using some remote methods like url + path + '/getaddress/' so that the implementation is non-specific to PHP. Anybody is free to create their own specific implementation with their own server policy. The current policy happens to be very simple (update record, set password, get address). Like a user who wanted to setup their own private provider could setup an implementation on their server and disable creation of new accounts. Obviously I want to get something in there with PK crypto... But haven't come up with a properly secure scheme yet. Many of them are prone to MITM attacks. However this can be used for small amounts effectively like a post on irc for somebody to send you X BTC to genjix@foo.org without having to open bitcoin. There's 2 class of queries- the public fetch record (uses GET) and the 2 calls to change things and require a password (and hopefully more security in the future- uses POST). The POST queries return a JSON. If there's a key by the name of "status" then it was successful and the value will give you an update as to what occured. If there's a key called "error" then it was unsuccessful and the value is an error message. The JSONs can also have other entries depending.
|
|
|
You can do everything in GMP except decode the JSON, which is what I think OP was complaining about.
No, I was complaining about the fact that the Bitcoin JSON-RPC Api uses numbers (that nearly all libraries convert to floats and have no option to change) when using strings would only be minorly impactful.
|
|
|
|