BSV USA Association: Confirmation-depth guidance

This is the living document behind item 2.3 of the technical program (drafts/technical-program.md). It belongs in Document 1 of the data room (drafts/data-room-index.md). John Calhoun (@johncalhooon), the named Director, owns it. Nancy (@NasdaqNancy) is the pseudonymous founder. This document does not speak for any exchange, custodian or the existing BSV Association.

Nothing here is built yet. The monitor that feeds it (item 2.2) does not exist. Every input below is a public figure with a date, or an estimate marked as one. No reviewer has checked the numbers.

1Purpose

Every exchange that lists BSV must pick a deposit confirmation count. Today each venue picks one alone. Often it picks a very high number, and that number becomes the story.

This document replaces the question "how many confirmations is safe?" with a method. The method takes measured inputs: who mines, how concentrated mining is, what reorgs have happened, and how much money is at stake. It returns a recommended count per deposit size, plus rules for when to stop crediting.

An exchange or custodian can adopt it, adapt it, or check its own policy against it. Each venue approves its own thresholds. Our numbers are inputs, not orders.

There is no safe number. Confirmations reduce risk. They never remove it. Section 6 says what this model leaves out.

2The model

2.1 The attack it describes

A customer deposits coins. The venue waits for z blocks on top of the deposit, then credits the account. The customer trades or withdraws. Meanwhile an attacker with share q of the hashrate mines a secret chain where the deposit never happened. If the secret chain overtakes the public one, the deposit vanishes and the venue has paid out against nothing. This is the double spend that hit BSV venues in 2021 (section 4).

2.2 The probability of a reversal

Satoshi Nakamoto gave the first calculation in section 11 of the white paper (bitcoin.org/bitcoin.pdf). It models the attacker's progress during the z blocks as a Poisson variable. Cyril Grunspan and Ricardo Pérez-Marco showed that this approximation understates the risk, and gave an exact closed form ("Double spend races", International Journal of Theoretical and Applied Finance 21(8), 2018; arxiv.org/abs/1702.02867). Meni Rosenfeld's earlier analysis reaches similar conclusions (arxiv.org/abs/1402.2009).

We use the exact form. With p = 1 - q:

P(q, z) = I_{4pq}(z, 1/2)      if q < 1/2
P(q, z) = 1                    if q >= 1/2

I_x(a, b) is the regularized incomplete beta function
  (scipy.special.betainc(a, b, x) in Python).

Nakamoto's approximation, for comparison:
  lambda = z * q / p
  P_N(q, z) = 1 - sum_{k=0..z} (lambda^k * e^-lambda / k!) * (1 - (q/p)^(z-k))

Two facts follow and matter more than any table:

• Below half the hashrate, each extra block cuts the risk, but slowly when q is close to one half.
• At half or more, the attacker wins eventually with certainty. More confirmations only make the attack take longer. Time is still useful: it gives a monitor time to see the attack and a venue time to halt. That is why section 3 has a halt rule.

A check on the formula: at q = 0.1 and z = 1 the exact value is 0.200 (that is, 2q), and Nakamoto's gives 0.205. At q = 0.3 and z = 10 the exact value is 0.065, and Nakamoto's gives 0.042. At q = 0.4 and z = 20 the exact value is 0.204, and Nakamoto's gives 0.164. Our own computation, 2026-10-12.

2.3 Choosing q from measured inputs

The formula needs q, the attacker's share. Nobody knows it in advance. We set it from what the monitor measures, and say plainly that this is a scenario, not a ceiling.

Coinbase tags are labels a pool chooses. They are not proof of who controls the hashpower. One operator can run several tags. The monitor page must say so.

The largest single-miner share is not a cap on q. An outside attacker can add rented or diverted hashrate on top of the honest network. Section 2.5 shows this is cheap for BSV. So the default rule is: q is the larger of the measured top-miner share and 30 percent, and the venue reads the 50 and 60 percent columns as the outside-attacker case.

2.4 Value at risk and the tolerance per tier

A venue tolerates more chance of loss on a small deposit than on a large one. We express this as a target: the expected loss from one deposit should stay under about one dollar. So the tolerated probability for a tier is one dollar divided by the top of that tier.

epsilon(tier) = R / V_max(tier)        R = $1 by default

