ByteStamp WebServices HowTo

Generic WS call In order to use ByteStamp WebServices you must run a BTC/DTC Wallet. This wallet has an address […]

Generic WS call

In order to use ByteStamp WebServices you must run a BTC/DTC Wallet. This wallet has an address that is used to sign a message each time a WebService is called. This signed message acts like an authentication system at ByteStamp Server.

The public address used to sign the above message must be put in the header of the web service call, in the param X-USER-TOKEN. The address must follow the ByteStamp notation format, i. e. you must separe the type of the cryptocurrency from the address by a colon (:). For example, if you have a Bitcoin wallet with address 123456, here you have to put BTC:123456. While, if you ha a Datcoin wallett with address 7890123, the value is DTC:7890123

The signature goes in the header in X-USER-SIGNATURE.

Optionally, if you have an application code assigned by ByteStamp, you can put it in header in

X-USER-APPCODE

The above info is for header building, follow info for the parameters of the WebServices.

The message to be signed goes in the param strcmd. Every WebService has this parameter.

The message must be unique for each WebService call.

The strcmd parameter is a string made of 4 parts pipe separated (‘|’):

  1. UTC Time in the YYYYMMDDHHmmSS format
  2. type and address, the same of X-USER-TOKEN in header
  3. current command in the format: <CalledWebService>;{“param1” => “value1”, “param2” => “value2”,…}

So:

  • the called action is followed by a semicolon (‘;’)
  • after the semicolon, parameters are between curly brackets (‘{}’)
  • parameters keys are between quotation marks (“‘)
  • each key is followed by an arrow (‘=>’) and then by its value
  • each value is between quotation marks (“‘)
  • each key/value pair is separed by a comma (‘,’)
  1. ByteStampMD5 applied on the chaining of the ByteStampMD5 of previous command with the current one: For example:
  • if the first command is: api.bytestamp.net/api/v2/bs/944555227/upd

with ver param set to 19 (‘–form ver=19’)

then the command is :

upd;{“ver”=>”19”}

then this field value is

58c77c17961252019bfb611901ed0de7

because ByteStampMD5 of

upd;{“ver”=>”19”}

is

“e1d196197948033636ce03c2d2ab3917”

but this must be added to ByteStampMD5 of previous command, that is an empty string, so we have:

“” + “e1d196197948033636ce03c2d2ab3917” = “e1d196197948033636ce03c2d2ab3917

Now, we must apply another time ByteStampMD5 algorithm to the above string and so we have:

ByteStampMD5(“e1d196197948033636ce03c2d2ab3917”) = 58c77c17961252019bfb611901ed0de7

That is the hash that must be put in position 4 of strcmd

Now, if the following command is:

api.bytestamp.net/api/v2/bs/944555227/upd

with ver param set to 20 0 (‘–form ver=20’)

then the command is :

upd;{“ver”=>”20”}

then its ByteStampMD5 is:

45fdb369c77cdd06b417ee826d057bc8

now this ByteStampMD5 must be chained with previous one:

“58c77c17961252019bfb611901ed0de7” + “45fdb369c77cdd06b417ee826d057bc8” =

“58c77c17961252019bfb611901ed0de745fdb369c77cdd06b417ee826d057bc8”

now we apply ByteStampMD5 algo on the above string, and we put the output in position 4 of strcmd:

a087154ffb8683422a6910cd76e03cf9

because the l ByteStampMD5 of:

“58c77c17961252019bfb611901ed0de745fdb369c77cdd06b417ee826d057bc8”

is

“a087154ffb8683422a6910cd76e03cf9”

This ByteStampMD5 (“a087154ffb8683422a6910cd76e03cf9”) , in turn, will be chained to ByteStampMD5 of following command, and on the resulting string will be applied another time ByteStampMD5 algo, and so on

curl -X POST -H ‘X-USER-TOKEN: <type:addresst>’ -H ‘X-USER-SIGNATURE: <signature>’

-H ‘X-USER-APPCODE: <ApplicationCode>’ –form

strcmd=’YYYYMMDDHHmmSS,type:address,CurrentCommand,ByteStampMD5ofByteStampMD5currentCommandByteStampMD5PreviousCommand’ https://api.bytestamp.net/api/v…

When ByteStamp answers to the api calls to WebServices, it includes a bssign parameter in the output.

The bssign value is the ByteStamp signature of the strcmd stringthat was sent by client.

The client can use this signature to verify ByteStamp identity. This must be checked against ByteStamp Datacoin or Bitcoin address that was assigned by ByteStamp together the application code.

Register/Verify ByteStampMD5 with ownership

https://api.bytestamp.net/api/v2/bs/<RandomNumber>/bstmd5

(see above for strcmd)

it returns:

{“ris” => {}, “nocred”:0, “tot”:0, “credres”:0, “dafs”:{}, “error”:0,

“bssign” => “”}

tot total cost operation

credres remaining credit. If this is a simulation then this is the credit before the operation, otherwise it is after

nocred if 1 then insufficient credit

ris Only returhed if parameters reg, own and tra are unset,or set to 0 (zero).

This is to verify files already registered in Blockchain.

It has key/value pairs where each key is one of the ByteStampMD5 sent in the md5s parameter, and each value has, in turn, key/value pairs with ByteStampProof details of the ByteStampMD5.

dafs Only returned if own or tra parameters are set to 1.

These are parameters to be used in the WebService signasset to sign an ownership transfer of a ByteStamp Digital Asset.

bssign ByteStamp signature see above

Web Service Parameters:

md5s Comma-separated list of ByteStampMD5

reg If 1 register files, otherwise verify it

sim If 1 only simulation

own if 1 also take ownership of each ByteStampMD5

tra If 1 transfer ownership of each ByteStampMD5

tokey Recipient address, i.e. new owner of the ByteStamp

Digital Assets identified by ByteStampMD5 of md5s parameter. In the format TypeCrypto:Address

The Sender of the ByteStamp Digital Asset always is the address in the X-USER-TOKEN in the header