Jochem Brouwer
> If you look at the raw serialized transaction, I don't think it matters whether you use the "null" address or the zero address, it serializes as the same thing...
> You can send ETH to any address, including the zero address. If a contract is created from the data payload, that ETH will be added to the contract account...
 ?
Ah - right, in that case you are correct. But this should not change stuff, since `sender` should already be in the warm access lists, as it was previously target...
True - sorry, I indeed meant the parent caller here, not `tx.sender` / `ORIGIN`.
It does make sense, but without [this](https://github.com/ethereumjs/ethereumjs-devp2p/pull/83/files#diff-d4f3dd7334a3b3002cca0903b5eca3fdL137) change it always means that a RLP connection is made from a random local port. I don't think that this is correct. If...
Yep it's no problem to recreate it. And indeed it would be nice to get a general overview of the ports which are used.
Hey @shamatar, thank you for the reply. A very good point about the state tests. I actually thought that the return values were part of the `receiptsTrie`, but this is...
@shamatar Good point about the post-EIP hardforks, but this does not apply to just this one but would apply to other EIPs as well, so one should explicitly write state...
Well, if we start throwing on `put` as well, then this is breaking, right?