Privacy at Scale — Paying by Many Small Notes on Bitcoin
Why thousands of tiny, standard transactions beat one big payment for practical privacy
Keywords: Bitcoin, privacy at scale, IP-to-IP, ECDH, P2PKH, UTXO, note-splitting, disjoint inputs, per-note change, broadcast pacing, selective receipts, Merkle proofs, auditability, deterministic derivationSubscribe
Introduction: privacy as an emergent property
Payments attract attention when they are rare, large, and distinct. A single, high-value transfer is a lighthouse on the ledger: it stands alone in amount, timing, and shape, and so it invites scrutiny and linkage. By contrast, many small, ordinary transfers dissolve into background flow. They are numerous, similar to countless others, and individually unremarkable. Privacy in this setting is not a switch to flip but an emergent property of scale: as independent, indistinguishable events accumulate, an outside observer’s ability to tell a coherent story about “who paid whom, when, and how much” diminishes.
This essay operates within a precise scope. Two parties—payer (Alice) and payee (Bob)—communicate over a direct, authenticated IP-to-IP channel sufficient to exchange small UTF-8 JSON messages and raw transactions. Transport specifics are deliberately out of scope; any authenticated path will do. Settlement happens on-chain using standard transactions and keys already native to Bitcoin. Identity keys authenticate the off-chain exchange and never appear on-chain. Examples in what follows are illustrative only; numbers, amounts, and timings serve to explain mechanisms rather than prescribe fixed values.
The core contribution is a practical recipe built from three ingredients: scale, independence, and diversity. Scale means decomposing a total into hundreds or thousands of bounded notes that each look like everyone else’s small payment. Independence means that every note is valid on its own, pays to a unique recipient address, uses inputs that no other note shares, and—if change is needed—returns it to a unique, per-note sender address. Diversity means that notes need not travel together: either party may broadcast any subset; announcements can be paced over windows, routed through different peers, and interleaved with other activity. Taken together, scale + independence + diversity yield practical privacy without exotic machinery.
Accountability is preserved by receipts that bind the entire set while allowing selective disclosure. A compact commitment to all notes can be published or archived, and later any chosen subset can be proven without exposing the rest. Thus, insiders retain a deterministic, auditable view of what was intended and what occurred, while outsiders face a sea of small, standard events that resist reliable linkage. The thesis is simple: do more of the ordinary thing, do it independently, and do it with varied timing and paths; privacy follows from the crowd.
Background and model (actors, channel, ledger)
Roles. Two principals participate. The payer (Alice) authorises spend of her own UTXOs and is responsible for input selection, fee policy, and constructing standard transactions. The payee (Bob) receives funds to addresses he alone can spend and publishes intake policy (minimum/maximum per note, fee-rate floor, optional pacing). Each party holds an identity keypair used only to authenticate off-chain messages, and a public anchor point used only to derive on-chain settlement keys. Identity keys never appear in locking scripts; anchors are public curve points meant for derivation, not for signing transcripts.
Channel. The parties speak over a direct, authenticated message path capable of exchanging small UTF-8 JSON objects and raw transactions. Transport specifics are deliberately out of scope: any medium that preserves integrity and endpoint authentication is acceptable (e.g., mutually signed messages over TCP, QUIC, or a relay). Messages are compact: policy, invoice, per-note metadata, and lifecycle events (broadcast, reissue, cancel). Where a shared element is required (for scoped derivations), it is computed from the identity keys; where authenticity is required, records are signed as canonical JSON. The channel never carries private spend keys and need not be private beyond authentication; privacy derives from on-chain structure and scale.
Ledger. Settlement uses ordinary P2PKH transactions on Bitcoin. For each note, Alice funds inputs and pays a bounded amount to a unique recipient address derived from Bob’s anchor; optional change returns to a unique sender address derived from Alice’s anchor. All keys live on secp256k1; hashes are SHA-256 and RIPEMD-160 in the usual address construction. Notes are independent: each has disjoint inputs, its own outputs, and can be broadcast, confirmed, and audited without reference to any other note. Confirmation depth chosen by the recipient defines finality per note.
Adversary classes.
A1 — passive chain analyst who parses blocks and mempools, observing scripts, amounts, and timing; cannot break SHA-256, RIPEMD-160, or the discrete-log problem on secp256k1.
A2 — passive network observer who records first-seen announcements and peers; cannot alter payloads.
A3 — inquisitive counterparty who knows their own transcripts and anchors but not the other party’s private scalars.
A4 — data broker who correlates leaked off-chain artefacts (policies, manifests) with public chain data.
The model aims to deny these adversaries reliable linkage across notes by using per-invoice scope, per-note keys, disjoint inputs, and broadcast diversity at scale.
Why scale wins: intuition and simple math
Privacy grows in crowds. One conspicuous transfer is easy to point at; a hundred small, ordinary transfers look like everyone else’s noise. The intuition is simple: indistinguishability rises with crowd size. When an observer stares at a busy hour on the ledger and finds a thick band of small outputs that all look alike, each individual note can plausibly be “one of many,” and the story of who paid whom blurs.
A back-of-envelope model makes this concrete. Partition time into hourly bins t = 1…H. In each hour t, let m_t be the number of outputs on the ledger that fall within the same small-value band you use (for example, 0.50–2.00 units). If you place a single note in hour t, a passive analyst who only knows “it is somewhere in that band” faces ≈ log₂ m_t bits of uncertainty: any one of the m_t candidates could be yours. If you place K notes across H hours, with k_t notes in hour t and Σ_t k_t = K, a crude lower bound for the analyst’s assignment uncertainty is
privacy ≳ Σ_t k_t · log₂ m_t.
This says two things plainly. First, bigger crowds help: large m_t pushes up log₂ m_t. Second, spreading notes across more hours multiplies uncertainty additively. If the band is busy (say m_t ≈ 2 000 in active hours) and you spread notes over a dozen hours, every hour contributes ≈ 11 bits; a few dozen notes already force the analyst into a combinatorial swamp.
Independence matters as much as scale. If each note uses disjoint inputs, pays a unique recipient address, and sends any change to a unique sender address, the usual link hooks (shared inputs across notes, shared change) disappear. Index-to-amount correlation vanishes when you permute the split; timing patterns smear when you pace announcements rather than blast all at once. These choices ensure that even if m_t is healthy, you are not undoing the effect by leaving tidy fingerprints.
There are caveats. The arithmetic above is not a proof; it is a sanity check. Real observers mix amount bands, timing windows, and first-seen network gossip; not all hours are equally busy; your own notes are not fully independent if you reuse change or overlap inputs. The fix is the same as the thesis: more, smaller, independent, and diverse. Use the whole band, avoid neat sequences, forbid intra-invoice change reuse, vary who announces and when. With those disciplines, the qualitative picture holds: Σ log₂ m_t grows, the search space explodes, and the outside view collapses into ambiguity while the inside view remains deterministic and auditable.
Invoice-scoped determinism
Determinism begins with scope. For each invoice, the parties derive two shared anchors of computation: Z, a shared element obtained via ECDH between the identity keys; and H_I, the SHA-256 fingerprint of the invoice encoded as canonical UTF-8 JSON. The pair {Z, H_I} is the scope tuple. Nothing leaves this tuple during derivation, and nothing outside it can reproduce what the parties compute inside it. Scope is one-time per invoice: H_I MUST be unique, and Z is specific to the two participants, so reusing either across invoices is forbidden.
Every derivation binds to this scope with explicit domain labels to prevent cross-talk. Recipient keys use the “recv” label: for note index i, the payer computes a per-note tweak from (Z ∥ H_I ∥ "recv" ∥ LE32(i)), adds it to the recipient’s public anchor, and obtains a unique settlement key for that note. Only the recipient, who knows the corresponding private anchor, can spend; identity keys never appear on-chain. Sender change keys use the “snd” label and the same index i, producing a per-note change address that is guaranteed not to collide with any recipient derivation. The amount split uses the “split” label to seed a deterministic PRNG that yields a vector a[0…N−1] with bounds v_min ≤ a[i] ≤ v_max and exact sum ∑ a[i] = T, followed by a permutation so indices do not correlate with sizes. Broadcast pacing (when used) takes the “pace” label to derive a reproducible schedule of gaps and bursts. Labels ensure that even with the same {Z, H_I} and index i, “recv”, “snd”, “split”, and “pace” live in disjoint namespaces.
Two consequences follow. First, symmetry: both sides, working independently from the same inputs {policy, invoice, anchors} and the same scope {Z, H_I}, compute identical outputs—recipient addresses, sender-change addresses, split amounts, and an optional timing plan—without exchanging per-note data. Second, isolation: derivations for one invoice cannot be reused or recognised in another, because H_I changes; even the same index i under a new invoice yields unrelated keys and amounts. With reject-zero handling done deterministically (e.g., counter bump if a scalar reduces to 0 mod n), implementations also agree on edge cases. In short, scope + labels give a reproducible function from shared facts to per-note artefacts, enabling two peers to act in lock-step off-chain while keeping on-chain activity standard, independent, and unlinkable across invoices.
Note-splitting within bounds
The split begins with two public bounds, v_min and v_max, that define the allowed size of each note. Given a total T, feasibility is checked by the simple inequalities N_min ≤ N ≤ N_max, where N_min = ⌈T ÷ v_max⌉ and N_max = ⌊T ÷ v_min⌋. If N_min > N_max, the invoice is infeasible and must be rejected before any construction. All arithmetic is done in the smallest settlement unit to avoid rounding drift; v_min, v_max, T, and every aᵢ are integers in that unit.
A deterministic seed S is derived from the invoice scope using a dedicated label (for example, S := H(Z ∥ H_I ∥ “split”)). From S, both parties draw the same reproducible stream of pseudo-random values to make identical choices without coordination. First, select the count N in the closed interval [N_min, N_max]. The selection is interior-biased unless forced to an edge: when many counts are feasible, prefer the middle to avoid a pattern (e.g., always picking N_min). Next, generate the amounts a[0…N−1] with prefix clamping so the remainder never becomes infeasible. At step i (0 ≤ i < N−1), compute the feasible interval for aᵢ given the current remainder rem and the remaining slots slots = N−1−i:
• low := max( v_min, rem − v_max × slots )
• high := min( v_max, rem − v_min × slots )
Draw aᵢ uniformly from [low, high] using the stream from S; set rem ← rem − aᵢ. When i = N−1, set a_{N−1} := rem. By construction, each aᵢ satisfies v_min ≤ aᵢ ≤ v_max and ∑ aᵢ = T. Because the interval [low, high] is recomputed at every step from rem and slots, it is never empty when N ∈ [N_min, N_max]; thus the procedure terminates without backtracking.
To prevent any accidental correlation between indices and sizes, apply a deterministic permutation to the finished vector a. Seed a second stream S_perm (for example, H(S ∥ “permute”)) and run a Fisher–Yates shuffle over the array. Both sides now hold the same multiset of amounts in a different, reproducible order; an outside observer cannot infer the original construction sequence from index positions.
“Illustrative only” example: for a total of £800 with bounds £0.50 ≤ aᵢ ≤ £2.00, the feasible range is 400 ≤ N ≤ 1 600. A typical interior choice might yield N around the middle of that interval, and the prefix-clamped draws would then produce hundreds of amounts in the allowed band that sum exactly to £800. After permutation, no structural clues remain: indices do not reveal sizes; sizes do not reveal order. The result is a crowd of small, standard notes that are individually unremarkable yet collectively exact.
Per-note addresses and change
Each note uses its own settlement keys, derived deterministically within the invoice scope so the payer can address every note while the payee alone can spend it. Let B = b·G be the payee’s public anchor and A = a·G the payer’s public anchor on secp256k1; G is the generator, n the group order. Identity keys authenticate messages off-chain and never appear in locking scripts on-chain.
Recipient address per note (sender can address; recipient alone can spend).
For index i, both parties compute a tweak scalar tᵢ from the scope tuple {Z, Hᴵ} using explicit domain separation:
tᵢ := int( SHA-256( Z ∥ Hᴵ ∥ "recv" ∥ LE32(i) ) ) mod n, with a reject-zero rule (if tᵢ = 0, deterministically bump a counter until non-zero).
The sender then derives the per-note recipient public key: Pᴮ,ᵢ = B + tᵢ·G, and encodes a standard pay-to-pubkey-hash address Addrᴮ,ᵢ := Base58Check(0x00 ∥ RIPEMD-160(SHA-256(serP(Pᴮ,ᵢ)))). Only the payee can spend, because the corresponding private key is kᴮ,ᵢ = (b + tᵢ) mod n, which the sender cannot compute without knowing b. Outsiders who see serP(Pᴮ,ᵢ) across multiple notes cannot test for common origin: for any two curve points X and Y there exists some Δ such that Y − X = Δ·G, so the relation is uninformative without tᵢ or b.
Sender change per note (no shared-change clustering).
Change, when it exists, must never tie notes together. For the same index i, derive a second tweak with a different label:
sᵢ := int( SHA-256( Z ∥ Hᴵ ∥ "snd" ∥ LE32(i) ) ) mod n, with the same reject-zero rule.
Compute the per-note sender change public key Pᴬ,ᵢ = A + sᵢ·G and its address Addrᴬ,ᵢ analogously to Addrᴮ,ᵢ. If a note produces change, it returns to Addrᴬ,ᵢ and only Addrᴬ,ᵢ for that i. The wallet forbids using change from note i to fund any other note j ≠ i within the same invoice. This “one-note, one-change-address” rule eliminates the shared-change heuristic that commonly links transactions.
Why this structure matters.
• Privacy. Domain labels (“recv”, “snd”) and the invoice fingerprint Hᴵ ensure that keys for one invoice cannot be correlated with keys for another; even the same index i yields unrelated keys across invoices. Without Z and Hᴵ, outsiders cannot regenerate the address sets. Since identity keys never appear on-chain, off-chain personas are not exposed in scripts.
• Determinism. Given {Z, Hᴵ, A, B} and i, both parties compute identical Addrᴮ,ᵢ and Addrᴬ,ᵢ without exchanging per-note data. Reject-zero handling is deterministic, so edge cases match across implementations.
• Auditability. Internally, either side can recompute every address from logs to verify that each note paid the intended recipient and, where applicable, returned change to its unique sender address. Externally, nothing in the on-chain form distinguishes these outputs from ordinary P2PKH payments.
The result is a clean separation of roles: identity keys for authenticated dialogue only; anchors for settlement derivations; per-note keys for unlinkable receipts and change.
Disjoint inputs and minimal linkage
Disjoint funding is the backbone of unlinkability across notes. At invoice start the payer takes a snapshot of her spendable UTXO set U₀ and constructs a reservation table R that maps each note index i to a dedicated input set Sᵢ. The rule is strict: for all i ≠ j, Sᵢ ∩ Sⱼ = ∅. Once an outpoint is placed in Sᵢ it is logically locked to that note for the life of the invoice; it is removed from the working pool and cannot be “borrowed” to top up Sⱼ. This is not a performance tweak but a privacy guarantee: overlapping inputs are a primary link hook used by chain analysts to cluster transactions as coming from the same wallet event. By eliminating overlap across notes, the only multi-input clustering that remains is within a single note, which is acceptable because that note is already a unit of payment.
The reservation procedure is deterministic. UTXOs are listed in a fixed order (for example, value ascending, then txid ascending, then vout ascending), note targets are processed in a fixed order (for example, larger amounts first, then by index), and a bounded-knapsack policy prefers exact matches, then single-input near-over, then the fewest inputs with minimal change. Candidates that would produce dust change or violate the fee floor are rejected and reseated. If granularity is too coarse to satisfy all targets, a single preparatory fan-out (payer to payer) may be performed outside the note set to create smaller UTXOs; after it settles or is risk-accepted per policy, reservations are rebuilt from a fresh snapshot. Every selection step is recorded so two independent implementations produce byte-for-byte identical R given the same U₀ and parameters.
Change reuse inside the invoice is banned. If a note produces change, that output returns to its unique per-note sender address and remains out of scope for funding any other note of the same invoice. This prohibition removes the second common link hook: shared change. Analysts frequently tie transactions together when they see funds exit multiple transactions to the same change destination; here, that pattern cannot occur by construction.
The combined effect is simple to state and powerful in practice: no input overlap across notes, no shared change across notes, deterministic selection, and an append-only log of reservations. Notes become independent islands—each fully funded, fully signable, and eligible for broadcast—without leaving the structural fingerprints that typically bind a set together.
Broadcast diversity and pacing
Broadcast is symmetric by design: either party may submit any subset of notes at any time, and duplicate submission of identical bytes is benign because identical transactions share the same txid and are deduplicated by nodes. This symmetry is not a convenience; it is a privacy tool. When only one side announces everything, first-seen heuristics can attribute the whole set to that origin. When both sides announce overlapping subsets, the “who sent it first” signal fractures and ceases to be a reliable binder for the set.
Three practical strategies cover most needs. All-at-once floods every note immediately; it is simple and sometimes appropriate when the background rate of small transactions is high, but it creates a burst that can be grouped by a sliding time window. A paced window spreads announcements over an interval with bounded gaps (for example, a minimum spacing to respect rate limits and a maximum to guarantee completion), adding small deterministic jitter so the schedule does not look like a metronome. Bursts partition notes into batches of size β and send each batch separated by a gap; within a burst, a tiny offset per note breaks tie-ordering. In all cases, parties can vary the first announcer per note (some by the payer, some by the payee) and vary route selection (different peers or relays) to diversify network entry points.
The effect on standard heuristics is direct. First-seen-peer attribution weakens when two endpoints announce disjoint subsets at different times. Time-window clustering weakens when notes are spread across hours or days with jitter rather than emitted as a single spike. Path diversity blunts assumptions that a contiguous set entered the network from the same place. Because each note is already independent on-chain—disjoint inputs, unique recipient address, unique change address—the removal of strong timing and origin signals leaves far fewer handles for an outsider to grasp.
Operationally, pacing remains deterministic and auditable. If a schedule is used, both parties can compute the same nominal plan from shared scope without exchanging per-note timing, ensuring that a later audit can confirm intent. Hold-time timers protect against stalled queues by triggering reissue or cancel actions, and periodic rebroadcast keeps unconfirmed notes alive without creating a distinctive heartbeat. The result is broadcast that looks like ordinary traffic: varied in time and path, split between voices, and therefore difficult to cluster reliably from the outside.
Receipts and selective disclosure
Receipts bind the whole note set without forcing public disclosure of its parts. For each note i, both parties compute a fixed-width leaf Lᵢ that commits to the essentials: index i, the transaction identifier txidᵢ (32 bytes), the amount aᵢ (8-byte little-endian), and the address payload (version byte ∥ 20-byte pubkey hash). The leaf is the SHA-256 of that byte-exact concatenation; no Base58 text, no variable formatting, no whitespace. Ordering is deterministic: leaves are listed [L₀, L₁, …, L_{N−1}] by ascending i. A binary Merkle tree built left-to-right over this list (with the usual “duplicate the last node” rule for odd layers) yields a single 32-byte root M that commits to the entire invoice. This root is the receipt for the set.
From there, accountability is simple and selective. A compact manifest stores just enough to cross-reference on-chain data later—typically the pair (i, txidᵢ) for each note—plus the root M and the invoice fingerprint H_I that scopes the set. To prove that a particular note i was part of the committed set, the prover reveals only the leaf data for i and its Merkle path πᵢ (the sequence of sibling hashes and left/right positions from the leaf to the root). Any verifier can recompute Lᵢ from the disclosed fields, fold the path in order, and check that the result equals M. Everything else remains hidden: the amounts and addresses of undisclosed notes, their positions, even their count beyond what the manifest states.
Selective disclosure scales naturally. You may present multiple independent leaf proofs or package them as a multi-proof that shares siblings when paths overlap. In both cases, the verifier learns only what you intend—chosen (i, txid, amount, address payload)—and nothing about the remainder. Because leaves encode binary payloads (not display strings), there is no ambiguity over encodings, padding, or case. Because M binds the ordered list of leaves, any attempt to reorder, insert, or remove notes breaks verification immediately.
These receipts enable audit without surveillance. Internally, the parties can archive M, the manifest, and signed logs; later, they can reconstruct every leaf and the root to confirm that exactly one transaction per index settled. Externally, they can satisfy narrow evidentiary requests by revealing only the minimal set of leaves and paths that support a claim. No new cryptography is required—just careful byte-level encoding, deterministic ordering, and a standard Merkle construction—yet the result is a strong, tamper-evident commitment to the whole without forfeiting the privacy of its parts.
Limits, risks, and operator guidance
No privacy system erases structure; it redistributes it. This approach shifts structure away from the recipient’s side and into places that are operationally acceptable, but some fingerprints remain and must be managed.
Residual payer clustering persists within individual notes. Each note may use multiple inputs from the payer’s wallet, and the classic multi-input heuristic will still cluster those specific inputs to the payer. That is expected: a note is a unit of spend, and the payer is not the privacy target here. The goal is that across notes in the same invoice there are no durable links back to the recipient. You achieve that by enforcing two hard rules: Sᵢ ∩ Sⱼ = ∅ for all i ≠ j (no input overlap across notes) and “no intra-invoice change reuse” (change from note i never funds note j). Break either rule and you re-introduce the very hooks analysts use to stitch a set together.
Amount-shape and timing-shape are the next pitfalls. Humans like patterns; analysts love them. Avoid tidy sequences such as long runs of identical amounts, arithmetic progressions, or obvious round-number bias. Use the whole band [v_min, v_max], not just its ends, and permute the final vector so indices have no correlation with sizes. On timing, resist the urge to “get it done now” with a single burst at a memorable minute. Pace across a window with bounded jitter or send in small bursts separated by gaps; vary which party announces first and through which peers. Even trivial diversity in time and route erodes first-seen and sliding-window clustering.
Policy publication versus practice deserves care. Publicly advertise bounds that are wider than the ones you actually enforce, then operate within a tighter internal band. Outsiders who infer a coarse range from on-chain amounts will be pushed toward the public interval, not your true operating window, increasing deniability without changing any primitive. Document both sets internally so audits remain precise.
Finally, operational hygiene matters more than cryptography here. Enforce reject-zero in derivations; log every reservation and state transition with canonical JSON and detached signatures; monitor for external conflicts and rebuild reservations on any hint of overlap; rebroadcast orphaned confirmations rather than reconstructing. Treat pacing schedules as advisory and be willing to switch announcers mid-stream. Done together, these disciplines keep recipient linkage low, preserve payer accountability, and ensure that privacy is earned by scale, independence, and variety—not by wishful thinking.
Failure handling in brief
When things go wrong, the wallet behaves deterministically and leaves an auditable trail. Four cases cover most reality.
• Insufficient inputs → single fan-out, then fail cleanly.
At reservation time, if the snapshot of spendable UTXOs cannot fund all notes within bounds (either total value is short or granularity is too coarse), perform exactly one preparatory fan-out from payer→payer. This creates smaller UTXOs outside the note set; it never pays the payee and never reuses intra-invoice change. Once the fan-out is confirmed (or risk-accepted per policy), rebuild the reservation table from a fresh snapshot. If funding is still insufficient, abort the invoice before any note is issued or queued. Record a signed failure entry with reason "insufficient_utxo" and whether a fan-out was attempted.
• Pre-broadcast fee change → reissue; same index, same addresses.
If fees rise before a note is broadcast, reissue that note i. Select a new disjoint input set Sᵢ′, recompute size and fee at the requested rate (≥ the agreed floor), and rebuild the transaction. Preserve the index i, recipient address Addrᴮ,ᵢ, and (if present) change address Addrᴬ,ᵢ. Increment the version counter, set “supersedes” to the old txid, and mark the old raw bytes voided off-chain; they must never be broadcast. Log a signed “reissue” record capturing i, NoteID, old/new txids, and the new feerate.
• Reorg → rebroadcast the same bytes.
If a confirmed note is orphaned by a reorganisation (confirmation depth falls below the target), label it “orphaned” and immediately rebroadcast the identical transaction bytes. No reconstruction and no re-signing occur; the txid remains the same. Continue periodic rebroadcast until the note regains the required depth, then restore its “confirmed” status. Log the orphan event and each rebroadcast timestamp.
• Expiry → cancel queued notes.
When the invoice or policy expiry time elapses, cancel any notes that are constructed/signed/queued but not yet broadcast; release their reservations. Notes already broadcast may continue passive monitoring to confirmation if policy permits, but no new broadcasts are allowed after expiry. Emit a signed summary (“invoice_expired”) with counts by status.
All four paths are idempotent and machine-checkable: given the same inputs and timers, independent implementations will take the same actions and produce the same signed records.
Interoperability and audit
Determinism is the interop contract. Given the same fixed inputs—policy, invoice, anchors A and B, and the scope tuple {Z, H_I}—two independent implementations must produce the same per-note recipient addresses and sender-change addresses, the same bounded split a[·] (including permutation), the same reservation table R (disjoint input sets Sᵢ), and the same receipt root M over identically encoded leaves. This holds regardless of language, datastore, or network stack because every step is derived from canonical bytes and labelled domains, with reject-zero handling and rounding rules specified.
Wire and log formats are canonical UTF-8 JSON with detached signatures. Keys are sorted, strings NFC-normalised, integers base-10, hex lowercase, timestamps ISO-8601 UTC. Each signed record includes {"sig_key","sig_alg","sig"} and a hash-chain via "prev_hash" = H(canonical_bytes(previous_without_signature)). Sequence numbers ("seq") advance monotonically. Optionally, a journal root (Merkle of record hashes) can be published or anchored for external timestamping without disclosing content.
Audit is a replay, not an opinion. The verifier: (1) validates signatures and the hash-chain for all records; (2) recomputes H_policy from the signed policy and checks invoice.policy_hash, then recomputes H_I; (3) recomputes Z from the exchanged identity keys; (4) derives the split a[·] and its permutation from {Z, H_I} and verifies ∑aᵢ = T and bounds; (5) rebuilds R deterministically from the logged UTXO snapshot and parameters and compares to the recorded reservations; (6) for each i, derives Addr_B,i and Addr_A,i and reconstructs or verifies the raw transaction, recomputing txidᵢ and checking equality; (7) reconstructs leaves Lᵢ and recomputes the receipt root M, matching the manifest; (8) checks lifecycle transitions (queued, broadcast, seen, confirmed, reissued, cancelled) against timers and flags to ensure they follow the normative state machines.
Interop touchpoints are explicit: fee = ceil(fee_rate × size_bytes) with size_bytes = 10 + 148·m + 34·n; Base58Check version 0x00 for P2PKH; binary payloads (not display strings) inside receipt leaves; deterministic input/output ordering; prohibition of intra-invoice change reuse; and identical reject-zero counters for scalar derivations. Conformance is enforced with golden vectors (small and large invoices) that include all intermediate artefacts; an implementation that reproduces them byte-for-byte is interoperable, and any deviation is a concrete, auditable defect.
Ethical and practical implications
Privacy here is ordinary use of standard tools, not special-purpose obfuscation. The method does not hide data with exotic scripts or side systems; it simply uses many small, standard transactions to avoid creating a single, high-signal event. Ethically, that matters: minimising unnecessary disclosure is a legitimate design goal, and doing so with plain, inspectable primitives keeps the system verifiable. Receipts and selective proofs reinforce this stance. They let parties demonstrate exactly what needs to be shown—no more, no less—so accountability is preserved without turning every payment into public theatre.
For merchants, the operational benefits are concrete. Publishing intake bounds and a fee floor translates privacy into discipline: inflows arrive in predictable sizes, treasury and reconciliation become simpler, and risk from outsized transfers is reduced. Because either side can submit notes, settlement does not stall on a single broadcaster; pacing spreads load and smooths liquidity. Internally, canonical logs and deterministic derivations mean audits are replayable rather than arguable.
For payers, predictability is the companion virtue to privacy. The build is deterministic from a shared scope, so addresses, amounts, and schedules are reproducible without coordination. Disjoint inputs and per-note change remove linkage traps without sacrificing spendability. Pacing allows fee and timing control, and reissue-before-broadcast provides a clear path when network conditions shift.
The broader implication is that practical privacy need not be an arms race. By keeping to standard transactions and well-known hashes and keys, the approach remains legible to auditors and tools while denying outsiders easy linkage. In short: ordinary mechanisms, carefully arranged, can deliver both discretion and operational clarity.
Conclusion: privacy by doing more of the ordinary
Privacy in payments is not conjured by a single clever trick; it emerges when ordinary elements are multiplied and disciplined. Break a total into many small notes and you dilute the signal of any one transfer. Make each note independent—its own inputs, its own recipient address, its own (optional) change—and you remove the structural hooks that bind notes together. Scope every derivation to a specific invoice and role so that keys, amounts, and schedules are reproducible for the parties yet opaque to outsiders. Finally, vary broadcast in time and path, letting either side submit, so that first-seen and time-window heuristics lose their bite. Scale + independence + diversity: that is the recipe.
The promise is dual. For outsiders, what they see is a sea of small, standard transactions—indistinguishable in amount, unhelpful in timing, and uncooperative in structure. Linking one to the next yields little beyond guesswork. For insiders, determinism preserves control and accountability: from shared scope to split amounts, addresses, reservations, and receipts, every artefact can be recomputed from canonical logs; every transition is signed and auditable; every dispute resolves by replay rather than rhetoric. No exotic constructions are required—just careful use of the existing primitives and a refusal to create a single conspicuous event where hundreds of unremarkable ones will do. Privacy follows from the crowd; audit follows from the calculus of identical bytes.
Epilogue: privacy demands scaling, not headline TPS
If privacy is an emergent property of scale, then the system that seeks practical privacy must be able to manufacture scale on demand. The unit that matters here is not the “payment” in the retail sense, but the note: a small, ordinary transaction that looks like thousands of its neighbors and refuses to carry a distinctive shape. One big transfer creates a lighthouse. Hundreds or thousands of small notes create weather.
This reframes the scaling target. It is not “seven transactions per second,” nor even “a few million on a good day.” It is the sustained capacity to carry the note volume implied by ordinary economic life when each payment is decomposed into many independent notes. The arithmetic is blunt. If a city does 100 000 real-world payments per minute at peak (cards, cash equivalents, invoices clearing), and if privacy-preserving practice averages, say, 1 000 notes per payment, then the ledger must absorb ≈ 100 000 × 1 000 = 100 million notes per minute. That is roughly 1.67 million notes per second, continuously, before you consider retry traffic, reissues prior to broadcast, or the simple fact that peaks exceed averages. If the average rises to 1 200 notes per payment to harden privacy, the required headroom climbs accordingly.
Crucially, the number of payments per minute is not the ceiling; it is the multiplier. Privacy pushes us from “how many payments can we fit?” to “how many notes must we carry so each payment can hide in a crowd?” The more ambient small outputs the ledger produces per unit time in the relevant bands, the larger the crowd each note can disappear into. That is why a system that tops out at token TPS cannot credibly promise privacy at population scale: the background is too thin to drown the signal.
Scaling, then, is not a vanity metric; it is the precondition for discretion. It means blocks that comfortably ingest metropolitan-level note streams, mempools and relay paths that tolerate burstiness without collapsing into global gossip storms, UTXO sets and indices that admit high-velocity insertions and lookups, and node software that validates and forwards ordinary transactions at industrial rates. It means fee markets that reward throughput of the mundane over spectacle, because the mundane is where privacy lives. It means engineering for the boring case—tiny P2PKH notes, lots of them, always.
There is a deeper symmetry here. The same properties that help privacy—many small, independent notes; diverse timing and routes; receipts that commit without broadcasting—also help resilience. Congestion in one pocket does not halt settlement everywhere; either party can broadcast; orphan handling is trivial; audits are replayable. But none of that matters if the network cannot carry the load implied by privacy itself. If a jurisdiction needs 100 million notes per minute to make 100 000 payments per minute plausibly private, the only honest answer is to build for 100 million notes per minute (and the peaks above it). Anything less is a promise that cannot be kept.