Read a Bitcoin transaction explorer without getting lost

Start with the value flow

A transaction explorer packages chain and mempool information into a readable page. It can be useful, but the page is a view assembled by an operator. Its labels, visibility, and current chain observation matter.

Here is an original fictional example. demo-A is a teaching label, not a transaction hash that can be looked up on Bitcoin:

Field	Fictional value
Transaction label	demo-A
Input 1	Prior output demo-X:0, worth 60,000 sats
Input 2	Prior output demo-Y:1, worth 40,000 sats
Output 0	Destination R, 70,000 sats
Output 1	Destination C, 29,000 sats
Virtual size	200 vB, supplied for the exercise
Inclusion	Block 500-A, active tip at height 502

First add the inputs: 100,000 sats. Then add the outputs: 99,000. The difference is a 1,000 sat fee. Divide that fee by the example size to get 5 sat/vB.

Now count confirmations: if block 500-A is on the observer’s active chain ending at 502, the transaction has three confirmations. The result relies on that chain membership, not just matching height numbers.

Inputs point backward; outputs offer future spending

An input identifies a previous output using a transaction identifier and an output index. The explorer resolves that reference to show its value and conditions. The input is not intrinsically a named sender or account owner.

Outputs contain value and spending conditions. An explorer may render a recognizable address when it can express those conditions using an address format. Labels such as “change,” “exchange,” or “recipient” may rely on external information or heuristics. They are not all equivalent to raw transaction facts.

In our example we call C the change destination because the fictional wallet story tells us that. A stranger examining only the transaction would not have that same certainty. Likewise, two inputs in one transaction are not sufficient to identify a particular human.

A transaction identifier is useful for referring to a transaction; it is not a secret credential or a receipt proving an order shipped. Sharing it can reveal relationships and activity, so a support workflow should ask only for information it needs. This lesson uses fictional labels to avoid exposing anyone’s payment history.

Annotate evidence and inference

Mark each statement as record-derived, context-dependent, or unsupported:

1. The two input values sum to 100,000 sats.
2. Output C is change controlled by the sender.
3. A person named Noor owns destination R.
4. The payment has three confirmations on the stated active chain.
5. The merchant has shipped the order.

Expected answers: record-derived; context-dependent; unsupported; record-derived with the stated chain context; unsupported. In the story we supplied the change interpretation, but that is additional information, not a universal on-chain label.

A developer can repeat the field inspection using decoded transaction data from a controlled test environment. Compare the explorer’s presentation with vin, vout, vsize and available confirmation fields. Do not treat this fictional table as serialized Bitcoin data or copy its made-up identifiers into a production query.