Any ideas how to solve it? I currently switched to different library, but wish to let you know about this problem.

https://etherscan.io/tx/0xb6c83f4b066f56731fb808e7019df2efe61decaf29dfaa71aea5e853b8963418

https://trade.fhn-capital.org/login

pub struct Account { pub nonce: U256, ... }
But in go ethereum, it is
type Account struct { Nonce uint64 ... }
looks like 24 bytes are wasted, is this intended? why?

It'd be nice if you can release 0.12.0, so we can update primitive-types and ethereum in Sputnik: rust-ethereum/evm#101

There is no need to implement rlp::Encodable and rlp::Decodable on the enveloped TransactionV1 and TransactionV2 types.

According to EIP-2718, the leading byte of an enveloped transaction determines the format of the remaining bytes, but the envelope itself is not rlp-encoded.

In other words, the format for enveloped transactions is TransactionType || TransactionPayload, so in the case of EIP1559 transactions for example, the envelope should be 0x02 || rlp(EIP1559Transaction). However using this library, you effectively end up with rlp(0x02 || rlp(EIP1559Transaction)), which is incorrect.

This means, for example, I would have expected to be able to decode a raw ethereum tx like so: TransactionV2::decode(&raw_bytes), however for non-legacy transactions this fails with RlpExpectedToBeList.

It might make sense to remove/deprecate the implementations of rlp::Encodable and rlp::Decodable for the TransactionV1 and TransactionV2 enums since there should never be a reason to rlp-encode the envelope in the first place.

As currently implemented, the Receipts message test case in EIP-2481 cannot be deserialized. This is because the definition of Receipt uses type H256 (which has a fixed-sized, 32 byte serialization) instead of U256, which has a variable length serialization.

pub struct Receipt {
	pub state_root: H256, // Should to be U256
	pub used_gas: U256,
	pub logs_bloom: Bloom,
	pub logs: Vec<Log>,
}

To verify the issue, you can use an RLP debugger to deserialize the test case and check that the entry corresponding to state_root is encoded as a number, not a vector.

You can also reproduce the issue by pulling akula-bft/akula#19 locally, patching your ethereum crate on disk, and then verifying that the unit test decode_receipts passes.

@sorpaas Could you release a new version v0.12.1 that includes PR #41 ?