# The Data Elements Now that we understand what a Merkle tree is and why they are used in a number of distributed and peer-to-peer systems, let us take a closer look at their role in BSV in particular. BSV is a peer-to-peer electronic cash system. When creating physical cash, there are substantial measures taken to ensure the authenticity of the cash instrument; however even with these measures, there is still a significant problem with the counterfeiting of these physical objects. Creating an electronic cash system needs similarly sophisticated techniques to ensure the integrity of the cash-like objects of the system. The use of Merkle trees as a verification process is one of the techniques employed to verify the authenticity and integrity of these cash-like objects on the BSV network (referred to as satoshis). For this system to have any merit, these tokens must be verified from their issuance through each of the instances where they are used to exchange value in the system. In the case of BSV, these exchange events are referred to as transactions. When a BSV transaction occurs, it is generated by the wallet software as a set of statements in BSV's native programming language called 'Script'. At the very least, a transaction will be a statement that provides a 'true' solution for a locking puzzle that was generated by the previous custodian when the coins were received, as well as a statement for the generation of a new locking puzzle that will be passed on to the next entity in the chain of custody of the tokens. The former are referred to as inputs for a transaction and the latter as outputs. These locking and unlocking scripts often utilise digital signatures with asymmetric public and private keys that are generated by the wallet software via an elliptic curve digital signature algorithm (ECDSA). These digital signatures may sound complex, but they are simply an electronic, encrypted, stamp of authentication on digital information such as email messages, macros, or electronic documents. In the case of BSV, these keys are used to create a solution to the locking puzzle that contains the tokens received via an earlier transaction so that they may be spent. The below diagram shows the most commonly used BSV script template called a Pay to Public Key Hash or P2PKH. Here, not only is a hash of the transaction preimage used to create the signature, but the public key itself is hashed to keep it private until the coin is spent. ![](https://bitcoinsv.academy/storage/photos/8381/BSVA-MerkleTrees_Ch2Less1_VA1.jpg) These script statements instruct operations on chunks of data which represent the values for the specific input fields of the statement inside the <> in the image above. These chunks are concatenated into a string of raw transaction data which can be seen in the table below. Since a BSV transaction will only be validated if it is the first time the inputs specified in the transaction statements are being spent, each transaction has unique raw data. When this raw transaction data is put through a hash function, a unique hash is generated. In this way, each transaction can be identified by this hash value (TXID) rather than having to specify all the details of the transaction. ![](/files/IMKXZh7SgUO5DhKGWxH5) | **Bytes** | **Data Field** | **Hexadecimal String** | | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- | | 4 | Version | 01000000 | | | 1-9 | Number of Inputs | 01 | | | 32 | Previous TX hash (reversed) | f253cf794a7a0aff45144c8ea1fc4271be683952ae8241ee1524266b46375246 | **Inputs** | | 4 | Previous Output Index | 00000000 | | | \ qty with variable length per input | Script Length | 6b | | | \-many bytes |

ScriptSig
(Unlocking Script)

|

4830450221008f8c069a2e8aa0cce2455374916ff1dedc40da58680c7fab925b0d8206e

d4e48022013bd576c0ed17448525d282ca4ddc55245c788da88eee7e35a2084b7bed78

caa01210302e3a61057a9c9616291b17085c16d9e1f22821395e3ba792f4492f61d57169b

| | | 4 | nSequence | ffffffff | | | 1-9 | Number of Outputs | 01 | | | 8 | Value (reversed) | 30c11d00000000 | **Outputs** | | 1 - 9 bytes VI = VarInt | Script Length | 19 | | | \-many bytes | ScriptPubKey (Locking Script) | 76a914800311626c5e50a10ea7d84f42471c0e7c17a4a088ac | | | 4 | nLockTime | 00000000 | | | **Serialised String of Raw Transaction Data** | | | | |

0100000001f253cf794a7a0aff45144c8ea1fc4271be683952ae8241ee1524266b46375246000000006b4830450221008f8c069a2e8aa0cce2455374916ff1d

edc40da58680c7fab925b0d8206ed4e48022013bd576c0ed17448525d282ca4ddc55245c788da88eee7e35a2084b7bed78caa01210302e3a61057a9c96162

91b17085c16d9e1f22821395e3ba792f4492f61d57169bffffffff0130c11d00000000001976a914800311626c5e50a10ea7d84f42471c0e7c17a4a088ac00000000

| | | | --- # 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/merkle-trees/merkles-trees-in-bsv/the-data-elements.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.