Glossary / Transactions & fees
Transaction version number
- Definition
- The transaction version number is the first four bytes of a transaction, and it tells validators which optional rule sets, such as relative timelocks, apply to it.
Only three values have ever meant anything. The field is not a software version, not a protocol version, and not a hint about which address types are inside, which is most of what people assume when they first see it. Consensus is largely indifferent to it, while relay policy is not, and that gap is the whole story of the field.
How it works
The version occupies bytes 1 through 4 of the serialized form, before the input count, and Bitcoin Core reads it as a signed 32 bit integer.
Version 1 is the original, used by every transaction in the first years of the chain. Version 2 exists because BIP68 needed a way to reinterpret sequence numbers as relative timelocks without invalidating older transactions, so it attached the new meaning to a version bump. From block 419,328 in July 2016, a transaction declaring version 2 has its sequence numbers checked as waiting periods, and one declaring version 1 does not. Modern wallets set version 2 by default whether or not they use timelocks, which is why almost everything you look up on an explorer says 2.
Version 3 arrived with Bitcoin Core 28.0 in October 2024, under the name topology restricted transactions, or TRUC. Declaring version 3 opts into a stricter deal: the transaction is always treated as replaceable, it may have at most one unconfirmed parent and one unconfirmed child, the child is limited to 1,000 virtual bytes and the transaction itself to 10,000. Those limits sound like a downgrade until you have been pinned, which is when a counterparty attaches a huge cheap descendant to your unconfirmed transaction so that bumping the fee becomes unaffordable. Lightning implementations adopted version 3 for exactly that reason.
Nothing in the consensus rules rejects a transaction for having version 7, or version 0. Standardness does: Bitcoin Core will not relay or mine versions outside the accepted set, so an unusual version is a transaction that has to reach a miner some other way.
Where you see it
Every block explorer prints the version near the top of a transaction's details page, and Bitcoin Core's decoderawtransaction returns it as the first field.
For anyone buying or holding bitcoin, it is a diagnostic rather than a decision. You never choose it, your wallet does. Its practical value is in reading unfamiliar software: a wallet still producing version 1 transactions in a world of relative timelocks is old, and a payment declaring version 3 almost certainly came out of a Lightning node's channel machinery rather than from a person pressing send.
Transaction version number vs block version number
Transactions and blocks both carry a four byte version field, and they have nothing to do with each other.
The block version tracks consensus upgrades. Version 2 blocks became mandatory at block 227,931 in March 2013 when BIP34 required the block height inside the coinbase input, version 3 enforced strict DER signature encoding under BIP66, and version 4 came with the CHECKLOCKTIMEVERIFY deployment. From 2015 onward the field was repurposed again as a set of signaling bits under BIP9, so miners could vote a soft fork in by flipping one bit of it. A transaction version does none of that. It never signals, it never counts upward with each upgrade, and it applies to one transaction rather than to the whole network's rule set.