# BSV Transactions and SHA-256 ## What is a Transaction? The BSV Blockchain is an electronic cash system comprising 2,100,000,000,000,000 indivisible units called 'satoshis' and a shared ledger. A ‘bitcoin’ is a denomination equal to 100,000,000 satoshis. Satoshis are the smallest unit of account in BSV. Ownership of any amount of satoshis is transferred by adding a record to the ledger in the form of a transaction. Each transaction specifies: * **The number of satoshis being transferred.** * **The source of these satoshis (input UTXOs).** * **The destination for the satoshis (output UTXOs).** Transactions consume input UTXOs and create new output UTXOs. Each UTXO includes a locking script (commonly referred to as `lockScript or scriptSig`) written in Bitcoin Script, a minimal, stack-based language derived from Forth. To spend (i.e., transfer ownership of the tokens contained inside) a UTXO, the sender must provide a corresponding unlocking script (`unlockScript or scriptPubKey`) that satisfies the conditions of the original locking script. A locking script resolves to either `true` or `false` upon evaluation, making BSV a predicate system. As long as the conditions resolve to `true`, the ownership of the associated satoshis can be transferred. The most common locking script template in BSV is Pay-to-Public-Key-Hash (P2PKH). In a P2PKH transaction: 1. The sender locks the satoshis by including the hash of the recipient's public key in the locking script of a new UTXO. 2. The recipient unlocks the UTXO by providing a digital signature created using their private key, which matches the hash in the locking script. While P2PKH is the most prevalent template, locking and unlocking scripts can vary widely, offering endless possibilities for defining custom spending conditions. Regardless of complexity, every script ultimately resolves to either `true` or `false`, enabling the transfer of satoshi ownership. Every satoshi is part of a chain of digital signatures tracing back to the genesis of the Bitcoin network in 2009. Transactions serve as the fundamental record, documenting each new addition to this chain of signatures. Once a transaction is constructed and serialized into raw hexadecimal (HEX) form, it is hashed using double SHA-256 to generate a unique transaction ID (TXID). BSV nodes use TXIDs to organize transactions in memory pools and Merkle trees, ensuring efficient validation and tracking across the network. ![](/files/7rOlJw69mdm0qvgp5gGp) ## P2PKH Transactions Although it’s possible to embed data directly into transactions, P2PKH is the most well understood UTXO locking script template. In P2PKH UTXOs, the public key hash is an address, which is a **HASH-160** (further explored in chapter 5) of the public key portion of an Elliptic Curve public-private key-pair. In P2PKH UTXOs, satoshis are “locked” to the receiver’s address allowing them to unlock the UTXO and spend the satoshis within it using the corresponding private key for the public key used to create the address. ## Example P2PKH Transaction The following is an example of a P2PKH transaction in RAW hexadecimal format: `010000000167e7105b52e8534596af29dba949921cffe3dbaa555b8ed96121346c6755adae000000006a47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379bffffffff019c276bee000000001976a914accd105073775756cc04962bc1e4893694f50c5588ac00000000` Below, is the same transaction decoded and presented in a JSON format: ```markup { "version": 1, "size": 191, "locktime": 0, "vin": [ { "txid": "aead55676c342161d98e5b55aadbe3ff1c9249a9db29af964553e8525b10e767", "vout": 0, "scriptSig": { "asm": "304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c[ALL|FORKID] 0267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b", "hex": "47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b" }, "sequence": 4294967295 } ], "vout": [ { "value": 39.999999, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 accd105073775756cc04962bc1e4893694f50c55 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a914accd105073775756cc04962bc1e4893694f50c5588ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "mwGeB8HZwx22snzWoXRRfL2dhmJ4QXZr9V" ] } } ], "time": 1645757424, } ``` Transactions consist of 6 serialised elements: | **Element** | **Description** | **RAW Hexadecimal** | **JSON** | | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Version (4 bytes little endian): | The version number of a transaction is meant for transaction routing and handling. Currently, only version numbers 01000000 (1) and 02000000 (2) are accepted by. In future, the transaction version number will allow nodes to specialize their services by geographic location and service type. | `01000000` | `"version": 1` | | Input count (1-9 bytes little endian): | Specifies how many input UTXOs are in the transaction | `01` | `"vin"` | | Input list (variable length little endian): | The input UTXOs themselves | `67e7105b52e8534596af29dba949921cffe3dbaa555b8ed96121346c6755adae000000006a47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379bffffffff` | `"txid": "aead55676c342161d98e5b55aadbe3ff1c9249a9db29af964553e8525b10e767", "vout": 0, "scriptSig": { "asm": "304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c[ALL\|FORKID] 0267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b", "hex": "47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b" }, "sequence": 4294967295` | | Output count (1-9 bytes little endian): | Specifies how many new output UTXOs are being created in the transaction | `01` | `"vout":` | | Output list (variable length): | The output UTXOs themselves | `9c276bee00000000976a914accd105073775756cc04962bc1e4893694f50c5588ac` | `"value": 39.999999, "n": 0, "scriptPubKey": { "asm": "OP_DUP OP_HASH160 accd105073775756cc04962bc1e4893694f50c55 OP_EQUALVERIFY OP_CHECKSIG", "hex": "76a914accd105073775756cc04962bc1e4893694f50c5588ac", "reqSigs": 1, "type": "pubkeyhash", "addresses": [ "mwGeB8HZwx22snzWoXRRfL2dhmJ4QXZr9V" ] }` | | nLocktime (4 bytes little endian) |

