BIP draft: Terminology for transaction components and aspects

[murchandamus]

This document proposed a set of terminology to refer to various aspects and components of transactions.

TODOs:

• distinguish “transaction field” vs “transaction component”
• what is the correct label for the Witness Structure? Should it rather be a [TC] than an [AT]?
• Make a graphic that shows the relationship of forwarding scripts and condition scripts
• varInt vs compactSize
• add glossary entry for varInt
• list all popular aliases for terms
• vostrnad: How is the tweaked public key considered a condition script? Isn't it instead a (part of a) witness program?
• karask: If a Witness Stack contains items that will not be added to the stack, why not called it just 'Witness' ? 'Witness' is also the same as the field, like scriptSig is. | vostrnad: "Witness" or "witness structure" already has a defined meaning: "The part of the serialized transaction that contains the witness stacks for each input."
• karask: “(un)locking script widely used for scriptSig/scriptPubKey”
• collate with BIP141
• collate with BIP144
• collate with BIP341
• script arguments in P2SH doesn’t make sense
• ScriptCode
• prevout as synonym for outpoint

[LarryRuane]

To be continued..

[satsie]

Nicely done! I think it is tremendously helpful to have a single source of truth for this stuff, especially as things have evolved over time and some terms in BIP-144 aren't as concise as they could be, and we have new fields for taproot transactions.

I left comments on parts of this document that I felt were especially useful to have explained. I didn't go through the glossary with a fine toothed comb, but left notes on suggestions/questions that immediately jumped out at me. After a first pass, I think I mostly understand all the terms, but I'll be the first to admit I know next to nothing about P2TR, so cannot be of much help in reviewing those sections.

Do you plan on adding some diagrams to this? Here is one I had to draw out and continued to reference as I made my way through the draft:

As I look at it now, I'm a little confused by redeem script and bare output script being ATs and not TCs. My brain wants all little blue blocks on the bottom row to be TCs.

Right now I don't think the motivation section does enough justice to the rest of the document, especially considering conversations we've had on the general confusion around some of these terms. I'm a little afraid to dig up my old notes on this stuff because even my attempts to tease apart some of these terms confused me! At the moment, I don't have any concrete suggestions on ways to enrich this section other than anecdotal examples (i.e. "people often use locking script, output script, and redeem script interchangeably"). But I will come back if I think of ideas.

Overall I think this is a really good idea, and certainly not a small task! Excited for this draft to continue to evolve!

[murchandamus]

The graphic is an excellent idea. I’ll incorporate that soon. Gotta run in a minute, will just push the quick fixes meanwhile.

[LLFourn]

Concept ACK.

Nit: document uses the term "UTXO" without defining it. Would love if you could normalize the usage of the term TXO (a transaction output that may be spent or not) with this document as people sometimes complain when I use it (and prefer the term txout).

[karask]

First of all, great initiative and great job explaining the terminology. I only have a couple of related suggestions. Rather than commenting in several places I would argue for a couple of changes here, in one place.

I would suggest that Locking Script and Unlocking Script are also mentioned 'aka' to Output Script and Input Script respectively.

I found that a lot of people have been using them this way and I have adopted it with success, i.e. people understood much easier what was the purpose of the script. I also I have never seen condition script and script arguments to be associated with locking and unlocking script respectively, but maybe I just never happened to come by those!

Rationale
I agree with emphasizing the position of the field. Output Script (as well as Input Script) should be the main entry.

However, an output script is what effectively locks the funds and I argue that it always has this function. e.g. P2SH locks the funds to an unknown script that will be revealed later (similarly for taproot alternative paths/scripts).

Similarly an input script is always what unlocks the funds. It includes everything required to unlock them (incl.any forwarding scripts, etc.).

Suggested changes:
Input Script entry: include "aka scriptSig or Unlocking Script"
Output Script entry: include "aka scriptPubKey or Locking Script".
Condition Script entry: just remove "aka locking script"
Script Arguments entry: just remove "aka Unlocking Script"
Rephrase (or maybe remove) this section.

Thanks again for your efforts.

[murchandamus]

Hi @karask, thanks for your comment. I should clarify that condition script and script arguments are newly introduced terms per this proposal specifically to decouple the position of the input script and output script from the function of locking and unlocking, and to underscore the evolution of output types from executable scripts to templates with additional meaning.

As output types have evolved over the years, we have departed from them relying on fully specified executable scripts, but rather imbued certain templates with additional constraints. For example a P2SH program as written only checks that the redeem script revealed in the input script matches the pre-image in the output script, but the implied meaning of the P2SH program additionally requires the redeem script to be evaluated satisfactorily. Later with wrapped P2WSH, we didn’t even require the witness script to contain all the arguments with push operations directly in the script but rather provide them as separate items akin to a pre-built stack. These stand-alone witness items is what I refer to as script arguments. With native segwit outputs finally, the input script is empty altogether, and it would feel weird to me to refer to still refer to it as “unlocking script” when it holds no sway in the authorization of spending a UTXO at all anymore.

I think I’ve identified a few points that I need to rework, and I will look to incorporate my explanation into the rationale as well as the descriptions of input script and output script. I’ll think about how to best mention “locking script” and “unlocking script”. I’ll also try to rework my description of forwarding scripts to honor their function in committing the spender to the condition script even when they no longer directly express the spending conditions.

[satsie]

Murch - Are Forwarding Scripts (Witness Programs and P2SH Programs) not considered to be locking scripts?

