At the recent BSV DevCon 2024, Kevin Healy (Content Specialist at BSV Academy) and Todd Price (Chief of Content at BSV Academy) introduced the audience to the BSV Academy and gave an introduction to the basics of the transaction architecture of BSV.
The presentation is a good entry point to get an overview of how the BSV blockchain works. Healy shed light on the specific courses and how these cater to diverse objectives. Following up on that, Price gave a thorough exploration of BSV transaction fundamentals, underscoring their versatile and dynamic potential.
Courses tailored to builders
Healy gave an overview and explained how developers can navigate them. Instead of introducing and discussing each course one by one, Healy highlighted aspects that could interest a developer with specific needs.
He noted that for specific goals, it might not be necessary to take many courses and also that there are existing services and infrastructure that solve specific needs. These are the aspects Healy discussed in his presentation:
- Micropayments: For those navigating micropayment solutions, foundational knowledge suffices. Leveraging existing wallets or platforms like LaMint can streamline entry into this domain.
- Timestamping: Essential for data integrity, timestamping solutions like whatsonchain suffice for basic needs. A deeper understanding can be gained through courses covering hash functions and Merkle trees, pivotal for robust timestamp implementations.
- Programmable Money: Delving into Bitcoin script unlocks the potential for programmable money solutions. Healy mentions a specialised course focusing on Bitcoin script, highlighting its pivotal role in abstracting complexities within transaction workflows.
- Optimisation Problems: BSV’s capacity to tackle optimisation conundrums, exemplified by scenarios like optimising delivery routes, underscores its practical applications. Bitcoin script’s heuristic capabilities empower developers to devise innovative solutions to real-world economic challenges.
- DAG Data Structures: Directed acyclic graphs (DAGs) offer versatile applications across diverse fields, from machine learning to project management. Healy emphasises BSV’s enhancement capabilities through timestamping and incentivisation mechanisms, transforming workflows by ensuring task completion and reward mechanisms.
Understanding transaction dynamics of the BSV blockchain
Transactions form the core of the BSV network, facilitating the transfer of value between users without the need for a centralised authority. Despite their perceived complexity, the fundamental structure of BSV transactions is both flexible and straightforward.
Every transaction in BSV begins with a Coinbase transaction. In this process, transaction processors collect block subsidies, currently set at 3.125 BSV per block, along with transaction fees. These coins are claimed by the processor without any inputs and are then locked with a script. This initial transaction is crucial as it introduces a new BSV into circulation.
The outputs from Coinbase transactions are subsequently unlocked in future transactions. Each transaction, represented in hexadecimal, includes details such as version, lock time, and inputs. Unlocking funds typically require a signature that meets the conditions of the locking script, ensuring that only authorised parties can access the funds.
The UTXO model – A key component of BSV transactions
Price explained the UTXO (Unspent Transaction Outputs) model of the BSV blockchain. At its core, a BSV transaction involves inputs being consumed and reallocated to outputs in a continuous chain. Unlike traditional banking systems, BSV does not use accounts. Instead, tokens move discretely from one transaction to the next, ensuring a scalable and transparent transfer of value.
These outputs, available for spending, are associated with various keys, each containing discrete amounts of tokens. The UTXO set is essentially a database of all unspent transaction outputs, maintained by nodes to verify if a transaction’s unlock script correctly solves the associated lock script.
Each transaction input references a previous transaction’s output and includes details like script length and sequence value. Sequence values allow for multiple spends within a transaction template, adding flexibility for dynamic transactions like crowdfunding. This structure ensures that each transaction can be traced back through the blockchain, maintaining transparency and integrity.
Unlocking scripts and transaction scripts
Unlocking scripts involves a signature and a public key. The private key generates the signature by mutating the hash of a message, allowing funds to be unlocked if validated by the network nodes. This cryptographic process ensures that only the rightful owner of the private key can authorise the spending of funds.
BSV transaction scripts consist of various opcodes, such as “OP_DUP,” which duplicates a value and ensures it matches a provided value. Unlocking scripts typically include a signature and a public key, but there can be any data satisfying the script’s conditions. This scripting language allows for complex and versatile transaction structures.
The BSV blockchain supports various scripts for locking coins in transactions, including:
- P2PKH (Pay to Public Key Hash): Requires a public key and a corresponding private key signature.
- P2SH (Pay to Script Hash): Involves a hash puzzle where the script is hidden until spending.
- Multi-signature: Requires multiple signatures to authorise spending, allowing for complex arrangements.
The role of sig-hash flags in transaction management
Price explained how transactions are managed using sig-hash flags to specify their handling. These flags determine which parts of the transaction are signed: all inputs, all outputs, or specific combinations. The “anyone can pay” (ACP) flag allows an input to be signed while leaving the possibility to add more inputs later.
Including data in BSV outputs has significant implications. Larger scripts result in higher fees due to the fee-per-byte structure. Data can be embedded using push data opcodes, with OP_RETURN specifically used for non-spendable data meant for informational purposes. This distinction ensures that data can be stored on the blockchain without being spendable.
BSV transactions are not static; they can dynamically add inputs and outputs. This flexibility, managed by sig hash flags, allows innovative arrangements, such as using a single transaction throughout a product’s supply chain lifecycle. Trust dynamics in transactions vary, with the ACP option offering maximum flexibility if there is trust between parties, while the “all” option locks inputs together for transaction integrity in adversarial scenarios.
Advanced Concepts: Merkle Trees, DAGs, and Transaction Containers
Price delved into advanced concepts like constructing a Merkle tree for transactions, which culminates in a single Merkle root summarising all transactions. The unified Merkle path format and Directed Acyclic Graph (DAG) structures further enhance data organisation and access management.
The presentation featured many more concepts and detailed descriptions of the BSV transaction architecture and is worth a watch for anyone interested.
