txid - hash of the transaction itself
Indeed. It is the hash of the transaction without witness data included (if any).
hash - hash of the transaction itself. If transaction is non-segwit, txid == hash, otherwise in segwit transactions the transaction hash is different.
Indeed. It is the hash of the transaction with witness data included (if any). The serialization this is commputed over is defined in BIP144.
version - this is obvious what it is, but how should be interpreted?
It reports the contents of the transaction's
Currently there are two transaction version numbers defined:
- 1: the original version number
- 2: defined in BIP68. Transactions with this version number (or higher) have their
nSequence fields interpreted according to the new rules specified in BIP68.
- Any other version numbers are non-standard (won't be relayed by common node software on the network), but permitted by to block validity rules. 0 has the same meaning as 1; 3 and higher have the same meaning as 2.
size - size of the transaction in bytes
Indeed. It is the size of the transaction's serialization.
vsize - weighted size for segwit transactions
Indeed. It is the size of the serialization, where witness data is discounted by a factor 4, as specified in BIP141.
locktime - lock time of this transaction either in block height either in unix time. OP_CLTV is only determinable from the redeemscript, not from this field.
Indeed. It reports the value of the transaction's
nLocktime field. It is the time or height until which the transaction cannot be included in a block. So for example, a transaction with
locktime 700000 can only be included in blocks with height 700001 or higher.
OP_CHECKLOCKTIMEVERIFY opcode (aka
OP_CLTV; defined in BIP65) provides a way to enforce constraints n the
nLocktime field of the spending transaction from inside scripts, and thus indirectly on the time when the output can be spent. It is available in all script constructions (bare, P2SH, P2WSH, ...), but would be nonstandard in bare ones.
vin - this subset includes all the inputs being spent.
This is an array containing information about all the transactions' inputs, which are stored in its
- txid - txid of the input being spent.
More specificially, it is the
hash value of the transaction input's
prevout field, which contains the txid of the transaction that created the UTXO being spent by this input.
It is the
n value of the transaction input's
prevout field. It reports which index in the creating transaction's
vout array is being spent.
- scriptSig - asm / hex - this includes the signature(s) and redeemScript of this particular input. Is there any difference between asm and hex?
Indeed. The hex value is exactly what is stored in the transaction. The asm value is a more human-readable decoding of that data.
- sequence - how can this be interpreted? How can one determine if the input is either CSV locked, either replace-able by fee (RBF)?
It is the value of the transaction's
It modern meaning is twofold:
- Whenever a transaction has
nVersion 2 or higher, and the
nSequence value is less that 22, the BIP68 rules apply, which puts constraints on how long ago the output being spent must be before this transaction is valid (in height or time). The BIP112 opcode
OP_CSV) provides a means in script to put constraints on the
nSequence value (and thus indirectly on the relative time the output can be spent).
- BIP125 specifies a potential policy (not consensus rule) for nodes about replacement of transactions while in the mempool. Specifically, it permits replacement of any transaction whose
nSequence value is not 0xFFFFFFF or 0xFFFFFFFE. This is the case for any transaction input using relative locktime as discussed in the bulletpoint above. Note that modern nodes as of writing do not implement the BIP125 policy rules exactly, though not in a way that makes this description invalid.
vout - this subset includes all the outputs of the transaction:
This is an array containing information about all the transactions' outputs, which are stored in its
- value - amount of this output.
- n - this looks like the number / ordering of outputs?
It is the analogue of the vout field in the inputs. When an input spends a particular UTXO created by this output, it needs to refer to this transactions' txid and
- scriptPubKey - script or pubkeyhash of the output
It contains the locking script of the UTXO being created, which defined the conditions under which it can be spent. For P2PKH outputs, this is a script that requires a signature by a public key whose hash is a specific value, but it is still a script.
- reqSigs - how can this be known in advance by the sender, only by having the address?
It can, but only for bare multisig scripts (where the full script is stored in the output directly, and not via a redeemScript), which are deprecated and nonstandard as writing. The reqSigs field is also being deprecated now for that reason. It is just confusing.
- type - how can this be know in advance as well?
It is the type of output. e.g. it can tell the difference between a P2PKH or P2SH output. It cannot know what the P2SH output's script is, until it gets spent.
- How can the amount of each input within the vin subset be determined?
It is looked up in the UTXO set database at spending time, using the
vout fields reported in the RPC output. Those two unique identify a transaction output (number
vout of transaction whose txid is
txid), and the UTXO set remembers its
- How can the scriptSig be validated, like: is the input CLTV or CSV locked? Does the redeemScript (if p2sh) validate to true (e.g. required number of sigs available, other IF/ELSE rules fulfilled)?
Execution proceeds as follows, roughly:
- First the
scriptSig is executed. The final stack state is remembered. If it fails, the transaction is invalid.
- Then the
scriptPubKey of the output being spent is executed, with the previous final stack state as initial state. This
scriptPubKey is looked up in the UTXO database as listed above. So what this effectively does is running the locking script, with the
scriptSig as input; if that fails, the transaction is invalid.
- Then, as a special step, if the
scriptPubKey matches the BIP16 (P2SH) template exactly, an additional rule triggers: the final scriptSig element is treated as another script, and executed with all but the final scriptSig element as input.
Similar rules apply to P2WSH (BIP141) and P2TR (BIP341) spends.