TransactionTests Update: ttGasPrice

[marioevz]

Contains updated TransactionTests for category ttGasPrice.
Outstanding issues:

• The field seems to accept 256bit+ values.

[winsvega]

there must be an exception

[winsvega]

this should trigger an exception as field is >256bits

[marioevz]

Hi @holiman , it seems like this field accepts 256bit+ values, although it is impossible to make a valid transaction with such values, should t8ntool raise an exception?

[holiman]

it seems like this field accepts 256bit+ values, although it is impossible to make a valid transaction with such values, should t8ntool raise an exception?

Interesting. Yeah, whether t9n gives an exception or not is up for debate. I can go whichever way, really. t9n is mostly a tool to aid in test generation, not the actual test executor.

Having >256bit gasprice values is interesting -- e.g make a tx where the gas (21K) multiplied by gasPrice becomes something like 0x1000.....0030000, where the uppermost digit is outside of the 256 (or 64) bit boundary.

I think too high gasprices are not intrinsically invalid, just in that 'ghost area' on semi-validness which happens due to balances being capped at 256 bits.

[marioevz]

Having >256bit gasprice values is interesting -- e.g make a tx where the gas (21K) multiplied by gasPrice becomes something like 0x1000.....0030000, where the uppermost digit is outside of the 256 (or 64) bit boundary.

I just tested this scenario and the transaction is correctly rejected with 'insufficient funds' exception, so it seems ok at least for this client.
I will include this state test case in this PR.

[winsvega]

Question here, @holiman also
Perhaps we should extend transaction test suite to also export the amount of gas such transaction is expected to eat (among with sender, and hash)

Any of the 256bit overflow in tr fields should trigger an exception as this is a transaction structure unit tests many devs are using for testing

[holiman]

Perhaps we should extend transaction test suite to also export the amount of gas such transaction is expected to eat (among with sender, and hash)

So you're saying that t9n should export something like gasUsage from seeing a transaction? I don't see how that could possibly work, since t9n doesn't actually execute anything on a prestate. It's just the basic tx validations. In order to know how much gas is spent, it needs to be actually executed.

Any of the 256bit overflow in tr fields should trigger an exception as this is a transaction structure unit tests many devs are using for testing

Sure, can do that

[holiman]

Which tx has gasprice exceeding 256 bits? The one in HighGasPrice:

$ rlpdump -hex 0xf87e809f031eea408f8e1799cb883da2927b1336521d73c2c14accfebb70d5c5af006c82520894d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d001801ca039b081ab7094dff1b3ac79cbf8e381adc9f7a4e16290d7abc42dd006e5e062c5a033af00e26e5eb4431dcad601b2c8bf12d51eef2bd037d14681f22692ffab1ccd
[
  "",
  031eea408f8e1799cb883da2927b1336521d73c2c14accfebb70d5c5af006c,

That's "only" 31 bytes.

[holiman]

( and TransactionWithGasPriceOverflow.json was deleted in this PR)

[marioevz]

TransactionWithGasPriceOverflow.json has been added again. I deleted it the first time because, since it was expecting an error, it could not be filled. Now it passes with ethereum/go-ethereum#23743