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.

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:

{ 
    "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.

Element	Description	RAW Hexadecimal	JSON
Previous TX hash (32 bytes little endian)	The TXID of the transaction that holds the output UTXO corresponding to this input UTXO	67e7105b52e8534596af29dba949921cffe3dbaa555b8ed96121346c6755adae	"txid": "aead55676c342161d98e5b55aadbe3ff1c9249a9db29af964553e8525b10e767"
Previous output index (4 bytes little endian)	The Vout of the output UTXO in the referenced TX corresponding to this input UTXO	00000000	"vout": 0,
Input script length (1-9 bytes little endian)	The number of bytes long the unlocking script is	6a	106 (decimal)
Input script (variable length little endian)	The unlocking script	47304402206e4db9dee8449b861e5fdc00ba3bdb80fba8cd52c75489376c54bd65d26262650220453569438e6bc6f957b1f7ff6fff4af2e42edaae1ac885382373d42fa569b17c41210267d2d1f8b3affffa10b68b2756ba7f6f4efafcadbecd145181016178d00b379b	"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 field	ffffffff	"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

\