BIP453: Terminology of Transaction Components by murchandamus · Pull Request #2195 · bitcoin/bips

murchandamus · 2026-06-09T01:00:34Z

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 BIP453: Terminology of Transaction Components #2195 (comment), vostrnad)
Inconsistency of use of Forwarding Script (see BIP453: Terminology of Transaction Components #2195 (comment)), vostrnad)

vostrnad · 2026-06-09T22:24:10Z

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


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.

vostrnad · 2026-06-09T22:24:29Z

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


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.

murchandamus

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

murchandamus · 2026-06-10T22:48:34Z

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


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

At first glance looks complete and ready for assignment.

danielabrozzoni

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

jonatack · 2026-06-20T12:47:05Z

Assigned 453

murchandamus · 2026-06-24T20:17:52Z

Thanks. I adopted the assigned number and @danielabrozzoni’s review. Other todos remain open.

danielabrozzoni

Thanks for picking up my comments! I gave this another read :)

danielabrozzoni · 2026-07-01T12:29:18Z

+; annex
+: [Component] A witness item reserved for future extensions, currently unused (see [[bip-0341.mediawiki#cite_note-5|BIP341]]).
+
+; bare output script


It took me a second to understand what exactly is a bare output - I think it's clear once you already understand condition and forwarding scripts, but it took me a few re-reads to appreciate this fully. I wonder if it would help to add a short note saying why the other script types are not bare.

Otherwise, it might be helpful to explicitly mention the lack of a forwarding script. That is already implied by "a condition script that is directly defined in the output script field" but repeating it could make the distinction easier to pick up on first read.

danielabrozzoni · 2026-07-01T13:16:32Z

+: Synonym: coin
+
+; version
+: [Component] Part of the transaction header that specifies the transaction version. Serializes as the four-byte <code>nVersion</code> integer field. `OP_CHECKSEQUENCEVERIFY` requires version 2 or higher (see [[bip-0068.mediawiki|BIP68]]), version 3 transactions are topologically restricted until confirmation (see [[bip-0431.mediawiki|BIP431]]).


OP_CHECKSEQUENCEVERIFY should be enclosed in "<code></code>", not in "``"

danielabrozzoni · 2026-07-01T13:17:10Z

+
+; witness item
+: [Component] An element of a witness stack. At the time of writing, witness items are: witness script (P2WSH only), script arguments, leaf script (P2TR script path only), control block (P2TR script path only), annex (P2TR only).
+: Synonyms: witness element, witness stack element ([bip-0341.mediawiki|BIP341]])


Missing one "[" at the start of bip-0341, should be: ([[bip-0341.mediawiki|BIP341]])

danielabrozzoni · 2026-07-01T21:22:36Z

+
+; input script
+: [Component] The Bitcoin code base used Hungarian notation when it was published. This transaction field appearing in transaction inputs was named <code>scripSig</code> 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.
+: Synonyms: <code>scriptSig</code>, unlocking script (see [[locking_unlocking|Rationale]])


Missing "#" in front of locking_unlocking, should be: [[#locking_unlocking|Rationale]]

danielabrozzoni · 2026-07-01T21:27:15Z

+
+; output script
+: [Component] 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.
+:  Synonyms: <code>scriptPubKey</code>, locking script (see [[locking_unlocking|Rationale]])


Same as above, needs a "#": [[#locking_unlocking|Rationale]]

purpleKarrot

I think establishing consistent terminology is overdue. Some comments inline.

purpleKarrot · 2026-08-10T08:06:00Z

+of transactions and functions that scripts fulfill in transactions includes a broad spectrum of
+competing jargon. In this document, we describe a set of terms that can be used to refer to
+transaction components by their function or their context. The terms are not entirely consistent in
+themselves since many are already firmly established. Instead of striving for consistency, we try to


The terms are not entirely consistent in themselves since many are already firmly established. Instead of striving for consistency, ...

Are we still early or is it too late? If we look back, we may find that certain terms have been established and we may want to keep them. But it we look forward and ask ourselves what would be more beneficial for generations to come, then we may realize that it is establishing a consistent vocabulary soon.

In 100 years, would people care that some entity changed its term 100 years prior?

purpleKarrot · 2026-08-10T08:13:33Z

+transaction components by their function or their context. The terms are not entirely consistent in
+themselves since many are already firmly established. Instead of striving for consistency, we try to
+relate terms to each other, explore the origins of terms, and fill in the blanks. The hope is that
+this terminology could be used in technical writing about Bitcoin as well as future BIPs.


Instead of hoping, why not make it a recommendation? Something like:

The goal of this BIP is to establish a terminology for technical writing such as documentation and future BIPs. Referring to concrete symbol names of one particular code base should be discouraged for the sake of keeping BIPs implementer-neutral.

purpleKarrot · 2026-08-10T08:15:55Z

+===Objects and their Serialization===
+
+We treat the objects of the Bitcoin protocol (e.g. transactions, blocks) as distinct from their
+serialization. We distinguish parts and concrete properties of transactions (labeled [Component])


In addition to keeping the objects distinct from their serialization, the specification of those objects should further be distinct from their concrete implementation.

purpleKarrot · 2026-08-10T08:24:12Z

+
+; locktime
+: [Component] Part of the transaction header. Locktime specifies a time (in blockheight or UNIX time) before which a transaction cannot be included in a block if any input’s sequence number indicates non-finality. The locktime can also indicate a relative spending lock in combination with <code>OP_CHECKSEQUENCEVERIFY</code>. Serialized as the four-byte <code>nLockTime</code> integer field.
+: Synonym: <code>nLockTime</code>, <code>lock_time</code>


I would not consider nLockTime and lock_time as synonymous for locktime. All three use a different coding style of one of the same term. The goal of this BIP should be to establish the terms while leaving the coding style to the implementers.

purpleKarrot · 2026-08-10T08:43:46Z

+==Rationale==
+
+; Amount vs Value
+: 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.


I would not frame amount and value as competing terms where one "wins" because the other is already loaded. The two terms operate at two different levels of abstractions. The distinction is between what something is and what role it plays in its containing object:

string is a type, name is a property.

outpoint is a type, prevout is a property.

amount is a type, value is a property.

There are cases where a property can use the name of a type (eg: the txid of an outpoint is a txid) but that is an exception to the rule, not the general case.

purpleKarrot · 2026-08-10T08:45:06Z

+
+; amount
+: [Component] The count of satoshis assigned to an output.
+: Synonym: <code>nValue</code>, value


This blurs two different levels of abstractions. See my comment on "Amount vs Value".

purpleKarrot · 2026-08-10T08:46:09Z

+
+; outpoint
+: [Component] Identifies the transaction output (TXO) being spent by a transaction input. Consists of a txid and output index. The txid is serialized in little-endian but displayed in big-endian.
+: Synonym: <code>prevout</code>


This blurs two different levels of abstractions. See my comment on "Amount vs Value".

purpleKarrot · 2026-08-10T08:58:54Z

+: [Component] Identifies the transaction that created a TXO in an outpoint. Result of hashing a transaction without its witness structure. The txid is serialized in little-endian but displayed in big-endian.
+
+; transaction input
+: [Component] An element of the transaction input list that consists of an outpoint, an input script, and a sequence. The outpoint identifies the TXO that is being spent. The input script can have various content depending on the type of output being spent. The input script has length 0 for native segwit inputs. In segwit transactions, every input must be accompanied by a witness stack. The witness stack is not part of the transaction input.


The witness stack is not part of the transaction input.

I'd say it is. See the rationale in std::bitcoin.

On the wire, the witness data is written after all outputs. Hence the term "segregated witness".

In the implementation, whether the witness stack is part of the input structure (as implemented in Bitcoin Core here) or whether it is held in a different structure and just referred to by input index (as implemented in Hornet here) should be considered an implementation detail.

But semantically, it is part of the input.

murchandamus added the New BIP label Jun 9, 2026

murchandamus mentioned this pull request Jun 9, 2026

BIP draft: Terminology for transaction components and aspects murchandamus/bips#1

Closed

15 tasks

Add transaction terminology bip

5491adc

murchandamus force-pushed the 2022-04-tx-terms branch from bbb3268 to 5491adc Compare June 9, 2026 01:19

Sjors reviewed Jun 9, 2026

View reviewed changes

Comment thread bip-0453.mediawiki

murchandamus commented Jun 9, 2026

View reviewed changes

Comment thread bip-0453.mediawiki

vostrnad reviewed Jun 9, 2026

View reviewed changes

murchandamus added 3 commits June 10, 2026 12:45

Fix compactsize link

be997fe

Split keypath and scriptpath to two words

a5d8bbb

Address vostrnad Review

1f9b42b

murchandamus commented Jun 10, 2026

View reviewed changes

Use shorter lines outside of lists

99a59aa

jonatack added the Needs number assignment label Jun 11, 2026

jonatack reviewed Jun 11, 2026

View reviewed changes

Comment thread bip-tx-terminology.mediawiki Outdated

jonatack reviewed Jun 11, 2026

View reviewed changes

Comment thread bip-tx-terminology.mediawiki Outdated

murchandamus added 2 commits June 11, 2026 10:33

Fix grammar error in article

4c5d730

Amend UTXO synonyms

03b513c

danielabrozzoni reviewed Jun 12, 2026

View reviewed changes

Comment thread bip-tx-terminology.mediawiki Outdated

Comment thread bip-tx-terminology.mediawiki Outdated

Comment thread bip-tx-terminology.mediawiki Outdated

jonatack reviewed Jun 20, 2026

View reviewed changes

Comment thread bip-tx-terminology.mediawiki Outdated

jonatack removed the Needs number assignment label Jun 20, 2026

murchandamus added 3 commits June 24, 2026 13:16

BIP453: Adopt assigned number

a0b3079

BIP453: Add references to BIPs using tx version

284bfbc

BIP453: Use page links across document

b0cb2f9

murchandamus changed the title ~~BIP Draft: Terminology of Transaction Components~~ BIP453: Terminology of Transaction Components Jun 24, 2026

danielabrozzoni reviewed Jul 1, 2026

View reviewed changes

purpleKarrot reviewed Aug 10, 2026

View reviewed changes

jonatack added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label Aug 10, 2026

Uh oh!

Conversation

murchandamus commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

murchandamus left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jonatack left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

danielabrozzoni left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jonatack commented Jun 20, 2026

Uh oh!

murchandamus commented Jun 24, 2026

Uh oh!

danielabrozzoni left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

purpleKarrot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

murchandamus commented Jun 9, 2026 •

edited

Loading

jonatack left a comment •

edited

Loading