> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/transactions-and-utxos/bitcoin-transactions.md). # Bitcoin Transactions A Bitcoin **transaction** consists of a version number, a locktime value, a list of inputs and a list of outputs. The primary functionality of a Bitcoin transaction is to transfer custody of bitcoin from one to another. A Bitcoin transaction can also serve as a vehicle for smart contracts, recording data, attestation and many other secondary functionalities. A transaction can be created and iterated inside a Payment Channel using nLocktime and nSequence interlocks, or sent directly to The Bitcoin Network for inscription into a block. A transaction uses unspent transaction outputs (UTXOs) as inputs and distributes their value to new outputs. UTXOs are the 'coins' in which all bitcoins are stored. Transactions are not encrypted, so it is possible to browse and view every transaction ever collected into a block. Once transactions have been seen and validated by a majority of block creating nodes in the Bitcoin network, they can be considered settled. When they are eventually mined into a block, miners collaboratively agree on the order in which they were seen by the network. Transactions are referenced using their TXID which is a double SHA-256 hash of the fully serialised transaction. Transaction outputs are puzzle scripts called ScriptPubKeys which are typically used to lock the contained bitcoin value, sometimes also called locking script. Outputs are redeemed by making them inputs to new transactions and providing a ScriptSig (sometimes called unlocking script) which is a valid solution that unlocks the bitcoin held in the ScriptPubKey (locking script). Outputs may have zero value in bitcoin, but may carry value in another form such as data or tokens. Scripts can be complex and specialised and may have more than one way to be redeemed. All transactions are captured on the ledger in blocks on the blockchain, and can be viewed with a block explorer. This can be useful for seeing the technical details of transactions in action and for verifying payments. 1. General format of a Bitcoin transaction The following outlines the elements that are serialised to build a valid Bitcoin transaction. | Field | Description | Size | | --------------- | ----------------------------------------------- | ----------------------------------- | | Version no | currently 2 | 4 bytes | | In-counter | positive integer VI = VarInt | 1 - 9 bytes | | list of inputs | Input Structure | qty with variable length per input | | Out-counter | positive integer VI = VarInt | 1 - 9 bytes | | list of outputs | Output Structure | qty with variable length per output | | nLocktime | if non-zero and sequence numbers are 32 inputs. | | All of the new transaction's input value (that is, the total coin value of the previous outputs referenced by the new transaction's inputs) are added up, and the total (less any fees) is consumed by the outputs of the new transaction. **Previous tx** is the TXID of a previous transaction. **Index** is the specific output in the referenced transaction. **ScriptSig** is the first half of a script which is provided when a UTXO is spent as an input to a transaction. An input ScriptSig may contain many components. To redeem a P2PKH script the input must provide a public key and an ECDSA signature. The Public key is doubled hashed (First SHA-256 then RIPEMD-160) and the resultant hash must match the hash embedded in the ScriptPubKey of the output being redeemed. The public key is then used to verify the redeemer's signature. Dependent on the SIGHASH flags used, the signature may cover a hash representing part or all of the transaction. Combined with the public key, this proves the transaction was created by a person or process that controls the keys needed to spend the bitcoin in the input. 1. Format of a Transaction Input Otherwise known as a TXIN, the following table outlines the required elements of a valid transaction input. | Field | Description | Size | | ------------------------- | ------------------------------------------------------------------------------------------- | ----------- | | Previous Transaction hash | TXID of the transaction the output was created in | 32 bytes | | Previous Txout-index | Index of the output (Non negative integer) | 4 bytes | | Txin-script length | Non negative integer VI = VarInt | 1 - 9 bytes | | Txin-script / scriptSig | Script | -many bytes | | Sequence\_no | Used to iterate inputs inside a payment channel. Input is final when nSequence = 0xFFFFFFFF | 4 bytes | The input sufficiently describes where and how to get the bitcoin amount to be redeemed. If it is the (only) input of the first transaction of a block, it is called the Coinbase message and includes information about which block it was mined in and a miner configurable data element. 1. Outputs An **output** contains a piece of Bitcoin Script which can be used to lock bitcoins, requiring a certain set of keys or information to be provided to unlock them. Outputs can also be used to inscribe data onto the ledger. This **ScriptPubKey** is the second half of a full script and is only completed when the output is spent. There can be more than one output, and they share the combined value of the inputs. The **Value** of each output is the number of Satoshis that the script unlocks when solved. Because each output from one transaction can only ever be referenced once by an input of a subsequent transaction, the entire value of the combined inputs needs to be allocated to the transaction outputs. Any Satoshis left unallocated are considered to be paid in mining fees and are awarded to the miner whose node generates the block that the transaction is included in. If a user's input is larger than the value they want to send, the transaction must create at least two outputs, one sending the required funds to the destination, and one sending the change back to the user. Outputs can have a value of zero satoshis. Currently, these outputs are limited to False Return scripts and are typically used to carry other information or tokens for Application layer protocols. 2. Format of a Transaction Output Otherwise known as a TXOUT, the following table outlines the required elements of a valid transaction output. | Field | Description | Size | | --------------------------- | -------------------------------------------------------------------- | ----------------------- | | value | non negative integer giving the number of Satoshis to be transferred | 8 bytes | | Txout-script length | non negative integer | 1 - 9 bytes VI = VarInt | | Txout-script / scriptPubKey | Script | -many bytes | The output's scriptPubKey sets the conditions to release this bitcoin amount later. The sum of the output values of the first transaction is the value of the mined bitcoins for the block plus possible transactions fees of the other transactions in the block. 1. Transaction Validation To verify that inputs are authorized to collect the values of referenced outputs, Bitcoin uses a [Forth](https://en.wikipedia.org/wiki/Forth_\(programming_language\))-like scripting system. The input's scriptSig and the referenced output's scriptPubKey are evaluated (in that order), with scriptPubKey using the values left on the stack by the scriptSig. The input is authorized if scriptPubKey returns true. Through the scripting system, the sender can create very complex conditions that must be met in order to claim the output's value. For example, it's possible to create an output that can be claimed by anyone without any authorization. It's also possible to require that an input be signed by ten different keys or be redeemable with a password instead of a key. ## Puzzles and Solutions The flexible scripting language enabled by the Bitcoin protocol allows a multitude of different transaction types to be created. Each scriptSig/scriptPubKey pair is validated by the network miners and mined into a block if the script returns true. Some commonly used Bitcoin puzzle types are described below: 1. Pay to Public Key (P2PK) scriptPubKey: OP\_CHECKSIG scriptSig: When redeeming coins that have been sent to a Bitcoin public key the script validates that the provided signature was generated by the private key that also corresponds to the public key. Checking process: | Stack | Script | Description | | ------ | ------------ | ---------------------------------------- | | Empty. | OP\_CHECKSIG | scriptSig and scriptPubKey are combined. | | | OP\_CHECKSIG | Signature is added to the stack. | | | OP\_CHECKSIG | Pubkey is added to stack. | | true | Empty. | Signature is checked. | 1. Pay to Public Key Hash (P2PKH) scriptPubKey: OP\_DUP OP\_HASH160 OP\_EQUALVERIFY OP\_CHECKSIG scriptSig: A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key. The script verifies that the provided public key does hash to the hash in scriptPubKey, and then it also checks the signature against the public key. Checking process: | Stack | Script | Description | | ------ | ------------------------------------------------ | ---------------------------------------------------- | | Empty. | OP\_DUP OP\_HASH160 OP\_EQUALVERIFY OP\_CHECKSIG | scriptSig and scriptPubKey are combined. | | | OP\_DUP OP\_HASH160 OP\_EQUALVERIFY OP\_CHECKSIG | Constants are added to the stack. | | | OP\_HASH160 OP\_EQUALVERIFY OP\_CHECKSIG | Top stack item is duplicated. | | | OP\_EQUALVERIFY OP\_CHECKSIG | Top stack item is hashed. | | | OP\_EQUALVERIFY OP\_CHECKSIG | Constant added. | | | OP\_CHECKSIG | Equality is checked between the top two stack items. | | true | Empty. | Signature is checked for top two stack items. | 1. Pay to R-Puzzle Hash (P2RPH) **NOTE:** Since the discovery of a transaction malleation exploit which allows a message hash and signature to be modified to redirect R-Puzzle inputs to modified outputs, the advised method for using R-Puzzles is to include two signatures generating using different SIGHASH types in order to create a distinct message hash. Take care to generate each signature with a different **k** value. scriptPubKey: **OP\_OVER OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG** scriptSig: Bitcoins locked in an R-Puzzle script require the spending party to sign using a known value for 'k' rather than a random number. To redeem the script, the spending party provides both the signature and the public key. The script verifies that the provided signature was signed using the correct k-value, then checks the signature against the public key. Because the public key is not checked as part of the script solution, it is possible to sign the transaction using any keypair. This can be useful when dealing with tokens that are associated with a Bitcoin address as the pubkey that corresponds to that address can be used to sign the transaction without the requirement for there to be bitcoin in the address. The technique is also relevant for Metanet node signing as the Metanet keys can be signed with an R-Puzzle without needing a separate signature. Checking process: | Stack | Script | Description | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | | Empty. | OP\_OVER OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | scriptSig and scriptPubKey are combined. | | | OP\_OVER OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | Constants are added to the stack. | | | OP\_3 OP\_SPLIT OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | Second from top stack item is duplicated. | | | OP\_NIP OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | First 3 bytes of signature are split | | | OP\_1 OP\_SPLIT OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | 3 byte data item is removed | | | OP\_SWAP OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | 1 byte containing R length is split from sig' | | | OP\_SPLIT OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | R Length parameter is moved to top of stack | | | OP\_DROP OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | R is split from sig" | | | OP\_HASH160 OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | sig'"== is dropped from stack | | | OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | R is double hashed (SHA256 followed by RIPEMD160) and result left on stack | | | OP\_EQUALVERIFY OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | Previously defined R-Hash is pushed onto stack | | | OP\_TUCK OP\_CHECKSIGVERIFY OP\_CHECKSIG | Script checks if rHashA = rHash | | | OP\_CHECKSIGVERIFY OP\_CHECKSIG | Pubkey is tucked behind | | | OP\_CHECKSIG | Script checks against | | true | Empty. | is checked against | 1. Pay to Multi Signature (P2MS) scriptPubKey: OP\_3 OP\_5 OP\_CHECKMULTISIG scriptSig: OP\_1 OP\_CHECKMULTISIG offers users the capability to lock coins with a requirement for multiple parties to sign the scriptSig before coins can be spent. OP\_CHECKMULTISIG can check many signatures against many public keys as long as the signatures in the scriptSig are provided in an order that corresponds to the order in which the public keys are arrayed on the stack when it is executed. The first opcode in the ScriptPubKey defines how many signatures must be provided in order for the coin to be successfully spent. The last one before OP\_CHECKMULTISIG indicates to the scripting engine how many public keys to evaluate those signatures against. There must be at least as many items on the stack as are required for the OP\_CHECKMULTISIG opcode to process or the script will be invalid. **Note:** The current version of the scripting engine also includes a bug that requires an additional value to be placed on the stack before the signatures. In this example, OP\_1 has been used to push a 1 to the top of the stack, but in theory any piece of data can be used. This value is consumed by the checking process but is not evaluated. Checking process: | Stack | Script | Description | | ------ | ----------------------------------- | --------------------------------------------------- | | Empty. | OP\_1 OP\_3 OP\_5 OP\_CHECKMULTISIG | scriptSig and scriptPubKey are combined. | | 1 | OP\_3 OP\_5 OP\_CHECKMULTISIG | Constants from scriptSig are added to the stack. | | 1 3 5 | OP\_CHECKMULTISIG | Constants from scriptPubKey are added to the stack. | | true | Empty. | Multisignature script evaluation is performed | 1. Other Puzzle Types Bitcoin's scripting language is rich and diverse and allows a user to create almost any kind of financial instrument that we have today, and many that we don't have. Puzzles do not need to conform to any particular standard or template however it is expected that the vast majority of transactions will be built using template scripts. Examples of more complex script can be found here Pieces of script can be combined to make larger and more complex transactions, and scripts can be built inside conditional loops allowing a single transaction output to be redeemed in multiple different ways. Prior to the Genesis upgrade, complex scripts that fell outside the 'isstandard' testing schema were required to be compressed into a transaction format called 'Pay to Script Hash (P2SH)' This format is now deprecated in favour of using the full, rich scripting language inside transactions. =See Also= * Opcodes used in Bitcoin Script * Protocol rules - "tx" messages * Protocol documentation - Transaction Verification * Transaction Malleability 1. Attribution This content is based on content sourced from under [Creative Commons Attribution 3.0](https://creativecommons.org/licenses/by/3.0/). Although it may have been extensively revised and updated we acknowledge the original authors. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.bsvblockchain.org/wiki/transactions-and-utxos/bitcoin-transactions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.