Bitcoin transfer volume: separate change from payments
A large bitcoin transaction can move a small payment and a large amount of change. Summing every output therefore measures output value, not necessarily value transferred between different economic owners. Research on network usage needs a transaction-level bridge between these quantities before interpreting a rising volume chart.
The Bitcoin transaction guide describes inputs spending previous outputs and the creation of new outputs. That structure explains the measurement problem. The change classifications below are research assumptions; the protocol does not attach a universal “payment” or “change” label to every output.
Start with conservation, then add interpretation
For an ordinary transaction, collect each input’s referenced output value. Record every new output and calculate the fee as total input value minus total output value. Exclude coinbase reward transactions from this particular identity. Keep the amounts in satoshis while reconciling, converting to BTC only for presentation.
Next classify outputs as verified external payment, verified internal change, or unresolved. Verification might come from a wallet’s own records in an authorized dataset. Public address patterns alone generally support weaker classifications. A newly observed address can receive change, a payment, or a transfer within a custodian’s systems.
Do not assume the largest output is change. Nor does matching address format prove common ownership. Batch payments, collaborative transactions, wallet migrations and exchange operations can defeat simple rules. Preserve the raw output total even when producing an adjusted estimate so another reader can assess what was removed.
Hypothetical payment and change bridge
Assume a fictional wallet spends one 10 BTC output. It creates a 0.4 BTC payment and 9.599 BTC of change, paying a 0.001 BTC fee. The input is consumed in full, although the intended payment is much smaller.
| Item | Hypothetical BTC | Meaning |
|---|---|---|
| Input value | 10 | Previous output consumed |
| Recipient payment | 0.4 | External transfer, if verified |
| Change | 9.599 | Continued wallet ownership, if verified |
| Fee | 0.001 | Input minus output total |
Output volume is 9.999 BTC. Verified payment volume is 0.4 BTC under the stated ownership evidence. Dividing output volume by payment volume gives about 25, which illustrates the scale of a possible overstatement. It does not establish that a public dataset overstates all payments by that factor.
Now remove the wallet evidence. If both outputs are unresolved, report their values and the classification uncertainty. A provider’s heuristic may identify a likely change output, but that probability is not an observed transfer of beneficial ownership. Publish a conservative verified subtotal and an explicit unresolved amount rather than an invented precise economic total.
Audit a volume change
When measured volume jumps, compare transaction count, input count, output count and value per transaction. Inspect large contributors for consolidation or batching. Consolidation can move old outputs into one new output without representing purchases; batching can combine many payments into one transaction. Neither pattern has a universal effect on the number of customers.
Save the classification rule and its version. Rerun a small sample with alternative plausible change assignments and report how much the adjusted total moves. Keep ambiguous collaborative transactions in a separate bucket instead of forcing them into a one-sender narrative. An entity label should also have a dated evidence trail, since an address cluster may be revised.
The output is a measured-value reconciliation, a set of ownership assumptions, and an unresolved balance. It cannot identify a sale, payment purpose, or unique person from transaction amounts alone. Reopen the analysis when wallet evidence changes, the provider revises its clustering method, or a new transaction type materially changes the classification success rate.
Use a validation sample where ownership is independently known to estimate the classifier’s practical limits. Report false change assignments separately from missed change, since their effects on payment volume run in opposite directions. A sample drawn only from simple two-output payments will not test performance on the largest consolidations that dominate the value total.
FAQ
Does spending a 10 BTC input mean 10 BTC was paid to someone?
No. The transaction consumes that output, but some new outputs may return value to the same controller. Payment requires additional interpretation.
Should all likely change be deleted from raw data?
Keep raw records and a separate adjusted view. Disclose uncertain assignments and their numerical effect so the economic estimate remains inspectable.