Standardize Transaction RLP format to always include sigs/witnesses

[achiurizo]

In the code base we use a variety of different transaction RLP format forms:

• We use a raw/unsigned encoding - [transaction_type, inputs, outputs, tx_data, metadata]
• We use a signed encoding - [sigs, transaction_type, inputs, outputs, tx_data, metadata]
• We use an empty sig encoding - [ [], transaction_type, inputs, outputs, tx_data, metadata]

To make the output less suprising, should we standardize around always expecting the sig value to be present, even if empty? Some pitfalls that can occur is when we attempt to RLP encode a raw versus an empty signature transaction, these will produce two different binaries. If we conform to one, this will help avoid encoding issues like this.

Also note that Transaction.Signed here acts as a wrapper around the Transaction. But I think if we can clear up the interface and always produce a sig in the rlp data list, this will make it less surprising to work with.

If we agree, we should also update our integration doc transaction format to reflect these changes.

---

For ex_plasma, it's current behaviour is to drop the sigs if its not present, but we can fix that to always include the sig value, empty or not.

[pdobacz]

OK, to gather my thoughts and comments after our call

• I'd opt for keeping the explicit separation of signed and unsigned transactions (Transaction vs Transaction.Signed), and not have a "transaction with null/empty signatures field" mean an unsigned transaction
• the signed encoding is strictly for elixir-omg's use. It also could potentially be changed to anything else (i.e. non RLP). It uses RLP and follows this convention out of the initial motivation to have a single encoding scheme for both flavors
• not sure if this is considered here, but the contract will not like that, if the inclusion of sigs is forced on it. In the contract the signatures are always "picked" (only the relevant ones are sent over, separately), for gas-saving reasons.
• I don't think we currently use [ [], transaction_type, inputs, outputs, tx_data, metadata] anywhere (the link you posted doesn't indicate this)? or at least we shouldn't. Or do you mean the "permissive" IFE endpoint that we talked about, that there's an idea to add?