I propose an additional fied:
"timestamp" which should be the date/time this transaction was observed by the monitoring system.
Good idea, then the receiver can also detect delayed notifications, due to outage of sender/receiver.
I suggest using a a standard timezone so we dont have to include timezone (zulu?)
Gaaah, i hate this timezone stuff. But indeed this should be un-ambigious a fixed Timezone.
I am currently working on extending notification possibilites of bitcoinmonitor.net to support outgoing payments. To support this also for http callback we should keep the wording neutral, so "to_address" would become "address" and "amount" can be positive for incoming and negative for outgoing payments.
Agreed, maybe a type field, to designate if the address is sender or receiver ?
I don't think this is necessary. It should be quite obvious: Negative amount -> Outgoing payment. Positive amount -> incoming payment.
As far as I know, it is a bit easyier to find a hash collision with MD5 than sha1, and bitcoin uses some form of sha.
But as a signature, I dont think the difference is all that big, I use sha1 today, but can switch to md5 if someone that knows the systems better, agrees that there is no security problem in it.
If sha1 is better for any reason - let's take it :-) No objection from my side.
Proposal how to store the data in the POST body:
Use a json string e.g.
{
"signed_data": {
"address": "12r9JzPNnyWs2j1s9KLW5keqBr4kbJjxz6",
"amount": 122678000,
"confirmations": 2,
"timestamp": "2012-02-19 10:37:20.203541",
"txhash": "e0c84120068bfefddab051e751f3df963c4ed29e7b13eadac026e6f17f55fb06",
"ip": "127.0.0.1"
},
"signature": "38a25ec14b9ffcfe98938f3e35ac9cf41de2a971",
"service": ""
}
Is there any specific reason you would rather post a json body than use the key=>value system ?
Using key=>value allows PHP scripts to access the data as $_POST['key'], instead of having to go with a json parser, and "internet of things" will have a hard time parseing json.
It has the advantage of allowing nested data structures. So like in my example we can nicely model an array of signed_data and it would be quite obvious which parameters to include for signature checking for everyone.
With a flat key=>value structure it's not so obvious anymore and might lead to errors.
Also json knows basic datatypes (strings, numbers, ...) so there is less risk of misinterpretation/wrong conversion.
A json-parser is available in any language you can think of (see
http://json.org/), and some/many popular languages have it already built-in.