Which input paid which output
Why that question has no single answer in Bitcoin, and the three accounting assumptions Forensia shows side by side.
#Plain languageIn plain terms
A transaction takes in several coins and pays out several coins. It is tempting to ask which incoming coin paid which outgoing one. Bitcoin does not record that. Inside a transaction, all the value is pooled.
Any answer is an accounting choice, the same way an accountant chooses how to treat stock that came in at different prices. Forensia does not pick one. It shows what three common assumptions would say, next to each other, so you can see how much the answer depends on the assumption.
#How it worksHow it works
- Take the transaction's largest input as the reference amount.
- Treat the miner fee as one more output, so it gets its share.
- Work out how much of the reference would land on each output under each of three models.
- Show all three.
The comparison is the "Compare allocation assumptions" panel in the Overview view of a Bitcoin transaction. It names the reference input, shows one column per model with the fee as its own row ("Transaction fee"), and links to the captured transaction response with "Inspect transaction source". The same table is written into the report.
#Technical detailThe exact rules
| Model | Assumption |
|---|---|
| Proportional | The reference is spread across all outputs and the fee in proportion to their values. |
| Input order | Inputs are used up in the order recorded, filling outputs in order. The fee comes last. |
| Reverse input order | The same, with the input order reversed. |
Proportional allocation works in whole satoshis: each output gets the rounded-down share, and the few satoshis left over are handed out one at a time in output order.
The comparison is only produced when the figures are complete and reconcile:
- the transaction is confirmed, with a recorded block number and block hash;
- exactly one captured response for that transaction can be identified in the result;
- it has between 1 and 16 inputs and between 1 and 16 outputs;
- every input's value is known, with no newly mined coin;
- inputs minus outputs equals the reported fee exactly.
If any of these fails, no allocation is calculated and the page says why.
Re-check against the saved response
When the transaction's raw response is retained in this browser's vault, "Check local evidence" compares the displayed input and output rows, the fee and the block context with that saved response. It fetches nothing. A response over 1 MiB, or a transaction beyond 16 inputs or 16 outputs, is left unchecked.
| Result shown | Meaning |
|---|---|
| Bitcoin inputs and outputs match saved response | Every recorded input and output, the fee and the block context agree with the saved response. |
| Bitcoin allocation check incomplete | The saved response was not available or was over the limit, the transaction is unconfirmed, an input is newly mined coin or has no value, or some rows are not displayed. No complete match is claimed. |
| Bitcoin allocation needs review | The displayed records disagree with the saved response. The comparison is replaced by "Allocation comparison needs review", and report, saving the result and combined raw export are blocked. |
A match means the display is consistent with what the index returned. It is not an independent check of the previous outputs or of Bitcoin's consensus rules, and it does not make any model more than an assumption.
#LimitsWhat it does not tell you
- No model establishes which actual satoshis reached a recipient. That information does not exist.
- The reference is always the whole largest input. You cannot choose a different one or part of one. If two inputs tie for largest, the earlier one is used.
- Input order is just the order in the transaction. It is not a claim about time or ownership.
- Allocation covers one transaction. It is not carried forward across hops.
- Transactions with more than 16 inputs or outputs are not supported.