Under $1k            epsilon = 1e-3
$1k to $10k          epsilon = 1e-4
$10k to $100k        epsilon = 1e-5
$100k to $1M         epsilon = 1e-6
Above $1M            epsilon = 1e-7 (sized for $10M; above that, manual review)

z(q, tier) = the smallest z with P(q, z) <= epsilon(tier)

R is a policy choice, not a fact. A venue can raise or lower it. Halving R adds a few blocks at q = 30 percent and many more at q = 40 percent.

An attacker does not attack one deposit. It splits a large sum across many small deposits, at one venue or several. Per-tier counts therefore need a per-account and per-day cap: deposits from one account inside one day are summed and the sum picks the tier. The venue sets the cap.

2.5 The cost of renting hashrate against BSV

BSV uses SHA-256, the same proof of work as Bitcoin. Any Bitcoin miner can point hardware at BSV without changing it. This is the core of the risk.

Public figures, all read on 2026-10-12 unless marked:

What these figures say, as an estimate:

Hashrate to match the honest BSV network:  H ~ 200 PH/s (unverified)
Price:                                     c ~ $2.90 per PH/s per hour
Cost of one hour at parity (q = 0.5):      H * c ~ $580

Blocks come every 10 minutes at the network's difficulty, so an
attacker with hashrate A mines 6 * A / H blocks an hour. The cost
per attacker block is therefore about

  cost_per_block = c * H / 6 ~ $97

whatever the attacker's share. Block rewards the attacker collects
on its own chain offset part of this.

Three conclusions, each with its uncertainty:

• An hour of majority hashpower against BSV costs in the hundreds of dollars today, on these figures. In August 2021 the cited figure was $5,200. The drop reflects lower BSV hashrate relative to Bitcoin. The BSV hashrate figure is not ours and is not verified.
• The BSV network is about one five-thousandth of Bitcoin's hashrate on these figures. Renting it on NiceHash is limited by what is for sale (about 1.3 PH/s today, under 1 percent of BSV). The serious case is a Bitcoin miner or pool diverting a tiny slice of its own hardware. That needs no market at all.
• No confirmation count makes a majority attack uneconomic for a large deposit. At about $97 a block, a $1M deposit would justify thousands of blocks of attacker spending. This is why large tiers need caps, monitoring and a halt rule, and why the 50 and 60 percent columns below do not come from the formula.

3Worked tables

3.1 Recommended confirmations by tier and top-miner share

Blocks are counted on top of the block containing the deposit. Hours assume 10-minute blocks.

The 30 and 40 percent columns come from the formula in section 2.2 with the tolerances in section 2.4. Our computation, 2026-10-12, using scipy.special.betainc. Nakamoto's approximation gives lower counts (24, 32, 40, 49, 57 at 30 percent), which is why we do not use it.

Note A. At 50 percent the formula says the attacker wins with certainty. These counts are a policy judgment, not a model output. They buy a full day or two of monitoring before a small deposit becomes spendable. They work only together with the halt rule below and a per-account daily cap.

Note B. At 60 percent the measured network is already in the attack case. We recommend that venues credit only the smallest tier, with a low per-account cap, and treat larger deposits by manual review or not at all. A reviewer may conclude that a venue should simply halt BSV deposits at this level. That is a defensible reading.

How to read the table: if the monitor's 7-day top-miner share is 34 percent, use the 40 percent column. Round up, never down. If the top-three share is above 50 percent, use at least the 50 percent column.

Compare with BTC. These counts are far higher than the 1 to 6 confirmations common for Bitcoin. That is because the measured inputs for BSV are worse, not because the method is harsher. The same method with Bitcoin's inputs gives Bitcoin's familiar numbers.

3.2 The halt rule

The formula assumes the venue cannot see the attack coming. The monitor changes that. A visible reorg or a lasting fork is evidence an attack may be under way. The halt rule turns that evidence into action.

Inputs from the monitor, checked before every credit:
  max_reorg_depth_24h   deepest reorg seen in the last 24 hours
  fork_age_minutes      how long a competing tip has existed
                        within 6 blocks of the best tip
  inputs_age_minutes    age of the newest monitor data
  top_share_shift       change in the top-miner share,
                        24-hour window against the 30-day window

HALT all automatic BSV deposit credits if any of:
  max_reorg_depth_24h > N          N = 2 blocks by default
  fork_age_minutes   > T           T = 30 minutes by default
  inputs_age_minutes > 120         the monitor is down or stale
  top_share_shift    > 10 points   a sudden new majority is forming
  unknown_share_24h  > 25%         hashrate nobody can label

