Verify data integrity

[moshababo]

Add checksum/hash field to the packet header. On receiving, verify the packet data integrity.

[sangaman]

A hash is currently added to the header of all packets with a body. For this issue, we want to calculate the has of received packets ourselves and make sure they match the hash we were sent. We also want to verify that the structure of the packet is what we expect - all the required properties using the right types, no unexpected properties, and we also should sanity check. For example, strings should have max lengths.

It also would be good to have some rate limiting for certain packets, for example we don't want to be spammed with GET_ORDERS packets even if they are valid.

We'll also want some system of penalizing peers for sending bad packets, with more severe penalties for problems that are due to malice rather than faulty transmission.

[kilrau]

Scope of this issue:

• Add checksum/hash field to the packet header.
• On receiving, verify the packet data integrity.
• Receive data structure of packet is what we expect
• rate limit for certain packet types like GET_ORDERS per nodePubKey

[moshababo]

1st is done. All the rest can be done separately.

[kilrau]

Updated scope of this issue:

• On receiving, verify the packet data integrity via the checksum/hash field.
• Receive data structure of packet is what we expect
• rate limit for certain packet types like GET_ORDERS per nodePubKey

[kilrau]

Do we still need this when we do (packet serialization)[https://github.com/ExchangeUnion/xud/issues/159#issuecomment-435583439]? @moshababo @sangaman

[kilrau]

Moved to next milestone, not too critical

[moshababo]

@kilrau we won't need to do most of this if we'll change to protobuf serialization (#159). but it's not a trivial change.

[kilrau]

https://github.com/ExchangeUnion/xud/issues/159 is a requirement

[moshababo]

Lets limit the scope of this issue solely to:

• On receiving, verify the packet data integrity via the checksum/hash field.

In regards to the others:

• Receive data structure of packet is what we expect -

159 will make this unnecessary.

• rate limit for certain packet types like GET_ORDERS per nodePubKey -

I don't think it's related to here. I've opened #708.

[moshababo]

Waiting for #159.