Inputs are not identities

A Bitcoin transaction consumes previous outputs and creates new ones. A history page can calculate how much entered and left an address. That is useful arithmetic, but it does not, by itself, establish a person’s spending, income, or identity.

Read an address row carefully

For each confirmed transaction, ztrash adds the outputs sent to the selected address and subtracts the previous outputs spent from it. The result is the address’s net change in that transaction. When the same address appears among both inputs and outputs, the net change differs from both the input total and the output total.

In the 55 BTC example, the selected address first received 55 BTC and then had that output consumed. The spending transaction’s two outputs together contain 54.9998 BTC. The 0.0002 BTC difference is the transaction fee. Calling all 55 BTC “a payment to the next address” would erase both the split and the fee.

Multiple inputs make attribution harder

The funding transaction in that example had two inputs. The transaction establishes that those previous outputs were authorized for spending together. It does not reveal a person’s name, and the blockchain does not attach a unique mapping from each input’s coins to each new output. Collaborative transactions can also involve different participants.

When several inputs contribute to several outputs, following “the same coins” through a particular branch requires an allocation assumption. ztrash’s output inspector therefore checks the explicit output-to-spending-input relationship and leaves ownership and downstream allocation open.

Use a repeatable reading sequence

  1. Check the network, transaction identifier, block, and observation time.
  2. Reconcile inputs, outputs, and fees.
  3. For a spend claim, check the exact previous transaction identifier and output index in the spending input.
  4. Separate those facts from interpretations about payment purpose, change, or ownership.
  5. Record gaps before following another branch.

The Bitcoin developer guide to transactions explains the input and output model. You can reproduce this example from the saved evidence bundle and compare it with the live inspector.

Edition 1 · September 26, 2026 (Pacific). These are explanations of public provider observations, not identity findings. Each evidence bundle records its UTC collection time and file hashes. Corrections should identify the transaction, disputed statement, and supporting source; use the Support link in the site footer. Material corrections will be recorded in a new edition while retaining this evidence bundle.