While halted:
  deposits already credited stay credited;
  pending deposits keep counting but are not credited;
  withdrawals of BSV pause for the same accounts (section 6).

RESUME only when all of:
  144 blocks (about 24 hours) with no reorg deeper than 1 block;
  no competing tip older than T;
  monitor data fresh;
  a named person at the venue signs off.

Why these defaults. A one-block reorg happens in normal operation when two miners find blocks at almost the same time. Two blocks is rare. Anything deeper than two has, on the public record, gone with attacks (section 4). Thirty minutes is three expected blocks. A natural fork resolves well before that. These are starting points. The monitor's own history should be used to tune them once it has months of data.

A venue that cannot run the halt rule should not use the 50 and 60 percent columns at all.

4The 2021 attacks

4.1 What the public record says

All from public sources. We have not yet checked heights and hashes against our own node data, because that node does not exist yet. The incident register (item 2.7) will do that work.

The reports disagree on depth (about 100 blocks against 14). Both may be true of different reorgs in the same episode. We report both and resolve neither.

4.2 What a reviewer should conclude

• The attacks were real, repeated, and reached venues. They were not theoretical.
• They were cheap, on the figures cited at the time, and they remain cheap on today's figures (section 2.5).
• Venues that credited at a few confirmations lost money. Depths of 14 and possibly about 100 blocks mean a policy of 6, 10 or even 50 confirmations would not have been enough on its own during the worst hours.
• The useful defense was seeing the fork and stopping. That is what the halt rule and the monitor are for.

4.3 What has and has not changed since

Has changed, on the public record:

• Rental economics. The cited hourly cost fell from $5,200 (August 2021) to an estimate in the hundreds of dollars (section 2.5), on unverified BSV hashrate figures. This is a change for the worse.
• Node software. BSV is moving from SV-node to Teranode. The technical program records Teranode v0.16.0 in the conformance harness. A software change does not change the hashrate arithmetic.

Has not changed:

• BSV still shares SHA-256 with a far larger network. Any large Bitcoin miner can still attack it.
• No public, dated, independent record of BSV reorgs since 2021 exists that we have checked. We do not claim there have been no attacks since 2021. The incident register (item 2.7) must establish that, period by period, with its gaps shown.

Unknown to us, and not claimed:

• Whether miners or node operators have adopted any formal response procedure since 2021.
• Whether any venue still uses the confirmation counts it set in 2021.

5How the numbers stay current

5.1 Inputs and their date

The tables in section 3 are fixed at this draft's date. The live version is the service. Every published copy of this document shows, at the top of section 3, the date and window of the inputs it used, in this form:

Inputs as of 2026-10-12T00:00Z
  top-miner share (7 d):  not yet measured; table uses 30, 40, 50, 60 percent
  top-three share (7 d):  not yet measured
  unknown share (7 d):    not yet measured
  deepest reorg (30 d):   not yet measured
  hashrate estimate:      185 to 245 PH/s, third party, June to August 2026
  rental price:           $2.90 per PH/s per hour, NiceHash, 2026-10-12

When the monitor runs, these lines fill from it. A copy older than 30 days carries a warning that its inputs are stale.

5.2 What the service reads from the monitor

The service reads the monitor's /api/miners endpoint (item 2.2). The monitor is not built. We assume it returns, per window, the block count, a share per coinbase tag, the unknown share, and the window's start and end. If it returns something else, this section changes to match.

GET /api/miners?window=7d

{
  "window": "7d",
  "from": "2026-10-05T00:00:00Z",
  "to":   "2026-10-12T00:00:00Z",
  "blocks": 1008,
  "miners": [
    { "tag": "ExamplePoolA", "blocks": 302, "share": 0.2996 },
    { "tag": "ExamplePoolB", "blocks": 251, "share": 0.2490 }
  ],
  "unknown_share": 0.05,
  "source_version": "monitor 0.1.0"
}

The values above are placeholders, not measurements.

5.3 The service endpoint: /api/confirmations

For the monitor to implement. One read-only endpoint. No key needed. Cached for 60 seconds.

Request:

GET /api/confirmations?usd=<amount>[&window=24h|7d|30d][&r=<dollars>][&scenario=top1|top3]

