Version in transaction

Question

Original transaction hex:

02000000000101fff8d9d39105eeec162fb45bd2a3e796b255866469a2cc7de93e438f3722c1490000000000fdffffff02801a0600000000001600145b497cfd64324fb0c4f7317472ca591cd7eb3bbfe093040000000000160014b1348ec3acd422b7c84f97f8757a0a5c3db9e32d02473044022020c3a9d7d06429008de82f13de672aac7886c5d6557a7c330bcb8cbc20b8cf4f02203890042ed8bf331e92f07df5d2a7bf5d8ade12cbb216f14493a98d0a188c4918012103c65a6e4a66a4a6b4af981c5e81632bb2d7336bc75d7ccf83e055006a2693050f00000000

Changing first two characters from 02 to 03 (Version 3):

03000000000101fff8d9d39105eeec162fb45bd2a3e796b255866469a2cc7de93e438f3722c1490000000000fdffffff02801a0600000000001600145b497cfd64324fb0c4f7317472ca591cd7eb3bbfe093040000000000160014b1348ec3acd422b7c84f97f8757a0a5c3db9e32d02473044022020c3a9d7d06429008de82f13de672aac7886c5d6557a7c330bcb8cbc20b8cf4f02203890042ed8bf331e92f07df5d2a7bf5d8ade12cbb216f14493a98d0a188c4918012103c65a6e4a66a4a6b4af981c5e81632bb2d7336bc75d7ccf83e055006a2693050f00000000

Version in blocks is used by miners for signaling readiness in soft forks. Can there be use cases for different version numbers in transactions?

According to this answer: https://bitcoin.stackexchange.com/a/72742, if its not 1 or 2 then transaction is not standard. So I am assuming nodes will not relay such transactions as mentioned in another answer: https://bitcoin.stackexchange.com/a/41008/. This is weird because a field in transaction which could have been used for several things is just limited to 1 and 2. Are there any downsides if all versions are considered standard and let the projects use it however they want to?

What are the minimum, maximum and invalid values for it? I tried using ff for negative 1 but it returned 255 in version

Answer 1

Indeed, the only standard versions are still 1 and 2. The transaction version number can be used to indicate consensus feature support. So far there has only been one such feature - BIP 68. Because special rules for other versions have not yet been defined and accepted, the standardness rules limit the version just to the 2 known version numbers. But this does not mean that it can't be changed in the future. Much like how we have output scripts that are non-standard, but can become standard with a future update, same can the transaction version.

Are there any downsides if all versions are considered standard and let the projects use it however they want to?

Yes. Because the transaction version can control how validation is performed on transactions, letting people set the version to whatever they want could restrict what functionality could be added in the future or restrict what version numbers can be used. But it is also just a standardness rule, so you are welcome to use whatever version you want if a miner is willing to accept the transaction out of band.

What are the minimum, maximum and invalid values for it? I tried using ff for negative 1 but it returned 255 in version

The version number is 4 bytes, not 1 byte. It is actually a 32 bit little endian signed integer (note it is parsed and stored as signed, not unsigned, but cast to unsigned and used as unsigned in many but not all places). This makes it's minimum value is -2147483648 == 0xffffffff and it's maximum is 2147483647 == 0x7fffffff.

Answer 2

Other transaction version numbers are for future consensus rules. If you create transactions using undefined versions numbers they may be invalidated by future consensus rules, or their outputs may be made unspendable by future consensus rules.

Using other version numbers today would have no legitimate purpose, but if applications weren't effectively blocked from doing it would mean that a future upgrade that needed to use version numbers would be effectively blocked or the funds of users who were pointlessly using the numbers might be irreparably destroyed.

This is why the use of these pointless encodings is inhibited-- to keep it safe to use them for extension, as they're intended and as a secondary purpose to keep faulty software from accidentally using them-- which has happened in the past, e.g. libbitcoin leaked uninitialized memory in version numbers-- and coming to harm when some rule is activated.