BSV Transactions and SHA-256

What is a Transaction?

BSV Blockchain is an electronic cash system made up of 2,100,000,000,000,000 tokens (called ‘satoshis’) and a ledger. A ‘bitcoin’ is $1*10^8$ satoshis. These satoshi tokens are the smallest unit of account in BSV. To transfer ownership of an arbitrary amount of satoshis, a record is added to the ledger in the form of a transaction.

The transaction acts as a contract complete with how many satoshis are being transferred; from where the satoshis are coming from; and to whom their ownership is being transferred to. Each transaction holds an arbitrary number of input Unspent Transaction Outputs (UTXOs) which include a puzzle or ‘lock’ written in a minimal scripting language called Bitcoin Script (based on Forth) that need to be unlocked in order for the sender to transfer the ownership of the satoshis they hold (I.e., spend), and an arbitrary number of output UTXOs which include new locking scripts that only the receiver can unlock.

Each locking script resolves to either true or false. This means BSV is a predicate system and as such the locking script of a UTXO can be anything that ultimately resolves to true or false.

As discussed briefly in chapter 1, the most common type of UTXO locking script template used in BSV is the Pay-to-Public-Key-Hash (P2PKH) template. The sender uses a hash of the receiver's public key to lock the satoshis being spent in a new output UTXO. The receiver is then able to unlock and use that UTXO as an input in a new transaction by providing the digital signature generated from the corresponding private key. As briefly mentioned above, it’s important to note that there are innumerable ways to lock, and subsequently unlock, UTXOs -- they just need to resolve to either true or false. So long as the result resolves to true, the sending and receiving parties are essentially transferring ownership of the contained satoshis with a digital signature (even if it's not a literal digital signature like in a P2PKH transaction).

In this way, we can say each satoshi itself is a chain of digital signatures that can be traced back to the initial instantiation of the Bitcoin network in 2009. And, transactions are the fundamental record type that track the addition of each new digital signature to each satoshi since the Bitcoin network was instantiated in 2009.

Once a transaction has been constructed and serialised in its raw HEX form, it's hashed using HASH-256 to get its corresponding transaction ID (TXID). BSV nodes use TXIDs in their Merkle trees and in their memory pools to keep received transactions organised.

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

\