Difference between revisions of "Cryptonite API"
m (small formatting fix) |
m (changed coin value to 10 dec places) |
||
| Line 32: | Line 32: | ||
Since Cryptonite uses 64-bit's worth of coin units, it is not safe to treat amounts as double precision floating point values unless they are smaller than about 32 million XCN. To prevent old code designed for use with bitcoin daemon from trying to parse Cryptonite amounts, all RPC calls use strings to represent amounts. We call this encoding the extended-precision encoding, or EP for short. | Since Cryptonite uses 64-bit's worth of coin units, it is not safe to treat amounts as double precision floating point values unless they are smaller than about 32 million XCN. To prevent old code designed for use with bitcoin daemon from trying to parse Cryptonite amounts, all RPC calls use strings to represent amounts. We call this encoding the extended-precision encoding, or EP for short. | ||
| − | EP numbers are strings in JSON, and must always have | + | EP numbers are strings in JSON, and must always have 10 digits after the decimal point followed by "ep". An example of a valid RPC command using an ep number would be: |
| − | <pre>./cryptonited sendtoaddress mvqH4czVQg2HdGpkV7PWVZJpRXVwLnMXpN "0. | + | <pre>./cryptonited sendtoaddress mvqH4czVQg2HdGpkV7PWVZJpRXVwLnMXpN "0.0100000000ep"</pre> |
All amounts returned in RPC results are also EP numbers, and you must take care to parse them, do not use floating point to represent them unless you are really sure of what you are doing. | All amounts returned in RPC results are also EP numbers, and you must take care to parse them, do not use floating point to represent them unless you are really sure of what you are doing. | ||
Revision as of 03:58, 25 July 2014
Contents
The Cryptonite API is similar to the Bitcoin API, containing a few additions and subtractions, some changed arguments, and some use restrictions. Almost all commands returning anything more than a hash will return different JSON objects as compared to bitcoin. You can use the help command to get more information about any command.
New commands:
- addmultisigaddress - Generates a multisig destination address from a list of signers
- getblockheader - Gets header component of block only
- setlimit - set withdrawal limit for an address
Modified commands:
- listunspent is now listbalances
- decoderawtransaction - Now has optional arguments to support successful decoding of partially signed multisignature transactions
- sendtoaddress,sendmany,sendfrom - The two comment fields have been replaced by a single message field that is actually included in the transaction
- signrawtransaction - Extra parameters allowed to help with signing of partially unsigned multisignature addresses
Restricted commands:
- getblock - May fail if block is more than 10k blocks from tip.
- gettransaction/getrawtransaction - Transactions older then 10k blocks may not be locatable.
Removed commands:
- getrawchangeaddress
- decodescript
- lockunspent
- listlockedunspent
A note about EP amounts
Since Cryptonite uses 64-bit's worth of coin units, it is not safe to treat amounts as double precision floating point values unless they are smaller than about 32 million XCN. To prevent old code designed for use with bitcoin daemon from trying to parse Cryptonite amounts, all RPC calls use strings to represent amounts. We call this encoding the extended-precision encoding, or EP for short.
EP numbers are strings in JSON, and must always have 10 digits after the decimal point followed by "ep". An example of a valid RPC command using an ep number would be:
./cryptonited sendtoaddress mvqH4czVQg2HdGpkV7PWVZJpRXVwLnMXpN "0.0100000000ep"
All amounts returned in RPC results are also EP numbers, and you must take care to parse them, do not use floating point to represent them unless you are really sure of what you are doing.
