Proof of Work: Why Can Miners Order Transactions?

A compact note on settlement design, data permanence, and why builders keep looking at BSV.

Peer-to-peer electronic cash is the starting point for understanding Bitcoin and BSV. It emphasizes transferring digital value directly through transactions, signatures, and a public ledger, rather than relying on central platform accounts. This article explains peer-to-peer, cash, double spending, UTXOs, and why BSV emphasizes low fees, high-frequency transactions, and on-chain data.

Blockchain is not just a ledger; it is also a public time-ordering machine. This article explains what the timestamp server means in Bitcoin/BSV, the role of block height and confirmations, and the value of timestamps in double-spend prevention and data attestation.

This article explains the basic mechanics of the BSV network: how transactions are constructed, how blocks organize them, how miners are incentivized, and why BSV places special emphasis on low fees, large blocks, and high-throughput on-chain transactions.

SPV (Simplified Payment Verification) allows lightweight clients to verify that a transaction is included in a block without downloading the full blockchain. This article explains how SPV works, the role of Merkle proofs, what SPV can and cannot prove, and why SPV is a core capability in the BSV architecture.

BTC, BCH, and BSV all come from Bitcoin, but their technical roadmaps differ significantly. This article explains why BSV chooses a low-fee, high-volume, large-scale on-chain scaling approach, through the lenses of on-chain scaling, low fees, a stable protocol, SPV, enterprise data, and real-world challenges.

WIFs, mnemonic phrases, and HD wallets all relate to key storage, recovery, and derivation, but they mean different things. This article explains their differences, the role of xpubs, and security practices for BSV wallets and application development.

Mainnet carries real value, while test environments are for learning and development. This article explains the differences between BSV mainnet and test environments, common risks, SDK usage considerations, and practical environment-separation recommendations for project configuration.

A BSV wallet is not a traditional account system. There is no single on-chain balance field; instead, the wallet calculates balances and creates transactions by managing private keys, UTXOs, inputs, outputs, signatures, and related data. This distinction is essential for understanding change, multiple inputs, non-custodial wallets, and application authorization.

BRC-100 is an interface standard in the BSV ecosystem that describes how applications and wallets communicate. It emphasizes that applications express business intent while wallets retain control of keys, helping non-custodial applications request transaction creation, signing, and returned results in a safer and more consistent way.

A transaction input is the funding source of a BSV transaction. It references a specific unspent output from a previous transaction and provides unlocking data. Understanding inputs helps explain the UTXO model, outpoints, double-spend conflicts, fee calculation, and transaction debugging.

A transaction output is a new unit of value created by a BSV transaction, usually consisting of an amount and a locking script. Outputs can represent payments and change, but they can also carry OP_RETURN data, token state, or business records. Understanding outputs, UTXOs, and output indexes is fundamental to understanding BSV transactions and application protocol design.

A TXID is the most common transaction identifier in BSV. It can be used to look up transactions, reference outputs, store business records, and build SPV proof flows. But a TXID identifies the whole transaction, not a specific output, and it does not mean the transaction is final. Real applications should store it together with the output index, status, raw transaction, and proof materials.

A change output is a key concept in BSV’s UTXO model: old UTXOs must be spent in full, and any unspent amount must be returned to the payer through a new output. This article explains how change works, how it relates to fees, change addresses, privacy, and practical UTXO management.

BSV transaction fees are not stored as a separate field. They are calculated as total inputs minus total outputs. Understanding this rule helps developers handle change correctly, estimate fees, manage UTXOs, and avoid accidentally turning remaining balance into fees.

A raw transaction is the original byte representation of a transaction after protocol-compliant serialization, usually shown as a hexadecimal string. It is central to TXID calculation, signing, broadcasting, and debugging, and is a key concept for understanding how BSV transactions work at the protocol level.

Endian is a common byte-order issue when debugging BSV transactions, especially in raw transactions, TXIDs, outpoints, numeric fields, and Merkle proofs. Understanding the difference between display format and serialized bytes helps avoid false “TXID mismatch” or “proof calculation failed” conclusions.

A UTXO, or “unspent transaction output,” is the basic unit of the BSV transaction model. A wallet balance is not an on-chain account field, but the sum of controllable UTXOs. Understanding UTXOs helps explain BSV inputs, outputs, change, fees, double-spending, Script, and parallel processing.

In BSV, spending does not update a balance. It consumes old UTXOs and creates new ones. Understanding this model helps explain payments, change, transaction chains, and the basic logic behind tokens and application state transitions.

