Why is this transaction version not a signed integer?

[werki]

Hi,
when I query transaction 5839f20446d7b9446e82c00117ee3699fa84154e970d57f09add60deef2eaa18 on the bitcoin testnet, my node's RPC reports a transaction version of 4294967295 (which is 0xFFFFFFFF).
However, according to https://developer.bitcoin.org/reference/transactions.html, this value should be signed integer of 4 bytes. This implementation https://docs.rs/bitcoin/0.31.1/bitcoin/blockdata/transaction/struct.Version.html follows the same rule and even implies that transactions with such a version would not be relayed by the network (but obviously still appear in blocks!). I wonder why the RPC does not return a version of -1 here, but instead a number that cannot be parsed into a signed 32bit integer?
BIP 68 even contains some reference code that implies that it should be a signed integer:

Code:

    // tx.nVersion is signed integer so requires cast to unsigned otherwise
    // we would be doing a signed comparison and half the range of nVersion
    // wouldn't support BIP 68.
    bool fEnforceBIP68 = static_cast<uint32_t>(tx.nVersion) >= 2
                      && flags & LOCKTIME_VERIFY_SEQUENCE;

Is this a bug in the bitcoin RPC serializer?

[1714670298]

1714670298

[1714670298]

1714670298

[1714670298]

1714670298

[1714670298]

1714670298

[achow101]

It's complicated.

The version number is stored as a signed integer. However, in every single place that it is being used, including in consensus code, it is being cast to an unsigned integer. So the RPC also does that since it's only ever actually interpreted as an unsigned int.

It probably should just be changed to an unsigned integer, but I think there was some discussion about that and there were fears that there may be some unintended side effects. Since it is consensus critical code, it could lead to consensus failure if something was overlooked.