Transaction constructor fails to initialize falsy values

[alcuadrado]

This is pattern that is probably present in other libs, at least block. The constructor uses non-boolean values as conditions to decide wether to initialize a field or no, so it's impossible to initialize them to falsy values.

Here's a way to reproduce it

const Common = require("@ethereumjs/common").default;
const { AccessListEIP2930Transaction } = require("@ethereumjs/tx");

const tx = new AccessListEIP2930Transaction(
  { v: 0 }, // 0 is a valid v value in eip 2930
  { common: new Common({ chain: "mainnet", hardfork: "berlin" }) }
);

console.log(tx.v) // this is undefined, but should be BN(0)

[holgerd77]

Ok, this is really bad, since this renders the whole AccessListEIP2930Transaction functionality unusable.

Not sure if I will make it to still submit a bugfix PR today, but we should generally release ASAP and likely - even if this doesn't look so good to admit - deprecate v3.1.1 and v3.1.2 on npm.

[holgerd77]

This is actually only happening in some certain constructor combination (so on fromTxData() respectively when using the main constructor directly), we have the general problem that we have the default value setting clustered which can get inconsistent. I will address this along on some PR.