BSV Intel Cheat Sheet

BSV (Bitcoin SV) is a blockchain that follows the original Bitcoin protocol design. "SV" stands for "Satoshi Vision" - the goal of preserving Bitcoin as described in the 2008 whitepaper.

Unlike other Bitcoin variants that limit block sizes, BSV allows massive blocks (gigabytes), enabling high transaction throughput and data storage directly on-chain.

A transaction is a record of value moving on the blockchain. Every transaction has inputs (where the coins come from) and outputs (where they go).

An output is a "lockbox" that holds coins until someone provides the right "key" to unlock them. The lock is defined by a script - a small program that specifies the spending conditions.

When you "own" Bitcoin, you really own the ability to unlock certain outputs because you have the private key that satisfies their scripts.

A block is a bundle of transactions that miners package together. Roughly every 10 minutes (on average), a miner finds a valid block and adds it to the chain. All transactions in that block become confirmed.

The report scans 144 blocks (approximately 24 hours) to give you a full-day picture of network activity.

A script is a mini-program written in Bitcoin's scripting language. It defines the rules for spending an output. When someone tries to spend coins, the network runs the script to verify they have permission.

Scripts are what make Bitcoin programmable money. Beyond simple payments, scripts can encode:

• Multi-signature requirements (2-of-3 people must sign)
• Time locks (coins can't move until a certain date)
• Hash puzzles (reveal a secret to claim funds)
• Complex contracts with conditional logic

Scripts are written as a sequence of operations (opcodes) and data. Here's the most common script type - a standard payment (P2PKH):

This says: "Duplicate the provided public key, hash it, check it matches the expected hash, then verify the signature."

We classify every output using a three-layer model:

Pay-to-Public-Key-Hash - the standard Bitcoin payment. Over 95% of value transfer uses this format.

It locks coins to the hash of a public key. To spend, you reveal the full public key and sign the transaction. This is more private than exposing your public key directly.

A special output type that stores data without locking any coins. The output is provably unspendable (it starts with OP_RETURN which immediately fails), but the data after it is permanently recorded on-chain.

Applications use OP_RETURN to store:

• Document hashes (proof of existence)
• Social media posts
• Token metadata
• Application state

A method of embedding files (images, text, HTML) inside transaction scripts using a special envelope format. Unlike OP_RETURN, inscriptions are attached to spendable outputs.

We classify these under DATA_PUBLICATION because their primary purpose is data storage, even though the output can technically be spent.

Opcodes are the individual instructions in Bitcoin's scripting language. Each one performs a specific operation - pushing data, doing math, checking signatures, etc.

The colored tags in the report show which opcodes appear in a script, giving you a quick sense of what it does.

Any transaction moving 100 BSV or more. These large movements can indicate significant market activity - exchange deposits/withdrawals, OTC trades, or large holders repositioning.

Every block has a special transaction called the "coinbase" - the first transaction that creates new coins as the mining reward. Miners typically embed their name or pool identifier in this transaction.

We extract this signature from each block to track who mined it.

A healthy network has mining power spread across multiple independent miners. If one entity controls too much hash power (approaching 50%), they could theoretically:

• Double-spend coins
• Censor transactions
• Reorganize the chain

Bitcoin's difficulty adjustment algorithm targets an average of 10 minutes between blocks. This is a deliberate design choice balancing:

• Fast enough for reasonable confirmation times
• Slow enough for blocks to propagate globally before the next one

Mining is probabilistic - sometimes blocks come fast (1-2 minutes), sometimes slow (30+ minutes). This is normal.

Applications build on BSV using standardized data formats. We scan all DATA_PUBLICATION outputs (OP_RETURN, Ordinal envelopes, and spendable metadata scripts) for known marker patterns:

This is where it gets interesting. There are multiple ways to embed data in Bitcoin, and the ecosystem is evolving:

Our report classifies all of these under DATA_PUBLICATION because their purpose is the same - putting data on-chain. The structure (how they do it) varies.

Probably not soon, but the trend is toward more efficient methods. OP_RETURN has drawbacks:

• The output is unspendable - those satoshis are gone forever
• Creates UTXO bloat that nodes must track
• Originally designed as a "don't do this" escape valve, not a feature

Spendable data methods are perhaps more elegant — the data persists on-chain, but the value can still move. We feel this aligns better with Bitcoin's economic model, where every output theoretically could be spent.

The report is built on direct peer-to-peer connection to the BSV network — no centralized API dependencies for core data:

Relay Federation is a decentralized mesh network for BSV. Each bridge is a lightweight SPV node that:

• Syncs headers and verifies transactions with Merkle proofs
• Indexes inscriptions and tokens
• Serves a full REST API — no full node required
• Discovers other bridges via on-chain stake bonds
• Coordinates data sharing through WebSocket peering

We run a bridge node that connects to the BSV P2P network and fetches full blocks for this report's analysis.

The report is generated by an n8n workflow (open-source automation platform) that runs every morning:

Yes, but in a specific, limited way:

The scanner requests parsed transactions from the bridge, which fetches full blocks directly from BSV nodes via the P2P protocol. For each block, it:

1. Parses the coinbase transaction to identify the miner
2. Iterates through every transaction
3. Classifies each output by Purpose → Structure
4. Detects known protocol markers (MAP, B://, AIP, etc.)
5. Flags whale transactions (≥100 BSV)
6. Collects sample scripts for the "Script of the Day" section

The result is a complete picture of on-chain activity — not a sample, but the full 24-hour dataset sourced directly from the blockchain.

The P2P architecture handles current block sizes well. As BSV blocks grow larger:

The taxonomy and analysis logic remain the same — only the data ingestion layer would need to evolve.

Transparency builds trust. When you read a report that says "5 whale transactions detected" or "59% of outputs are payments," you should be able to understand:

• Where those numbers came from (direct blockchain queries, not estimates)
• How classifications are made (deterministic rules, not vibes)
• What AI does and doesn't do (narrative writing, not data generation)

The goal is to help you understand BSV on-chain activity, not to obscure how that understanding is derived.