Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

🤖 Consolidation penalty

A privacy liability term of the cost function. Spending several own coins together adds exposure to intersection attacks, which the term models as compounding with each additional coin. Subset-sum density and counterfactual routes jointly attenuate the penalty: the contribution of each depends on the other. The penalty is fully discharged when both meet their thresholds.

  • Why unbounded. Consolidation may leave the wallet worse off than its baseline, so the liability can exceed 1 and its associated reduction in subjective value can exceed the remaining privacy budget. Other terms may still outweigh this cost; the penalty does not categorically prohibit consolidation.
  • Density alone isn’t enough. Comparing the ancestor sets of pairs of inputs narrows down an intersection efficiently, even in a large transaction.

Consolidation exposes the inputs’ histories to comparison, so the route analysis considers their combined ancestry. Its measurements describe counterfactual connectivity between each input and the coins through which any of the consolidated funds first entered the wallet. Combining these measurements into a scalar would quantify how thoroughly the inputs’ histories have become connected through other users’ transactions. This measure of absorption would inform the consolidation liability alongside subset-sum density. The aggregation rule remains to be specified.

The routes factor uses the route counts of the Counterfactual paths to label the wallet’s coins, and the combined ancestry of the inputs.

Definition

The following parameterization uses per-coin route labels. Incorporating a joint measure of absorption into this parameterization remains an open question.

  • : the own inputs of the transaction under consideration, each with a label , the degree to which meets the counterfactual-route objective.
    • The labels are defined in Labels.
  • Links. .
  • Linked count. .
    • A single coin gives , and so does one coin below the route threshold spent with coins that meet it.
  • Routes. , and for a single coin.
  • Density. .
    • is the covered fraction of the subset sum ambiguity term for own input .
    • While decisions are evaluated, it checks against , the other users’ inputs known so far. After the fact, it also checks it against , the other users’ outputs.
    • , with well above that term’s .
      • : the number of doublings of over which rises from 0 to 1.
  • Liability. , with the factor per intersection.
    • Thresholds. once . once every input but one has , i.e. routes.
    • For more than one own input, it’s 0 only when both meet their thresholds.
    • The relief from each is proportional to the other: . With , density relieves nothing, and with , routes relieve nothing.

Labels

For each own coin :

  • Origins. is the set of coins by which the wallet received the funds descends from.
  • Routes. , with the wallet’s own edges omitted.
  • Label. rises with and reaches 1 at , the chosen route threshold. For example, .
  • Use. At , adds nothing to the linked count .

Everything depends on exists once confirms: the coins between its origins and , the other coins in their transactions, and their link probabilities. So is fixed from then on, and labels are cached per coin.

From bounds

With the bounds and :

  • uses , so it’s never overstated.
  • If , is impervious.
  • If , it isn’t, and more sampling won’t change that.
  • Otherwise, take more walks, or compute exactly on a pruned graph.

Combined ancestry

Spending own coins together links them. An intersection attack then intersects their candidate origins.

  • Union. : every coin by which the wallet received funds that any of them descends from.
  • Routes matrix. , for each and .
    • It’s a bipartite graph from to , with each edge labelled by its routes, written as a matrix.
    • Each entry is one max flow. Entries already computed for a coin’s own origins carry over: is the minimum of row over .
  • Reading it. Row shows which origins has many counterfactual routes from. When every row is high in almost every column, each input’s candidate origins cover almost all of . The sets the adversary can intersect then have a small symmetric difference, so intersecting them reveals little.
    • “Almost every” is read off , not fixed in advance. For example, the columns where one row is at least and another isn’t are what an intersection of those two inputs can reveal.
  • Aggregation. A candidate absorption index aggregates shortfalls in pairwise connectivity. Its parameters and its mapping to the consolidation liability remain to be determined.
  • Counterfactual superconcentrator. The graph of other users’ edges only.
    • Sources: the earliest ancestor coins, .
    • Sinks: the inputs under consideration for consolidation, .
    • The aim is counterfactual routes across it, making it a superconcentrator: for every , any sources and any sinks are joined by disjoint paths.

Candidate absorption index

One candidate aggregates the shortfall of each input–origin pair from a connectivity objective. For this purpose, use the unrounded flow ratio , retaining fractional values rather than the integer route count . Let be the objective and the degree to which a pair meets it. Saturation prevents additional flow for an already sufficient pair from providing further compensation for weak connectivity elsewhere.

For nonnegative weights summing to 1 over the input–origin pairs, define

At , this is one minus the root-mean-square shortfall. Larger gives weak pairs more influence; as tends to infinity, approaches the weakest score with positive weight. Finite permits strong coverage to compensate for incomplete coverage, while each improvement below saturation increases the index for a pair with positive weight. If a fraction of the weight has score 0 and the rest has score 1, then .