Represents either:

1. A block height if the value is < 500,000,000

2. A UNIX Epoch timestamp – the number of seconds elapsed since 01 January, 1970.

Note that the nLockTime of a transaction is ignored if all the transaction inputs have the maximum nSequence value (UINT\_MAX).

| `00000000` | `"locktime": 0` | Input UTXOs consist of 5 serialised elements: The below table breaks-down the input UTXO from the above example transaction.
ElementDescriptionRAW HexadecimalJSON
Previous TX hash (32 bytes little endian)The TXID of the transaction that holds the output UTXO corresponding to this input UTXO67e7105b52e8534596af29dba949921cffe3dbaa555b8ed96121346c6755adae"txid": "aead55676c342161d98e5b55aadbe3ff1c9249a9db29af964553e8525b10e767"
Previous output index (4 bytes little endian)The Vout of the output UTXO in the referenced TX corresponding to this input UTXO00000000"vout": 0,
Input script length (1-9 bytes little endian)The number of bytes long the unlocking script is6a106 (decimal)
Input script (variable length little endian)The unlocking script47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b"asm": "304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c[ALL
Sequence number: ‘nSequence' (4 bytes little endian)Indicates whether an input is considered ‘finalised’. nSequence is considered final when its value is 0xFFFFFFFF i.e. the maximum value of a 4-byte fieldffffffff"sequence":4294967295
Output UTXOs consist of 3 serialised elements: The below table breaks-down the new output UTXO(s) from the above example transaction. | **Element** | **Description** | **RAW Hexadecimal (Little Endian)** | **JSON (Big Endian)** | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Value (8 bytes little endian) | The value being transferred (in satoshis) | `9c276bee00000000` | `"value": 39.999999` | | Output script length (1-9 bytes little endian) | How long the output UTXO locking script is | `19` | `25 (decimal)` | | Output script (varInt little endian) | The actual output UTXO locking script | `76a914accd105073775756cc04962bc1e4893694f50c5588ac` |

"asm": "OP\_DUP OP\_HASH160 accd105073775756cc04962bc1e4893694f50c55 OP\_EQUALVERIFY OP\_CHECKSIG",

"hex": "76a914accd105073775756cc04962bc1e4893694f50c5588ac"

| | Locktime | When the transaction can be included in a block. Block height if <500 000 000 or UNIX timestamp if >500 000 000. | 00000000 | 00000000 | \\ --- # Agent Instructions: 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: ``` GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/hash-functions/sha-256/bsv-transactions-and-sha-256.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.