BIP Draft: Terminology of Transaction Components #2195

murchandamus commented at 1:00 AM on June 9, 2026: member

This informational BIP provides a set of terminology to refer to the various components, scripts, and concepts used to compose Bitcoin transactions.

This proposal was discussed in 2023 on the mailing list and had subsequently been reviewed and developed against my personal BIPs repository. I recently picked it up again to address the outstanding review and would now like to put it forth for broader consideration.

Note on pull request organization: During this initial review phase, I will append commits for each change to make it easier for reviewers to check whether their comments have been addressed adequately. The PR will be reorganized into one or a few commits as this document approaches publication.

Todos:

Add definition for the Witness Reverved Value (BIP141) (Sjors)
Inconsistency of Condition Script (see #2195 (review), vostrnad)
Inconsistency of use of Forwarding Script (see #2195 (review)), vostrnad)

murchandamus added the label New BIP on Jun 9, 2026

Add transaction terminology bip 5491adc896

murchandamus force-pushed on Jun 9, 2026

in bip-tx-terminology.mediawiki:1 in 5491adc896 outdated

   0 | @@ -0,0 +1,351 @@
   1 | +<pre>

Sjors commented at 7:11 AM on June 9, 2026:

nit: any reason to still prefer mediawiki over markdown?

murchandamus commented at 3:13 PM on June 9, 2026:

It was already written in MediaWiki, but also, GitHub Markdown doesn’t natively support definition lists.

in bip-tx-terminology.mediawiki:215 in 5491adc896 outdated

 210 | +: [Concept] The part of the serialized transaction that contains the witness stacks for each input. Transactions without segwit inputs are serialized without a witness structure.
 211 | +: Synonym: <code>script_witnesses</code> (BIP144), witness (BIP141, underdefined without more context, as "witness" is used for both witness structure and witness stack)
 212 | +
 213 | +; witness script
 214 | +: [Component] A witness item that provides the condition script used to spend P2WSH outputs. Appears in the witness stack.
 215 | +

murchandamus commented at 8:34 PM on June 9, 2026:

Todo: Add definition for the Witness Reverved Value (BIP141)

cc: @Sjors

murchandamus commented at 5:41 PM on June 11, 2026:

Moved to the OP.

in bip-tx-terminology.mediawiki:65 in 5491adc896

  60 | +; coinbase
  61 | +: [Component] The coinbase field takes the place of the input script in a coinbase transaction (named after this field), since coinbase transactions do not spend a previous transaction output (TXO).
  62 | +
  63 | +; <code>CompactSize</code>
  64 | +: [Concept] A variable-length integer encoding used in the transaction serialization to express input and output count.
  65 | +: Synonym: <code>VarInt</code> (do not use, see [[compactsize|Rationale]])

vostrnad commented at 10:24 PM on June 9, 2026:

The Rationale links lead to a 404.

murchandamus commented at 7:39 PM on June 10, 2026:

Added the missing pound sign.

in bip-tx-terminology.mediawiki:68 in 5491adc896 outdated

  63 | +; <code>CompactSize</code>
  64 | +: [Concept] A variable-length integer encoding used in the transaction serialization to express input and output count.
  65 | +: Synonym: <code>VarInt</code> (do not use, see [[compactsize|Rationale]])
  66 | +
  67 | +; condition script
  68 | +: [Concept] Umbrella term for scripts that encode the actual spending conditions that must be fulfilled to spend a TXO. Condition scripts may be preceded by one or more forwarding scripts. An output script will either directly contain a condition script in the case of a bare output, or commit to one or multiple condition scripts for other output types. For P2TR both the taproot internal key and each leaf script in the script tree are considered condition scripts. At the time of writing, there are five distinct condition scripts: taproot output key, leaf script, witness script, redeem script (only non-segwit P2SH), and bare output script (P2PK, P2PKH, P2MS, and arbitrary scripts).

vostrnad commented at 10:24 PM on June 9, 2026:

I think this is somewhat contradictory in multiple ways:

If a "condition script" is indeed meant to be a script (and the first sentence explicitly confirms it) then the taproot internal key and the taproot output key aren't condition scripts – the former is a part of the control block (itself a witness stack item that's not a script) and the latter is a witness program (a data push in an output script, not a script itself).
It says a taproot internal key is considered a condition script, but then doesn't include it in the (presumably exhaustive) list of condition scripts.

in bip-tx-terminology.mediawiki:71 in 5491adc896

  66 | +
  67 | +; condition script
  68 | +: [Concept] Umbrella term for scripts that encode the actual spending conditions that must be fulfilled to spend a TXO. Condition scripts may be preceded by one or more forwarding scripts. An output script will either directly contain a condition script in the case of a bare output, or commit to one or multiple condition scripts for other output types. For P2TR both the taproot internal key and each leaf script in the script tree are considered condition scripts. At the time of writing, there are five distinct condition scripts: taproot output key, leaf script, witness script, redeem script (only non-segwit P2SH), and bare output script (P2PK, P2PKH, P2MS, and arbitrary scripts).
  69 | +
  70 | +; control block
  71 | +: [Component] The proof of existence for a leaf script. Appears as a witness item in witness stacks for P2TR scriptpath inputs, but does not get evaluated by the condition script. Only consists of the taproot internal key for script trees with a single leaf script, otherwise provides the taproot internal key as well as a taproot branch in the form of the hashing partners for the used leaf script.

vostrnad commented at 10:24 PM on June 9, 2026:

Why "scriptpath"? The Taproot BIPs (i.e. the canonical source for the term) use "script path", and all 9 other BIPs that reference it use the spaced form as well.

murchandamus commented at 7:44 PM on June 10, 2026:

Replaced all instances of keypath and scriptpath with the two word spelling.

in bip-tx-terminology.mediawiki:77 in 5491adc896 outdated

  72 | +
  73 | +; flag
  74 | +: [Artifact] A serialization artifact indicating features used by the transaction. As of writing, the only allowed value is <code>01</code> which indicates that the transaction serialization has a witness structure (see [[https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki|BIP144]]).
  75 | +
  76 | +; forwarding script
  77 | +: [Concept] A collective term for scripts that redirect input validation to another script or data structure. Witness programs and P2SH Programs are forwarding scripts. Forwarding scripts make use of script templates that imply additional evaluation steps beyond the explicitly expressed conditions. In the case of P2SH, the output script itself only explicitly specifies that the redeem script must be the preimage of the hash in the output script, but the template prescribes that the redeem script must additionally be satisfied. For witness programs, the output script is even less verbose with more implied meaning.

vostrnad commented at 10:24 PM on June 9, 2026:

Same problem as above: the witness and P2SH programs aren't scripts, they're byte arrays pushed in an output script. A SegWit/P2SH output script is the forwarding script in this case.

in bip-tx-terminology.mediawiki:90 in 5491adc896

  85 | +
  86 | +; input index
  87 | +: [Concept] The position of an input in a transaction’s input list.
  88 | +
  89 | +; input script
  90 | +: [Component] The Bitcoin code base used Hungarian notation when it was published. This transaction field appearing in transaction inputs was named for containing the signature and being of the type script. Today, this field is better understood as the input script which is used to satisfy spending conditions for non-segwit outputs, redirects validation to the witness stack for wrapped segwit outputs, and is empty for native segwit outputs. The input script may contain an actual script when spending a bare output script, but may only contain push operations for any output type since P2SH.

vostrnad commented at 10:24 PM on June 9, 2026:

The description should include the name scriptSig like the description of output script does. Seeing how you mention Hungarian notation in both places it seems like an accidental omission here.

murchandamus commented at 7:49 PM on June 10, 2026:

Mentioned scriptSig.

in bip-tx-terminology.mediawiki:97 in 5491adc896

  92 | +
  93 | +; leaf script
  94 | +: [Component] A condition script used for spending P2TR outputs via the scriptpath. The leaf script appears as a witness item.
  95 | +
  96 | +; leaf version
  97 | +: [Component] The version of Script used in a leaf script. At the time of writing, only Tapscript is defined.

vostrnad commented at 10:24 PM on June 9, 2026:

It wouldn't hurt to mention that the leaf version is a part of the control block.

murchandamus commented at 7:50 PM on June 10, 2026:

Added!

in bip-tx-terminology.mediawiki:99 in 5491adc896

  94 | +: [Component] A condition script used for spending P2TR outputs via the scriptpath. The leaf script appears as a witness item.
  95 | +
  96 | +; leaf version
  97 | +: [Component] The version of Script used in a leaf script. At the time of writing, only Tapscript is defined.
  98 | +
  99 | +; lock time

vostrnad commented at 10:24 PM on June 9, 2026:

I'm surprised to see "lock time" as two words (I was of the impression that you much prefer compound words), I can't recall ever seeing it spelled out that way. For example, in the BIPs repo itself "locktime" is much more common.

murchandamus commented at 7:52 PM on June 10, 2026:

Replaced with locktime throughout the document.

in bip-tx-terminology.mediawiki:122 in 5491adc896

 117 | +; output index
 118 | +: [Component] Part of an outpoint. The position of the output in a transaction’s output list that created the identified TXO.
 119 | +: Synonym: <code>vout_index</code>, sometimes abbreviated as <code>vout</code>
 120 | +
 121 | +; output script
 122 | +: [Component] Must be present in each transaction output. Contains either a condition script or a forwarding script. Originally, the Bitcoin code base used Hungarian notation. This field was presumably named <code>scriptPubKey</code> as it was of the type script and because it fulfilled the role of a public key. While the first standard output type, Pay to Public Key, only contained the public key in this field, the use of this field had evolved beyond that even when Bitcoin was published, since the field could already contain more complicated bare scripts. Today, this field is referred to as the output script.

vostrnad commented at 10:25 PM on June 9, 2026:

"Must be present in each transaction output" or similar applies to a good portion of these terms, so it seems a bit out of place here (not even the input script description has this).

murchandamus commented at 7:53 PM on June 10, 2026:

Fair! Removed.

in bip-tx-terminology.mediawiki:129 in 5491adc896

 124 | +
 125 | +; P2SH program
 126 | +: [Concept] A script template that forwards input validation to the redeem script. P2SH programs are a type of forwarding script.
 127 | +
 128 | +; redeem script
 129 | +: [Component] The condition script used in spending P2SH outputs. Is provided in the input script along with script arguments to satisfy it. The input script of wrapped segwit inputs is not a redeem script but a witness program.

vostrnad commented at 10:25 PM on June 9, 2026:

"The input script of wrapped segwit inputs is not a redeem script [...]" – well duh, no input script is a redeem script, an input script may contain a redeem script as its last script push.

murchandamus commented at 8:11 PM on June 10, 2026:

I rewrote this definition. What do you think about the following?

: [Component] The condition script used in spending P2SH outputs. The redeem script appears as the last push in the input script, usually preceded by script arguments to satisfy the redeem script. In the case of wrapped segwit inputs, the input script consists only of the redeem script which contains a witness program forwarding evaluation to the witness stack.

vostrnad commented at 7:23 AM on June 11, 2026:

It's great, I've nothing more to add.

in bip-tx-terminology.mediawiki:133 in 5491adc896

 128 | +; redeem script
 129 | +: [Component] The condition script used in spending P2SH outputs. Is provided in the input script along with script arguments to satisfy it. The input script of wrapped segwit inputs is not a redeem script but a witness program.
 130 | +: Synonyms: <code>redeemScript</code>, redemption script
 131 | +
 132 | +; Script
 133 | +: [Concept] The original variant of the Bitcoin Script language used in bare output scripts, P2SH redeems scripts, and P2WSH witness scripts. Signature processing opcodes in Script expect DER-encoded ECDSA signatures. Capitalized Script refers to the language, whereas lowercase script refers to a script.

vostrnad commented at 10:26 PM on June 9, 2026:

I don't think it's correct to call it "Script" only when it's used in pre-Taproot inputs. Tapscript is just a variant of Script.

murchandamus commented at 8:21 PM on June 10, 2026:

In my eyes, Tapscript is a closely-related different language, e.g., markedly so by using different signatures schemes, using different sets of opcodes, and handling disabled and undefined opcodes differently. If someone explicitly referred to Script, I would expect them to mean only legacy script. I don’t understand which action you propose here, if you have ideas how to improve this, please let me know.

vostrnad commented at 4:11 PM on June 12, 2026:

I doubt there are many contexts in which you'd actually read "Script" as meaning "legacy Script". Just a few not even that contrived examples:

"Bitcoin Core has a Script interpreter"
"OP_NOP is a Script opcode"
"you can't do loops or recursion in Script"
"a script is a program written in Script"

My recommendation is to have "Script" refer to the language as a whole, and use "legacy Script" and "Tapscript" when needing to specify the variant. Case in point, you're already doing this: in the definition for "signature" you used "legacy Script" instead of "Script".

in bip-tx-terminology.mediawiki:136 in 5491adc896

 131 | +
 132 | +; Script
 133 | +: [Concept] The original variant of the Bitcoin Script language used in bare output scripts, P2SH redeems scripts, and P2WSH witness scripts. Signature processing opcodes in Script expect DER-encoded ECDSA signatures. Capitalized Script refers to the language, whereas lowercase script refers to a script.
 134 | +
 135 | +; script arguments
 136 | +: [Concept] Arguments presented to satisfy a condition script, e.g. signatures and public keys.

vostrnad commented at 10:27 PM on June 9, 2026:

This should have "initial stack" as a synonym, no?

murchandamus commented at 8:42 PM on June 10, 2026:

I think an argument can be made that the initial stack is formed from the script arguments for P2SH, while the script arguments are the initial stack for segwit outputs. I don’t think synonym is quite right, but I added some explanation about this relationship.

in bip-tx-terminology.mediawiki:151 in 5491adc896 outdated

 146 | +
 147 | +; <code>scriptSig</code>
 148 | +: See '''input script'''.
 149 | +
 150 | +; sequence
 151 | +: [Component] The sequence number appearing in each transaction input. Serialized as the four-byte <code>nSequence</code> integer field. If any input’s sequence number is less than the maximum allowed value, a transaction is non-final.

vostrnad commented at 10:27 PM on June 9, 2026:

I like that this mentions that sequences are four-byte integers. A lot of the other fields don't mention the serialization format (e.g. input/output index, outpoint index, amount etc.).

murchandamus commented at 10:48 PM on June 10, 2026:

I realize that I did this for marker, sequence, version, locktime, and sighash-flag. It feels a bit out-of-place in a list of definitions, so I was considering to remove it, but would you think that it should also be added to other components instead?

vostrnad commented at 4:11 PM on June 12, 2026:

Personally I think including the serialization format in the definition is helpful, and you even included a definition for CompactSize so you might as well refer to it in other definitions. But I'm okay with either solution.

in bip-tx-terminology.mediawiki:154 in 5491adc896

 149 | +
 150 | +; sequence
 151 | +: [Component] The sequence number appearing in each transaction input. Serialized as the four-byte <code>nSequence</code> integer field. If any input’s sequence number is less than the maximum allowed value, a transaction is non-final.
 152 | +
 153 | +; signature
 154 | +: [Component] A script argument that proves a key owner’s consent to a transaction. Composed of an r-value, an s-value, and a sighash flag. ECDSA and Schnorr signatures use different serialization schemes for signatures. The length indicator preceding the signature is a serialization artifact that is not part of the signature. If the default signature hash type <code>SIGHASH_ALL</code> is used, the sighash flag may be omitted for Schnorr signatures.

vostrnad commented at 10:27 PM on June 9, 2026:

When the sighash flag is omitted for Schnorr signatures, it's no longer SIGHASH_ALL but SIGHASH_DEFAULT. The distinction is somewhat important.

murchandamus commented at 8:46 PM on June 10, 2026:

Thanks, good correction!

in bip-tx-terminology.mediawiki:187 in 5491adc896

 182 | +; transaction input list
 183 | +: [Concept] The enumeration of all transaction inputs of a transaction.
 184 | +: Synonym: inputs, <code>vin</code>, <code>txins</code>, <code>tx_ins</code>
 185 | +
 186 | +; transaction output (TXO)
 187 | +: [Component] A transaction component that consists of an amount and an output script. Adds a new unspent transaction output (UTXO) to the UTXO set that is uniquely identified by an outpoint.

vostrnad commented at 10:29 PM on June 9, 2026:

Well, usually uniquely 😄

murchandamus commented at 8:43 PM on June 10, 2026:

Adding a footnote to point out that we have been disabused of that notion TWICE!

in bip-tx-terminology.mediawiki:195 in 5491adc896

 190 | +; transaction output list
 191 | +: [Concept] The enumeration of all transaction outputs of a transaction.
 192 | +: Synonym: outputs, <code>vout</code>, <code>txouts</code>, <code>tx_outs</code>
 193 | +
 194 | +; unspent transaction output (UTXO)
 195 | +: [Concept] An entry in Bitcoin’s ledger of spendable funds, the UTXO set. UTXOs get created by transaction outputs and spent by transaction inputs. UTXOs are uniquely identified<ref>There have been two instances in which UTXOs with existing outpoints were recreated, see [[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP30]]</ref> by an outpoint. The UTXO model with its uniquely-identifiable discrete portions of funds is instrumental to Bitcoin’s solution of the doublespend problem.

vostrnad commented at 10:29 PM on June 9, 2026:

This seems to be the most common name of the problem in question: (used e.g. in the white paper)

: [Concept] An entry in Bitcoin’s ledger of spendable funds, the UTXO set. UTXOs get created by transaction outputs and spent by transaction inputs. UTXOs are uniquely identified<ref>There have been two instances in which UTXOs with existing outpoints were recreated, see [[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP30]]</ref> by an outpoint. The UTXO model with its uniquely-identifiable discrete portions of funds is instrumental to Bitcoin’s solution of the double-spending problem.

murchandamus commented at 8:52 PM on June 10, 2026:

Taken

in bip-tx-terminology.mediawiki:196 in 5491adc896 outdated

 191 | +: [Concept] The enumeration of all transaction outputs of a transaction.
 192 | +: Synonym: outputs, <code>vout</code>, <code>txouts</code>, <code>tx_outs</code>
 193 | +
 194 | +; unspent transaction output (UTXO)
 195 | +: [Concept] An entry in Bitcoin’s ledger of spendable funds, the UTXO set. UTXOs get created by transaction outputs and spent by transaction inputs. UTXOs are uniquely identified<ref>There have been two instances in which UTXOs with existing outpoints were recreated, see [[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP30]]</ref> by an outpoint. The UTXO model with its uniquely-identifiable discrete portions of funds is instrumental to Bitcoin’s solution of the doublespend problem.
 196 | +: Synonym: coin (whitepaper)

vostrnad commented at 10:29 PM on June 9, 2026:

Not just the white paper, for example the Bitcoin Core coinbase uses this a lot. I'd drop the parentheses.

in bip-tx-terminology.mediawiki:203 in 5491adc896

 198 | +; version
 199 | +: [Component] Part of the transaction header that specifies the transaction version. Serializes as the four-byte <code>nVersion</code> integer field.
 200 | +: Synonym: <code>nVersion</code>
 201 | +
 202 | +; witness item
 203 | +: [Component] An element of a witness stack. Witness items are: witness script (P2WSH only), script arguments, leaf script (P2TR scriptpath only), control block (P2TR scriptpath only), annex (P2TR only).

vostrnad commented at 10:29 PM on June 9, 2026:

The enumeration could use a "at the time of writing" disclaimer.

murchandamus commented at 8:53 PM on June 10, 2026:

Good point, taken!

in bip-tx-terminology.mediawiki:217 in 5491adc896

 212 | +
 213 | +; witness script
 214 | +: [Component] A witness item that provides the condition script used to spend P2WSH outputs. Appears in the witness stack.
 215 | +
 216 | +; witness stack
 217 | +: [Component] The pre-built stack of witness items that is consumed in validation of the input’s condition script. Witness stacks are not scripts, but may include witness items that are scripts. While there is a witness stack for each input, the witness stack is not part of the input. A witness stack can contain witness items that will not be added to the stack, such as the control block. The witness stack may contain condition scripts, specifically it will contain a witness script for P2WSH inputs, and a leaf script for a P2TR scriptpath spend. Every transaction input is accompanied by a witness stack, but the witness stack of non-segwit inputs is empty, i.e. consists just of the serialization artifact of a witness item count of 0.

vostrnad commented at 10:29 PM on June 9, 2026:

"Every transaction input is accompanied by a witness stack" – but only in a transaction that spends at least one segwit input.

murchandamus commented at 10:40 PM on June 10, 2026:

I added "If a transaction does not have any segwit inputs, witness data is omitted from the transaction serialization."

Fix compactsize link be997fe9aa

Split keypath and scriptpath to two words a5d8bbb5a2

Address vostrnad Review 1f9b42b538

murchandamus commented at 10:52 PM on June 10, 2026: member

@vostrnad: Thank you for the great review. I took most of your suggestions, I’m still working on the Condition Script and Forwarding Script point.

Use shorter lines outside of lists 99a59aa3bc

jonatack added the label Needs number assignment on Jun 11, 2026

in bip-tx-terminology.mediawiki:22 in 99a59aa3bc

  17 | +This document describes terminology for referring to scripts, transaction parts, and serialization
  18 | +artifacts in the context of transactions.
  19 | +
  20 | +===Copyright===
  21 | +
  22 | +This document is licensed under the 3-clause BSD license.

jonatack commented at 1:45 PM on June 11, 2026:

style nit, feel free to ignore, as the same info is stated in the header only 14 lines earlier, maybe this section can be moved toward the end of the document.

murchandamus commented at 5:33 PM on June 11, 2026:

Moved to the bottom.

jonatack commented at 1:47 PM on June 11, 2026: member

At first glance looks complete and ready for assignment.

Fix grammar error in article 4c5d7305e0

Amend UTXO synonyms 03b513ce00

in bip-tx-terminology.mediawiki:54 in 99a59aa3bc

  49 | +transactions (labeled [Concept]).
  50 | +
  51 | +===Reader Guidance===
  52 | +
  53 | +* If the distinction between components and serialization artifacts is not readily clear, perusing the below example of a [[#example-anatomy-of-a-serialized-transaction|transaction’s anatomy]] may help foster an intuitive sense.
  54 | +* An visual overview of how different output types make use of the different components can be found in the table [[#usage-in-context-of-txo-creation-and-spending|"Usage in context of TXO creation and spending"]].

jonatack commented at 1:48 PM on June 11, 2026:

* A visual overview of how different output types make use of the different components can be found in the table [[#usage-in-context-of-txo-creation-and-spending|"Usage in context of TXO creation and spending"]].

in bip-tx-terminology.mediawiki:321 in 03b513ce00

 316 | +
 317 | +; Amount vs Value
 318 | +: Amount underscores that we are referring to a count of satoshis rather than subjective value. As Bitcoin transactions (and code altogether) are littered with “values”, we prefer “amount” as being less ambiguous.
 319 | +
 320 | +; <span id="compactsize"></span><code>CompactSize</code> vs <code>VarInt</code>
 321 | +: The Bitcoin Core codebase uses the term <code>CompactSize</code> for a “variable-length integer encoding used in Bitcoin Core’s serialization framework” that has outside of Bitcoin Core also been referred to as <code>VarInt</code><ref>Also see Bitcoin Stack Exchange: [[What is the different between CompactSize and VarInt encoding?|https://bitcoin.stackexchange.com/a/114585/5406]]. Since the Bitcoin Core codebase uses another type of variable-length integer encoding called <code>VarInt</code> in the context of database interaction, we prefer using <code>CompactSize</code> in the context of transaction serialization. This approach is also preferred by some technical writers working on widely read technical resources concerned with Bitcoin.

danielabrozzoni commented at 9:32 AM on June 12, 2026:

In the Bitcoin Stack Exchange url: in mediawiki format, the URL should go first, and the displayed text as second; here they're backwards:

Should be:

[[https://bitcoin.stackexchange.com/a/114585/5406|What is the different between CompactSize and VarInt encoding?]]

in bip-tx-terminology.mediawiki:207 in 03b513ce00

 202 | +; unspent transaction output (UTXO)
 203 | +: [Concept] An entry in Bitcoin’s ledger of spendable funds, the UTXO set. UTXOs get created by transaction outputs and spent by transaction inputs. UTXOs are uniquely identified<ref>There have been two instances in which UTXOs with existing outpoints were recreated, see [[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP30]]</ref> by an outpoint. The UTXO model with its uniquely-identifiable discrete portions of funds is instrumental to Bitcoin’s solution of the double-spending problem.
 204 | +: Synonym: coin
 205 | +
 206 | +; version
 207 | +: [Component] Part of the transaction header that specifies the transaction version. Serializes as the four-byte <code>nVersion</code> integer field.

danielabrozzoni commented at 9:55 AM on June 12, 2026:

What if here we added links to the various BIPs specifying tx versions? BIP68 for version 2 and BIP431 for version 3

in bip-tx-terminology.mediawiki:195 in 03b513ce00

 190 | +; transaction input list
 191 | +: [Concept] The enumeration of all transaction inputs of a transaction.
 192 | +: Synonym: inputs, <code>vin</code>, <code>txins</code>, <code>tx_ins</code>
 193 | +
 194 | +; transaction output (TXO)
 195 | +: [Component] A transaction component that consists of an amount and an output script. Adds a new unspent transaction output (UTXO) to the UTXO set that is uniquely<ref>Well… usually uniquely. There have been two transactions that were repeated which created duplicate UTXOs (see BIP30).</ref> identified by an outpoint.

danielabrozzoni commented at 10:10 AM on June 12, 2026:

Should link to BIP30:

duplicate UTXOs (see [[https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki|BIP30]])

danielabrozzoni commented at 10:15 AM on June 12, 2026: member

I only did a first (rather quick) pass. Thanks for taking the time to write this! It was very informational, and helped me clear many of the doubts I had regarding terminology :)