TransactionTests Update: ttValue

[marioevz]

Contains updated TransactionTests for category ttValue.
Outstanding issues:

• The field seems to accept 256bit+ values.

[marioevz]

Hi @holiman, this field also allows values greater than 256bits. I added an state test for this, similar to the one added to the one suggested in #956.

[holiman]

The 'high value' one:

rlpdump -hex 0xf87f800182520894095e7baea6a6c7c4c2dfeb977efac326af552d87a0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff801ba048b55bfa915ac795c431978d8a6a992b628d557da5ff759b307d495a36649353a01fffd310ac743f371de3b9f7f9cb56c0b28ad43601b4ab949f53faa07bd2c804
[
  "",
  01,
  5208,
  095e7baea6a6c7c4c2dfeb977efac326af552d87,
  ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff,
  "",
  1b,
  48b55bfa915ac795c431978d8a6a992b628d557da5ff759b307d495a36649353,
  1fffd310ac743f371de3b9f7f9cb56c0b28ad43601b4ab949f53faa07bd2c804,
]

The value is ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff -- exactly 32 bytes/ 256 bits. .
Overflow:

rlpdump -hex f880806482520894d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0a1010000000000000000000000000000000000000000000000000000000000000001801ba0c16787a8e25e941d67691954642876c08f00996163ae7dfadbbfd6cd436f549da06180e5626cae31590f40641fe8f63734316c4bfeb4cdfab6714198c1044d2e28
[
  "",
  "d",
  5208,
  d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0,
  010000000000000000000000000000000000000000000000000000000000000001,
  "",
  1b,
  c16787a8e25e941d67691954642876c08f00996163ae7dfadbbfd6cd436f549d,
  6180e5626cae31590f40641fe8f63734316c4bfeb4cdfab6714198c1044d2e28,
]

Indeed, it's 33 bytes.

So you want t9n to issue an error on these?

[holiman]

The real validation rules work like this:

	// 1. the nonce of the message caller is correct
	// 2. caller has enough balance to cover transaction fee(gaslimit * gasprice)
	// 3. the amount of gas required is available in the block
	// 4. the purchased gas is enough to cover intrinsic usage
	// 5. there is no overflow when calculating intrinsic gas
	// 6. caller has enough balance to cover asset transfer for **topmost** call

Additionally, there are extra constraints in London about maxPriorityFee and maxFee. There is no explicit validity check that the value must be <256 bits, theoretically, but it would fail check 2.

I can add a 'synthetic' helper-check in t9n, but it doesn't actually map to any real error during block processing.

[holiman]

ps. See core/state_transition.go in go-ethereum for more details

[holiman]

ps. please file a ticket in go-ethereum for change requests on t9n

[marioevz]

Thanks for the explanation @holiman, I have filed ethereum/go-ethereum#23740.

[winsvega]

No, I think it should get rejected. as all values in Yellow paper are 256 bit max.
so the balance check should not occur as the structure itself is invalid