Skip to content

BIP Draft: Terminology of Transaction Components#2195

Open
murchandamus wants to merge 7 commits into
bitcoin:masterfrom
murchandamus:2022-04-tx-terms
Open

BIP Draft: Terminology of Transaction Components#2195
murchandamus wants to merge 7 commits into
bitcoin:masterfrom
murchandamus:2022-04-tx-terms

Conversation

@murchandamus

@murchandamus murchandamus commented Jun 9, 2026

Copy link
Copy Markdown
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:

Comment thread bip-tx-terminology.mediawiki
Comment thread bip-tx-terminology.mediawiki
Comment thread bip-tx-terminology.mediawiki Outdated
: Synonym: <code>VarInt</code> (do not use, see [[compactsize|Rationale]])

; condition script
: [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).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread bip-tx-terminology.mediawiki Outdated
: [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]]).

; forwarding script
: [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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated

@murchandamus murchandamus left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated
: See '''input script'''.

; sequence
: [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.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@jonatack jonatack left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At first glance looks complete and ready for assignment.

Comment thread bip-tx-terminology.mediawiki Outdated
Comment thread bip-tx-terminology.mediawiki Outdated

@danielabrozzoni danielabrozzoni left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

: 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.

; <span id="compactsize"></span><code>CompactSize</code> vs <code>VarInt</code>
: 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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Image

Should be:

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

: Synonym: coin

; version
: [Component] Part of the transaction header that specifies the transaction version. Serializes as the four-byte <code>nVersion</code> integer field.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

: Synonym: inputs, <code>vin</code>, <code>txins</code>, <code>tx_ins</code>

; transaction output (TXO)
: [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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should link to BIP30:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants