Add support for non-byte chain id values

[conor10]

In the current web3j implementation, the ChainId is of type byte.

The reason for this is historical,to support EIP-155, where you place a byte value in the raw transaction object - see here.

However, further down the original EIP discussion it is mentioned that the v value when the transaction is RLP encoded shouldn't be limited to a single byte. So web3j could be enhanced to accommodate this.

This would mean enhancing the Transaction encoder so that a long value can be provided:

https://github.com/web3j/web3j/blob/master/crypto/src/main/java/org/web3j/crypto/TransactionEncoder.java#L34

The SignatureData object should not however be modified as this requires a byte value for v in transaction signing. This means that in the initial encode of the RawTransaction the chain id field should be RLP encoded, which would require modification of the current encode method.

The ChainId itself should probably become an enum wrapping the underlying long value.

[fcorneli]

@conor10 Any news on this issue? We would want to use a geth dev network with chainId 1337...

[fcorneli]

I've been looking into this one a bit. See PR #478
ChainId of type byte is really all over the place.
Easiest to move forward here I guess is to first have a TransactionDecoder and proper signature validation within RawTransaction and work your way up from there.

[fcorneli]

Started working on that TransactionDecoder:
https://github.com/e-Contract/web3j/tree/transaction-decoder

[fcorneli]

Seems like Sign.signedMessageToKey has a problem when the message has been signed with an explicit chain id.

[fcorneli]

TransactionDecoder ready: #491
Funny thing: change chainId within TransactionDecoderTest.testDecodingSignedChainId to something else than 1, and the test explodes. But anyway, it's already a starting point I guess...

[fcorneli]

You can change chainId within TransactionDecoderTest.testDecodingSignedChainId up to 46 without any problem. Above 46, the v requires more than one byte I guess, so it fails from there on.

[fcorneli]

Next step I guess is to allow for byte array v within Sign.SignatureData:
https://github.com/e-Contract/web3j/tree/signaturedata-v-array

[adridadou]

any news on that? it's limiting if we want to use it for non public chains ...

[d10r]

Looks like this was fixed in #913, included in release 4.3.
Unfortunately the last android build is 4.2 though. (update: nomore the case, there's no android builds including this fix)