In BSV’s UTXO model, an address is not an account or a single balance slot. The same address can be associated with multiple UTXOs, and a wallet balance is simply the sum of those outputs. Understanding this is essential for transaction construction, fee handling, UTXO fragmentation, and privacy.

The UTXO model splits state into independent outputs, allowing transaction verification to proceed in parallel, providing a key data structure foundation for BSV's on-chain scaling and high throughput. This article compares the account model with the UTXO model, explains the principles of parallelism, practical limitations, and its relationship with Teranode and application design.

Double spending is a core problem for digital cash systems. This article explains the principle, transaction structure, miner's role, 0-conf risk, signatures and double spend, and engineering best practices.

Locking script is an essential part of a BSV transaction, defining the conditions under which a UTXO can be spent. This article starts from the basics, gradually explaining the location of locking scripts, their relationship with addresses, how they are expressed, and their importance in applications.

Unlocking script is the unlocking material in a transaction input that satisfies the locking conditions of a previous output. This article comprehensively explains the concept, location, working principle, and common misconceptions.

P2PKH (Pay to Public Key Hash) is the most basic payment script in Bitcoin/BSV. This article breaks down its core logic, workflow, relationship with addresses, unlocking conditions, and why BSV developers need to understand it.

Learn the basics of OP_RETURN, how it differs from regular payments, data format requirements, privacy considerations, and use cases.

Bitcoin Script is a stack-based scripting language used to verify transaction spending conditions. This article starts with the concept of a stack, illustrates its execution process with examples, and explores key points such as P2PKH, restricted design, and BSV applications, helping readers understand the core mechanism of this on-chain verification language.

A transaction that is valid under consensus rules may not be processed by the network. Understand standard scripts and miner policies to avoid broadcast failures.

Introduces the installation, project setup, and verification process for @bsv/sdk, helping developers quickly enter the BSV development environment and understand the SDK's role in the tech stack.

WalletClient is a standardized client for connecting wallets in BSV applications. It enables applications to describe transaction intent while the wallet handles authorization, signing, and UTXO management, thereby isolating complexities like private keys, UTXOs, and signing.

createAction() is the core method in the BSV SDK, allowing applications to describe transaction actions via a high-level interface while the wallet handles signing, fees, and broadcasting. This article explains its principles, parameters, and practical usage.

When using the high-level SDK, the wallet automatically selects spendable UTXOs, generates change outputs, and calculates fees. This article explains how this process works, its benefits, and potential risks.

BSV transactions can do more than transfer satoshis. By including data outputs, you can record text, hashes, or business events on-chain. This article starts with the first Hello BSV transaction, explains the difference between data outputs and payment outputs, how to construct an OP_RETURN using the SDK, the reason for hex encoding, and how to move toward structured protocol design.

This article teaches you how to use the block explorer WhatsOnChain to view transaction details, understand core concepts like inputs, outputs, scripts, and fees, and leverage the explorer to infer the underlying logic of the SDK.

In BSV's UTXO model, manually specifying transaction inputs is a must-have skill for advanced development. This article explains the essence of inputs, the required information, code examples, and common pitfalls, helping you avoid the mental trap of "debiting an address."

Learn how Bitcoin transaction outputs work by constructing transactions manually. This article covers output types, change rules, index ordering, and common pitfalls, helping you advance from “sending transactions” to “designing BSV applications.”

Transaction fees are not an explicit field but the difference between total inputs and total outputs. Understanding the fee calculation logic, factors affecting transaction size, and BSV network policies is essential for building on-chain applications.

Understand the necessity of multi-input signatures in Bitcoin transactions, avoid common misunderstandings, and learn the basics of P2PKH signing, SDK usage, and what signatures actually protect.

Understanding transaction serialization is key to connecting application development with the blockchain network. This article explains why serialization is needed, the standard transaction structure, the role of hex, serialization and deserialization in the SDK, the relationship with txid, and common misconceptions, helping you move from calling the SDK to debugging on-chain data.

In BSV development, constructing a transaction is only the first step. This article explains the significance of transaction broadcasting, common misconceptions, pre-broadcast checks, how to interpret the return value, and failure reasons, helping developers correctly submit transactions to the network.

To truly grasp the Bitcoin white paper's definition of a coin as a chain of digital signatures, you must understand transaction chains. This article starts from the simplest model to explain how UTXOs transfer between transactions and why transaction chains are essential for state management in BSV applications.

The block header is an 80‑byte summary of a Bitcoin block. It does not contain full transactions, yet it is the critical structure linking the proof‑of‑work chain and committing to the transaction set. This article explains the header fields, Merkle root, and SPV principles, helping you understand how BSV enables massive scaling.