The weights must represent the exposure being evaluated, rather than the number of sampled paths. Their choice remains open, including how to prevent splitting funds or repeating observations from manufacturing credit. The index is a connectivity measure, not an attack-cost estimate. Incorporating Sybil resistance along the supporting paths remains to be specified: an adversary may create apparent alternatives through prior CoinJoins, and the expenditure supporting several pairs cannot be counted as a separate expenditure for each pair.

A possible extension first computes a coverage score for each input across origins, and for each origin across inputs, using a power mean with exponent . It then takes a power mean of those profiles’ shortfalls, with exponent , and subtracts it from 1. This distinguishes missing connections concentrated around one input or origin from missing connections spread across them, which the single mean does not. It adds a parameter and requires weights at both levels. Neither formulation by itself establishes that a high score makes a targeted intersection attack prohibitively expensive.

In the decision tree

  • It’s a privacy-related term.
  • Fixed per coin. Once a coin confirms, no later block adds to its ancestry. So , and the entries of for confirmed inputs, are computed once and reused in every leaf. Over time, they’re constant.
  • A leaf’s inputs. A leaf fixes the own inputs , and with them and the rows of . Nothing other users add to the transaction changes them, so the best and worst cases of the labels and are equal.
  • Outputs. The transaction’s own outputs get labels only after it confirms.
  • Order book coins. The own inputs’ coin edges are omitted, so routes from their origins into the transaction’s own outputs enter only through other users’ inputs.
    • An order book coin that descends from those origins adds routes, so selecting it is valuable.
    • A co-spend proposal from an own input that names such a coin links the two, unless such proposals are already common. An outcome may still prefer the selection, but the cost function should penalize proposals that leak the link this way.
  • Bounds. Leaves use from , the lower bound. Tightening , with more walks or an exact on a pruned graph, can run between iterations of the decision loop in the Mixed strategy chapter. It can only raise .
  • Worst case: checks only the other users’ inputs known so far. Their outputs aren’t known until the transaction has been fully built.
  • Best case: , which is used for pruning.
  • is unbounded, so its associated reduction in subjective value can exceed the remaining budget. An automated action requires a predicted improvement under the full cost-function evaluation. Consolidation-heavy branches are pruned when that evaluation cannot justify them; evidence that improves the lower bound can reduce the penalty and change the decision.
  • More aggressive consolidation can nevertheless have a better best-case evaluation because of feerates, batching opportunities, or reduced fragmentation. That best case alone does not justify execution under the current lower bound.
  • It applies to every own output of the transaction. The reduction in subjective value scales with their total value, independently of the number of outputs.

After construction

  • Once the transaction is fully constructed, is computed from the complete sets and the same cost function is evaluated with that information. This determines the liabilities and the accounting for privacy-budget expenditure, as described in Cost function structure. An explicit manual override resets liability accounting to the baseline.

Evaluating the wallet state

  • The term can evaluate a wallet state too. Imagine that an emergency forces the user to spend all of its coins rapidly in one unilateral transaction, and take that transaction’s consolidation penalty. This favors arranging the wallet state to minimize the privacy damage if such a liquidation becomes necessary.
  • That transaction’s cost includes its objective costs, e.g. the fees for each coin, so this also prices a wallet split over many coins.
  • It depends on the open question about transactions with only the wallet’s own coins. Until that’s settled, there, and every state with more than one coin gets the full penalty.

Monotonicity

  • can only fall as rises, or as the labels rise.

Open questions

  • How should the absorption index determine the route factor? The candidate shortfall mean and its grouped extension describe possible aggregation rules; their weights, parameters and resistance to manipulation remain to be evaluated.

  • Should siblings also count towards ?

  • A transaction with only the wallet’s own coins has no other users’ coins, so and the penalty can’t be discharged. Which density applies there? For example, the covered fraction of the outputs that became the inputs, in the transactions that created them.

  • How should and be scaled?

  • What link probabilities apply to the transaction under construction? They must hold in every completion.

  • Which term penalizes a co-spend proposal that leaks a link to an order book coin that adds routes, and how is “already common” measured?

  • How is the routes factor computed: from each input’s , as the definition does now, or from the counterfactual superconcentrator condition?

  • How is the counterfactual superconcentrator condition checked? It ranges over sets of sources and sinks of equal size, while holds only single pairs.

  • Should ramp up to , or switch from 0 to 1 at ? What should be?

  • May use an estimate (, the analytic estimate or Monte Carlo) when the randomization evidence is strong, or only ?

  • What label does an own input get before it confirms, such as change from a transaction still in flight?