Modify SignBytes format

[ethanfrey]

Before we sign a transaction, we calculate the sign bytes. These are currently the serialized transaction without signatures, followed by the chain Id and then an 8-byte nonce (account sequence).

This is easy to compute, but if we hand the SignBytes into a module to be signed (eg. a ledger app), it is hard to impossible to properly parse. The SignBytes were never meant to hit the wire before so this was not really considered, but Simon made a good point a few places and a proposal here: iov-one/iov-core#56 (comment)

format version | chain ID length | chain ID            | nonce | bz
int32          | int32           | utf8 encoded string | int?  | raw data

I would accept that proposal more or less with minor changes

format version | chain ID length | chain ID            | nonce | bz
4bytes          | int8           | utf8 encoded string | int64 (bigendian)  | raw data

the chain Id should be maximal ~32 bytes, so one byte for encoding the length is sufficient.
the nonce is a fixed 8 byte length, in BigEndian format. ChainId should be a subset of ascii, but we can define it as utf8 to be more permissive in parsing.

The version doesn't need just to be a counter 00000001, 00000002, ... but a unique identifier than can change between different versions. It also is a known magic number to inform how to interpret the following data.

We should use unique prefix(es) that are not simply a counter, to ensure minimal collision with other known formats and encodings. I propose the first version will be the prefix 00CAFE00 (no coffee), somewhat inspired by java class files CAFEBABE.

Updating this calculation will break the signing algorithm used in clients such as weave-js and should be accompanied with a version bump.

[webmaster128]

See also #70. Fell free to close/merge/modify any of those two Github issues how ever it makes most sense.

[ethanfrey]

I didn't see #70 when I opened this. Silly me.
Closing this in favor of the existing issue.