Authorizing the transaction
Digital signatures are used to authorize transactions. Recall that a digsig is a public key technology that emulates a signature by producing publicly verifiable evidence of agreement by a party to a statement. A pair of keys is created, a public and a private which are matched through mathematics such at that a number created by the private key can be verified using the public key, and the only numbers that can be verified by the public key are numbers calculated by the private key.
Each TXO is paired with a public key. The meaning is that the holder of the matching private key is the owner of that TXO. Using a TXO as a TXI will require that the TXI carry a signature, by that public key, over a synopsis of the transaction in which the TXI appears. In this way, the owner of the output is agreeing to use that output as input to the transaction under consideration. For each TXI in the transaction, there must be a signature using the associated private key for that input. In this way, only if all owners of all inputs agree is the transaction valid.
The signatures are include in the transaction, paired with its TXI. In this way, all the information to verify a transaction is permanently available on the block chain. While the miners best not mine blocks which include transactions which are not properly signed, that is because the block will be rejected by all honest players, and will eventually not be included in the consensus chain. Not being on the consensus chain, the transaction will never have officially occurred, and coinbase and fees will not be usable by the cheating miner.
The public keys, when written in a proper format, are called Bitcoin addresses. In order to give you bitcoin, I suggest a transaction that has a TXO with the agreed bitcoin amount and your "address" paired with the TXO. Since this information is a member of a block, and the blockhash connects block to block, once on the consensus chain, the ownership of the bitcoin is permanent and publicly visible.
Blockchain scripting
The design of blockchain understood as typical the sort of signing described above, but did not want to limit transactions to be only according to that mechanism. To accommodate an unforeseen multitude of transaction types, Blockchain created a stack based computer language that would run scripts to carry out the transaction verification.
What is paired with the TXO is not so much a public key, but a ScriptPubKey, which is a script that will eventually test whether the request for spending will be honored. It typically includes the public key (address) of the TXO owner, to express in some manner that that owner must be involved in verifying the spending.
The TXI is paired with a ScriptSig, that in the typical case just self evaluates to the information needed by ScriptPubKey to perform the verification.
First ScriptSig runs, and leaves the public key and signature on a stack, as input for ScriptPubKey. Then ScriptPubKey runs, using the stack data to check that the public key on the stack is correct, and that the signature verifies. If all goes well, the pair of scripts have evaluated true and the transaction is valid.
The scripting language uses a stack, and has no branching or looping operations. Therefore the power of the language is limited. For instance, there is no uncertainty about the maximum run time for the script, since each step consumes a script item, and the run only proceeds from the start to the end of a fixed number of script items. A stack is used to organize the data.
What is signed?
The scripting operation has various modes to accommodate various transaction types. An example clarifies what sort of data is signed,
Segregated Witnesses (SegWit)
Segregated Witness (SegWit) is a protocol upgrade to Bitcoin designed to address structural limitations in transaction representation and scalability. It changes how data is accounted for inside a block by distinguishing between base transaction data and witness data (signatures), and by introducing a new notion of block capacity called block weight, rather than a simple byte-size limit. This effectively changes how block space is measured and used, allowing more transaction-related data to fit within the same consensus constraints without directly altering the original block size rule, a design choice that avoided a hard fork such as the one that led to Bitcoin Cash.
The change also addressed transaction malleability. In the pre-SegWit design of Bitcoin, transaction identifiers were computed from the full serialized transaction, including signature (witness) data. Because signatures can be encoded in multiple valid ways without changing their cryptographic meaning, different representations of the same valid transaction could produce different transaction identifiers (txids). This meant that a malleated variant could be introduced into the network, and while both versions were valid under consensus rules, only one could ultimately be confirmed in the blockchain, as they correspond to the same underlying transaction spending the same bitcoin output.
As a result, wallet software tracking transactions by txid could fail to recognize that a transaction had been confirmed if its identifier changed due to malleation, breaking transaction tracking and any higher-level protocols that depended on stable transaction references.
author: burton rosenberg
created: 4 Mar 2019
update: 23 Apr 2026