Is that why "locking script" is specifically associated with Condition Scripts and not general Output Scripts, as karask suggests?

I ask because I agree with the first two suggestions of this comment, but also am worried taking that position is reinforcing confusion of the terms "locking script" and "unlocking script". I second karask's point that locking script and unlocking script are comparatively easier to understand, and I feel like they have seen a lot of success. Maybe because they naturally invoke an image of a lock and key.

They definitely should be incorporated in this BIP, as you have done, though the devil is in the details of how they should be defined/represented. I think what I'm trying to say is the terms locking/unlocking script will likely be easy and accessible entry points for people trying to understand this doc and level up their transaction terminology so care must be taken in how they are represented! 😄

[satsie]

I just realized while I was typing my comment I missed your response. Please disregard if I've said anything that has already been answered 🙈

[murchandamus]

That’s actually a good point. Perhaps “forwarding scripts” and “condition scripts” are both subtypes of “locking scripts”.

[murchandamus]

Added as a todo to elaborate on

[karask]

@LLFourn:

Nit: document uses the term "UTXO" without defining it. Would love if you could normalize the usage of the term TXO (a transaction output that may be spent or not) with this document as people sometimes complain when I use it (and prefer the term txout).

Defined the term UTXO and replaced multiple uses of UTXO with “TXO”.

@vostrnad, @karask, @satsie: Addressed most open feedback.

I’m in the process of lowercasing and italicizing all defined terms, see first few in last commit, will continue in that style.

Hi @xekyo
I don't see my locking/unlocking concerns be addressed (with changes or counter-explanations). Not sure if you are still contemplating on this but I wanted to raise it again now (or else I will probably forget! :-) It might seem pedantic but I think it is important.

Locking and unlocking scripts already have a high-level semantic meaning. Indeed, I don't believe they are mentioned anywhere in BIPs. If this BIP did not mention locking and unlocking scripts I would not raise it as an issue, esp. given that the terminology is targeted more towards BIP/technical writing.

I have already mentioned how it has been used until now and if we mention it in this BIP it should be aligned. My concern is that associating them with "extra"/specific meaning (condition script/script arguments) is going to further confuse.

[murchandamus]

Hi @karask, I added it as a todo in the opening comment, I am currently reworking the capitalization and formatting issues, while I mull over how I want to incorporate aliases better.

Do you happen to know some examples for resources that use the terminology of “locking script” and “unlocking script”? I think it might be used in Mastering Bitcoin, but I don’t know other cases.

[karask]

Mastering Bitcoin is the main resource I had in mind as well; it has proliferated from there to several blogs and other posts though.

[murchandamus]

@karask: I now mention “locking script” as a synonym of output script, and “unlocking script” as synonym for input script. I also rewrote the rationale sections regarding them. They could probably still use some polish, but I’m starting to suffer from tunnel vision—I think I’ve rewritten it four times meanwhile. 😬

I could use a set of fresh eyes to tell me whether it makes any sense, if you have a moment to glance at those definitions and rationales specifically. :)

[murchandamus]

I'd like to propose pubkey-script and sig-script as names when written in English.

That said, I think one advantage of spk/ss is that it's already been widely used and is very easily searchable by anyone wanting to learn more. Input/output script has also been widely used, although it's harder to search (having uses outside of Bitcoin). Whether (pubkey|sig)-script or (key|sig)script, those are new terms with no history and an uncertain future for whether anyone will adopt them.

Thanks, @harding and @tcharding. I prefer using existing terms with input script and output script over introducing new terms altogether.

[murchandamus]

It may be worth adding a section about the coinbase transaction and its various special rules. Once source of confusion for me is that too many things are called "commitment", see e.g. https://github.com/Sjors/sv2-tp/pull/10#issuecomment-3242942698

I added a definition for the coinbase field, but I don’t think the rules for coinbase transactions are on-topic here as this document deals with terminology, not consensus rules.

@Sjors: I’m not sure I follow your comment on "commitment". The link doesn’t work for me.

[murchandamus]

This is also not including block components. Is that explicitly out of scope? Might be nice to have that also covered.

@Kixunil: I think getting into block components would significantly increase the scope of this document, so I would at least at this stage of the proposal like to avoid it.

[murchandamus]

I noticed that both 'witness structure' and 'witness stack' have 'witness' as a synonym.

I added an explanation to the "witness" synonyms on both to clarify that it’s confusingly used for either.

[murchandamus]

Alright. I think I addressed most if not all of the comments that were still open on this. If any of you want to take another look, I will be opening a PR against the main BIPs repository shortly and would appreciate further review to be directed there.

Thank you all for your time and input!

[murchandamus]

The PR against the BIPs repository be found here: bitcoin#2195

[Sjors]

The link doesn’t work for me.

The repo moved: stratum-mining/sv2-tp#10 (comment)

I added a definition for the coinbase field

Thanks, that looks good in the current draft.

I don’t think the rules for coinbase transactions are on-topic here as this document deals with terminology, not consensus rules.

The witness of the coinbase transaction is special in the same sense that the coinbase field is (albeit with different rules, e.g. BIP34 vs. BIP141). So I think it deserves a name, but I agree we don't need to spell out the rules (though you could link to the SegWit BIP).

[murchandamus]

Oh, I see. I’ll add the “Witness Reserved Value” as it is referred to by BIP141 to the list of definitions!