Bitcoin Block Detective: Follow Inputs, Outputs and UTXOs

Start with the transaction, not a wallet nickname

Bitcoin Block Detective research starts with a public transaction identifier and a question that can be answered from the record. A wallet nickname, payment screenshot, or shortened address may help locate the relevant material, but it should not become the evidence itself. Preserve complete references before drawing a flow chart or attaching a real-world name.

The Bitcoin research hub provides the chain-specific starting point. The blockchain search tool recognizes supported input patterns and prepares an external explorer lookup. Its output is a navigation aid, not a claim that an address belongs to a particular person. When you reach the source, inspect the transaction structure and the selected network before accepting any summary. Clear research begins with the record you actually have, not with the story you expect it to tell.

Understand what an input spends

Bitcoin uses transaction outputs as the units consumed by later inputs. A wallet's balance is therefore not the same kind of ledger field as a conventional account statement. The official transaction guide explains that an input references a previous output and that an unspent output remains available until spent.

For research, identify the previous transaction and the specific output position whenever the explorer provides them. A transaction identifier alone can be insufficient when several outputs exist. In a worksheet, keep the outpoint reference distinct from a displayed address. This makes it possible to describe exactly which output the selected transaction consumed.

Do not immediately expand every input into a claim about one person's funds. First write the narrow observation: the selected input references the specified earlier output. That relationship is a useful fact without an ownership conclusion. The transaction tracer helps structure these relationship notes so the evidence and the interpretation stay visibly separate.

Read all outputs before naming a recipient

A Bitcoin transaction can have multiple outputs. A screenshot that highlights one address does not necessarily explain the others, and a familiar label does not establish the purpose of every output. Inspect the complete output list in the selected source and preserve the amounts with their units.

For an illustrative payment review, suppose one output matches a destination supplied in an invoice and another goes elsewhere. The first comparison can be documented directly: the displayed destination and amount match the supplied reference. Calling the second output “change” requires an additional interpretation. Keep that interpretation labeled rather than presenting it as a field guaranteed by the payment screenshot.

The wallet research guide explains why a single address should not be treated as a complete personal wallet. A useful output table can include position, amount, displayed destination, source link, and notes. It should not include an invented human owner merely because the table looks unfinished without one.

Reconcile amounts with a transparent example

Consider a hypothetical ordinary transaction with inputs totaling 0.015 BTC and outputs totaling 0.0148 BTC. The difference is 0.0002 BTC. In this simplified example, that difference represents the fee. These figures are invented to illustrate a calculation; they are not taken from a live transaction or offered as a typical fee.

Write the formula beside the worksheet and retain the source values. Do not mix BTC and satoshi amounts without an explicit conversion, and do not let a rounded interface display silently change the calculation. If you also show a fiat estimate, identify its price source and timestamp separately from the blockchain record.

A reviewer should be able to reproduce your result from the displayed inputs. If they cannot, the number is not ready for a final report. The research methodology treats calculations as their own layer of evidence: the underlying records may be observed facts, while the arithmetic and chosen scope are the researcher's responsibility to explain.

Record confirmation context accurately

A transaction observation has a time component. Preserve the status shown by the explorer and the moment you checked it. A screenshot from an earlier stage may differ from a later view without referring to a different transaction. Avoid describing a temporary observation as a permanent guarantee.

Bitcoin's payment processing guide discusses unconfirmed transactions and confirmation considerations. A research report should document the observed status without presenting its own unsupported settlement guarantee. The appropriate operational threshold depends on the payment context and is not decided by a colorful explorer badge alone.

Separate three fields: the transaction timestamp displayed by the source, your retrieval time, and the confirmation information you observed. If a provider does not expose a field, leave it explicitly unavailable. For an incident timeline, retain earlier observations as separate entries rather than overwriting them with the latest screen. This makes changes in your evidence understandable to someone reviewing the case later.

Treat change and common control as hypotheses

Graph layouts make ownership inference feel deceptively obvious. Several inputs converge on one transaction, so a reader may assume one person controlled them all. Another output resembles change, so the reader may assign it to the sender. These can be analytical hypotheses, but the visual shape alone does not prove them.

Bitcoin's contract examples include collaborative transaction constructions. They provide a concrete reason not to treat every multi-input pattern as automatic proof of a single owner. Your report should preserve the transaction relationship even when ownership remains unresolved.

Use separate visual styles for observed spending relationships and inferred associations. The fund flow graph guide recommends labeling each edge with its meaning and evidence. A solid edge can represent a documented reference between records; a clearly identified hypothesis can be discussed in a note. Do not hide both behind the same arrow and then claim the diagram speaks for itself.

Follow a path without overcounting value

Decide what a trace is intended to show before following another hop. A history of selected outputs is different from a claim that the same economic value can be uniquely assigned through every later transaction. When inputs combine or outputs split, a tracing narrative requires clearly stated assumptions about allocation.

In a hypothetical review, an earlier output contributes to a transaction that also consumes other outputs. Your evidence establishes participation in that transaction. It does not, by itself, specify which later output should be called the exclusive continuation of your selected amount. Preserve that limitation in the narrative rather than drawing a single dramatic path that conceals alternative interpretations.

The forensic search workflow emphasizes bounded questions and explicit stopping rules. You can stop after documenting a supported relationship. More hops do not automatically make a report stronger. A smaller, reproducible graph often communicates more accurately than a sprawling network whose edges rely on unrecorded assumptions.

Build an evidence packet another reader can use

Keep the transaction identifier, relevant outpoints, amounts, observed status, provider, and retrieval time together. Save the source links and any permitted exports used for your calculations. A screenshot can illustrate what you saw, but a complete reference lets someone inspect the selected record directly.

Separate externally supplied labels from your own wording. If an address is described as a service deposit in correspondence, state that this description came from the correspondence. Do not rewrite it as a fact encoded in Bitcoin's ledger. Keep personal information out of public notes unless there is a legitimate reason and appropriate authority to disclose it.

Before publishing, ask a second reader to verify the amount reconciliation and identify which conclusions depend on assumptions. The data coverage page clarifies that BlockDetective.com does not provide a proprietary ownership database. Your research packet should be equally candid about what the source records do and do not establish.

A useful conclusion is a bounded conclusion

A Bitcoin Block Detective note should answer the original question with the right degree of confidence. It may establish that a selected transaction consumed a particular output, created an output matching a supplied address, or showed a specified confirmation state when checked. Those are meaningful findings without an invented identity narrative.

Practice the distinction in the illustrative investigator workspace, where the graph and evidence panel are explicitly educational. Then return to the Bitcoin explorer starting point for an actual public-record lookup. Do not treat the sample graph as evidence about a real transaction.

The discipline is simple but demanding: preserve exact identifiers, reconcile quantities, name the source of each claim, and label inference. When the record stops answering the question, the conclusion should stop too. A clear boundary is part of the result, not an inconvenience to be removed from the report.