Following Bitcoin spends
The two ways Forensia follows Bitcoin forward and backward: an automatic largest-branch path and a manual step-by-step check.
#Plain languageIn plain terms
Bitcoin is unusually traceable in one respect. Every coin records exactly which earlier coins it came from, and every spent coin records which transaction spent it. Those links are exact.
What explodes is the number of branches. One transaction can have many inputs and many outputs, and each leads somewhere. Forensia offers two ways through: a quick automatic path that follows the biggest branch each way, and a manual mode where each step is verified.
#How it worksHow it works
Automatic path
From the searched transaction, the lookup steps backward along the largest input and forward along the largest spent output, two steps each way. It is a way to see the neighbourhood quickly.
Manual branch check
In the Overview view of a Bitcoin transaction, the "Follow spent outputs" panel lets you follow spent outputs one step at a time, with "Check starting transaction" and then "Check next transaction". Each step fetches a transaction and its spend status, confirms the link between parent and child, and queues the child's own spent outputs for the next step.
#Technical detailThe exact rules
Automatic path
| Limit | Value |
|---|---|
| Depth each way | 2 |
| Extra requests | 5 |
| Per request | 4 seconds |
Each of these requests is tried again if it gets no response at all, up to three attempts inside 8 seconds, under the same retry rule as the main lookup.
Going backward, the fetched parent must actually hold an output of the same value at the position the input refers to. Going forward, the fetched child must actually have an input that spends that exact output. A failed check is recorded as a linkage mismatch.
| The path stops at | Meaning |
|---|---|
| Depth budget | Two steps were taken. |
| Coinbase boundary | The input is newly mined coin. There is nothing earlier. |
| Unspent boundary | No output has been spent yet. |
| Linkage mismatch | Parent and child did not agree. |
| Source unavailable | The request failed. |
| No eligible output | No valid previous output, or no valid spending transaction ID, was available to follow. |
Manual branch check
| Limit | Value |
|---|---|
| Steps, including the start | 4 |
| Depth | 2 hops |
| Inputs per transaction | 64 |
| Outputs per transaction | 32 |
| Response size | 256 KiB |
A transaction is accepted only if it is confirmed, has no duplicate inputs, has no newly mined input, and its inputs equal its outputs plus the fee exactly. A link is marked matched only when the child is in the same or a later block (at the same height, the same block), exactly one of its inputs refers to the parent's output, that input sits at the position the index reported, and the value is equal. Steps are taken in output order, not by value.
Each step makes two requests, each with a 10 second timeout. A step is allowed exactly two requests, so a request that gets no response is not tried again: the step fails and still uses one of the four. If the original result recorded a block hash, the starting transaction must still be in that block, or nothing is accepted. A spent output whose spending transaction is the same transaction or the starting one is stopped as a cyclic reference and not queried.
#LimitsWhat it does not tell you
- The automatic path follows one branch each way. It is an attention aid, not a trace of where value went.
- With four steps, most multi-output transactions leave branches unchecked. Unchecked is not the same as unspent.
- A failed step still uses one of the four.
- An unspent output is unspent at the time of the lookup, not permanently.
- Neither mode groups addresses or assigns ownership.