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?)
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 ?
About the block number - Is this really necessary? I am not sure if it adds significant information. If not, i would omit it just to keep the list of parameters as short as possible.
I think some gambling sites would like it, to save an extra lookup to find the information, ie. the lotterly ended at block 27 which was the first block in Januar 1970.
While this is a very flexible approach it might make adoption of the system a bit more complicated. I think we should be able to agree on one algorithm. TBH I am lacking background knowledge to make an educated decision - basically I don't care which one to use.
There still would be the option to put the algorithm specifier outside the common signed_data part, so special solutions would still be possible.
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.
I hope we can agree on a sequence, so that the system does not need to load a list of fields to calculate the signature.
Very simple proposal which i chose also for bitcoinmonitor.net: Alphabetical ordering ;-)
Good idea, Agreed.
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.