BIP453: Terminology of Transaction Components#2195
Open
murchandamus wants to merge 10 commits into
Open
Conversation
15 tasks
murchandamus
force-pushed
the
2022-04-tx-terms
branch
from
bbb3268 to
5491adc
Compare
Sjors
reviewed
Jun 9, 2026
murchandamus
commented
Jun 9, 2026
vostrnad
reviewed
Jun 9, 2026
| : 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). |
Contributor
There was a problem hiding this comment.
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.
| : [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. |
Contributor
There was a problem hiding this comment.
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
commented
Jun 10, 2026
murchandamus
left a comment
murchandamus
left a comment
Member
Author
There was a problem hiding this comment.
@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.
| : 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. |
Member
Author
There was a problem hiding this comment.
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
reviewed
Jun 11, 2026
jonatack
reviewed
Jun 11, 2026
danielabrozzoni
left a comment
danielabrozzoni
left a comment
Member
There was a problem hiding this comment.
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
reviewed
Jun 20, 2026
Member
|
Assigned 453 |
murchandamus
changed the title
Member
Author
|
Thanks. I adopted the assigned number and @danielabrozzoni’s review. Other todos remain open. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: