BA-10 · LESSON 01

Common-input and change heuristics

KEY DEFINITIONS

Terms used in this lesson

Outpoint: A transaction ID plus output number that identifies one exact prior output.

Chain surveillance infers ownership from transaction structure; heuristics are probabilistic, not consensus facts.

35 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · privacy boundaryObservable evidence creates inferences, not automatic proofSelect any state to inspect its exact role.

RELATIONSHIP MAPCompeting paths and resolution

01
OBSERVABLEAmount, script, timing
Chain and network observers see different subsets of transaction and propagation data.
02
HEURISTICProbabilistic link
Wallet patterns can support a guess but do not prove a real-world identity.
03
RISKCommon-input and change heuristics
The Common-input and change heuristics lesson identifies which evidence or failure is in scope.
04
CONTROLReduce or separate evidence
Address discipline, coin selection, local verification, and routing choices change exposure.
05
RESIDUALExplicit remaining observer
Every mitigation leaves assumptions and observers that must be named honestly.

Rule shown: Privacy improves by reducing linkable evidence and separating observers, while preserving verifiable spending rules.

STAGE 1 OF 5OBSERVABLE: Amount, script, timing

Chain and network observers see different subsets of transaction and propagation data.

Governing relationship: Privacy improves by reducing linkable evidence and separating observers, while preserving verifiable spending rules. Complete path: 1. OBSERVABLE, Amount, script, timing. Chain and network observers see different subsets of transaction and propagation data. 2. HEURISTIC, Probabilistic link. Wallet patterns can support a guess but do not prove a real-world identity. 3. RISK, Common-input and change heuristics. The Common-input and change heuristics lesson identifies which evidence or failure is in scope. 4. CONTROL, Reduce or separate evidence. Address discipline, coin selection, local verification, and routing choices change exposure. 5. RESIDUAL, Explicit remaining observer. Every mitigation leaves assumptions and observers that must be named honestly.

1. State transitionWhat exists, what changes, and what results

BEFORE

A transaction has input 1 and input 2 from two users and outputs of 50,000 and 48,000 sats. It was built as PayJoin.

MECHANISM

Record input outpoints, output amounts and scripts, timing, and later spends. Do not label identity as on-chain data when it came from an exchange or investigator.

AFTER

Heuristics can prioritize hypotheses, but metadata and collaborative patterns determine confidence.

Text equivalent: Starting from A transaction has input 1 and input 2 from two users and outputs of 50,000 and 48,000 sats. It was built as PayJoin. The mechanism begins when Record input outpoints, output amounts and scripts, timing, and later spends. Do not label identity as on-chain data when it came from an exchange or investigator. The resulting lesson is Heuristics can prioritize hypotheses, but metadata and collaborative patterns determine confidence.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Observe only public facts

Record input outpoints, output amounts and scripts, timing, and later spends. Do not label identity as on-chain data when it came from an exchange or investigator.

Complete path: 1. Observe only public facts: Record input outpoints, output amounts and scripts, timing, and later spends. Do not label identity as on-chain data when it came from an exchange or investigator. 2. Apply a named heuristic: State the rule and reason for each guessed cluster. Common-input inference is stronger for ordinary wallet payments than for CoinJoin, PayJoin, or multi-party funding. 3. Score alternative change outputs: A unique new script type, round payment amount, wallet fingerprint, or later co-spend may suggest change, but none is universal. 4. Propagate with uncertainty: A mistaken cluster can contaminate later conclusions. Keep evidence strength and competing explanations attached to every inferred link. 5. Test against known exceptions: Collaborative construction, batching, self-transfer, sweep, and manual coin control can deliberately or accidentally violate wallet-pattern assumptions.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

The analyst scores only observable script, amount, reuse, and later-spend clues, retains tied candidates, and labels every ownership conclusion as inference rather than consensus fact.

CHANGED CONDITION

PayJoin or tied output clues defeat a forced single-owner or change label, and supplied real-world owner names cannot be treated as on-chain evidence.

Important distinction: Inputs appearing together prove they have one owner. They prove coordinated authorization for one transaction. One owner is often a useful guess, but collaborative protocols and multi-party funding are counterexamples.

Text equivalent: The accepted path is enforced by The analyst scores only observable script, amount, reuse, and later-spend clues, retains tied candidates, and labels every ownership conclusion as inference rather than consensus fact. If the required condition changes, PayJoin or tied output clues defeat a forced single-owner or change label, and supplied real-world owner names cannot be treated as on-chain evidence.

Loading lesson visuals...

Learn the idea

A blockchain heuristic is an inference, not a consensus fact. The common-input-ownership heuristic guesses that inputs in one transaction share an owner because one constructor needed their signatures. A change heuristic guesses which output returns to the spender using script type, amount, address reuse, and transaction pattern. Collaborative transactions create important exceptions.

GUIDED EXPLANATION1/5 ideas inspected

Observe only public facts

Record input outpoints, output amounts and scripts, timing, and later spends. Do not label identity as on-chain data when it came from an exchange or investigator.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“Inputs appearing together prove they have one owner.”

They prove coordinated authorization for one transaction. One owner is often a useful guess, but collaborative protocols and multi-party funding are counterexamples.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.