Research, engineering notes, and market context for blockchain systems.
articles
50
Latest update
Jun 30, 2026
min read
5 min read
BUMP standardizes Merkle path encoding in the BSV ecosystem, unifying single and composite proofs while reducing data redundancy and improving verification efficiency. This article explains the background, data structure, computation, and role of BUMP.
BlockchainMay 20, 2026
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.
blockchain
The strongest recent posts from the same topic, ordered by freshness.
BlockchainBUMP standardizes Merkle path encoding in the BSV ecosystem, unifying single and composite proofs while reducing data redundancy and improving verification efficiency. This article explains the background, data structure, computation, and role of BUMP.
BlockchainBroadcasting hands a transaction to the network, not directly modifying on-chain data. This article explains what broadcast really means, where it fits in the BSV tech stack, and the transaction lifecycle developers must track.
BlockchainSPV lets users and applications verify transactions with only block headers and relevant proofs, without downloading the full blockchain. This article explains how SPV uses Merkle proofs and block headers to separate verification tasks, cutting storage and bandwidth requirements, and why this matters for BSV’s big‑block scaling path.
BlockchainThis article systematically explains the full SPV (Simplified Payment Verification) process in the BSV blockchain from a technical editor’s perspective: from transaction verification and txid computation, through Merkle proof derivation of the Merkle root, to block header chain confirmation of the block’s validity. It also contrasts SPV with block explorer queries, helping developers understand how to verify on-chain transactions without downloading full blocks.
BlockchainBEEF (Background Evaluation Extended Format) is a data format that bundles transactions, their ancestor transactions, and Merkle proofs together. It enables receivers to independently perform SPV validation without relying on full chain data. This article introduces BEEF’s motivation, structure, validation logic, and its place in the BSV tech stack.
BlockchainThe Merkle root is the root hash computed from all transaction IDs (txids) in a block via a Merkle tree. Written into the block header, it serves as a cryptographic commitment to the transaction set. This article explains its principle, role, relation to big blocks and SPV verification, and common misconceptions.
BlockchainA Merkle proof is a lightweight method to verify that a transaction is included in a block's transaction set without downloading the entire block. This article covers the principles, structure, verification process, role in the BSV tech stack, and common misconceptions.
BlockchainThe 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.
BlockchainUnderstand 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.
BlockchainUnderstanding 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.
BlockchainTo 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.
BlockchainIn 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.
BlockchainTransaction 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.
BlockchainLearn 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.”
BlockchainIn 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."
BlockchainThis 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.
BlockchainBSV 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.
BlockchainWhen 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.
BlockchaincreateAction() 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.
BlockchainWalletClient 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.
BlockchainIntroduces 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.
BlockchainA transaction that is valid under consensus rules may not be processed by the network. Understand standard scripts and miner policies to avoid broadcast failures.
BlockchainBitcoin 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.
BlockchainLearn the basics of OP_RETURN, how it differs from regular payments, data format requirements, privacy considerations, and use cases.
BlockchainP2PKH (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.
BlockchainUnlocking 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.
BlockchainLocking 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.
BlockchainDouble 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.
BlockchainThe 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.
BlockchainIn 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.
BlockchainIn 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.
BlockchainA 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.
BlockchainEndian 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.
BlockchainA 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.
BlockchainBSV 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.
BlockchainA 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.
BlockchainA 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.
BlockchainA 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.
BlockchainA 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.
BlockchainBRC-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.
BlockchainA 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.
BlockchainMainnet 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.
BlockchainWIFs, 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.
BlockchainBTC, 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.
BlockchainSPV (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.
BlockchainThis 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.
BlockchainProof of Work uses a mechanism that is expensive to compute and cheap to verify, allowing miners to compete for new blocks in an open network and using accumulated work to determine the ordering of transaction history. This article explains how PoW works, why miners can order transactions, its security significance, and the miner-economic logic behind BSV’s focus on large blocks, low fees, and high transaction volume.
BlockchainBlockchain 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.
BlockchainPeer-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.
BlockchainA compact note on settlement design, data permanence, and why builders keep looking at BSV.