usd       required. Deposit value in US dollars, a positive number.
          The venue sums one account's deposits over 24 hours before calling.
window    optional, default 7d. Which /api/miners window sets q.
r         optional, default 1. Tolerated expected loss per deposit, in dollars.
scenario  optional, default top1. top1 uses the largest single-miner share;
          top3 uses the top-three share.

Response, 200:

{
  "version": "1",
  "computed_at": "2026-10-12T18:00:00Z",
  "usd": 25000,
  "tier": "10k_to_100k",
  "recommendation": {
    "action": "credit_after",          // credit_after | manual_review | halt
    "confirmations": 240,
    "expected_hours": 40,
    "basis": "formula",                // formula | policy | halt
    "note": "q rounded up to the 40 percent column"
  },
  "model": {
    "formula": "grunspan_perez_marco_2018",
    "q_measured": 0.2996,
    "q_used": 0.40,
    "epsilon": 1e-5,
    "r_usd": 1,
    "p_at_recommended": 9.7e-6
  },
  "inputs": {
    "window": "7d",
    "from": "2026-10-05T00:00:00Z",
    "to": "2026-10-12T00:00:00Z",
    "blocks": 1008,
    "top1_tag": "ExamplePoolA",
    "top1_share": 0.2996,
    "top3_share": 0.71,
    "unknown_share": 0.05,
    "max_reorg_depth_24h": 1,
    "fork_age_minutes": 0,
    "inputs_age_minutes": 4,
    "hashrate_phs": null,
    "rental_usd_per_phs_hour": 2.90,
    "rental_price_date": "2026-10-12",
    "monitor_source_version": "monitor 0.1.0"
  },
  "halt": {
    "active": false,
    "reasons": [],
    "thresholds": { "N": 2, "T_minutes": 30, "stale_minutes": 120,
                    "share_shift_points": 10, "unknown_share": 0.25 }
  },
  "caveats": [
    "Confirmations reduce risk; they never remove it.",
    "Coinbase tags are labels, not proof of who controls hashpower.",
    "Each venue approves its own thresholds."
  ],
  "document": "https://<site>/confirmation-depth-guidance (version and date)"
}

All values in this example are placeholders. When the halt rule fires, recommendation.action is halt, confirmations is null, and halt.reasons lists each condition that fired by name. When the monitor's data is stale, the service returns the halt answer, not an old number.

Errors: 400 with {"error": "usd must be a positive number"} for a bad amount; 503 with {"error": "monitor unavailable", "action": "halt"} when the service cannot read the monitor. A venue's integration must treat any error as a halt, never as a default count.

Every response is logged with its inputs, so any credit decision can be reproduced later. The source and the log are public.

6Limits

What this model does not cover:

• Eclipse attacks. If an attacker controls which peers a venue's node talks to, the venue sees a false chain and counts confirmations on it. Defense: several independent peers and observation points, and checking headers against the monitor. Not modeled here.
• Venue-side key compromise. Stolen keys, insider theft and wallet bugs lose money with no reorg at all. Confirmations do nothing for them.
• Withdrawals versus deposits. This model protects deposits. A withdrawal can also be reversed by a reorg, and the venue may resend it and pay twice. Venues should track withdrawals until they reach the same depth, and must not rebroadcast a reorganized withdrawal without checking whether the original is back in the chain.
• Fee sniping and short reorgs for fees. Miners may try to remine recent blocks to take their fees. On a low-fee chain the incentive is small, but it raises the base rate of one-block reorgs, which the halt rule must not mistake for an attack. Setting nLockTime to the current height on venue transactions is a cheap partial defense.
• Zero-confirmation acceptance. Not covered. Whether a transaction seen but unmined can be trusted is a separate question about relay policy and double-spend alerts.
• Bribery and miner collusion outside hashrate. The model counts hashrate only. Payments to miners to reorder blocks are not modeled.
• Price moves. Tiers are in dollars at deposit time. A large price move during a long confirmation wait changes the value at risk. The venue should recheck the tier at credit time.
• The inputs themselves. Hashrate, rental prices and tags come from third parties until the monitor runs, and some are unverified (section 2.5).

The plain statement, to appear in every copy and every API response: confirmations reduce the risk of a reversal; they never remove it. An attacker with most of the hashrate can reverse any number of confirmations given enough time. What a venue can do is make attacks slower and more expensive, see them early, and stop crediting when it does.