How safe are my keys?

The app uses the secp256k1 group order, not a rounded 2²⁵⁶. A normalization warning is load-bearing: the standard random-map collision expression is √(πn/2); quotienting by ±P gives √(πn/4). The brief calls the latter “standard” and then subtracts another 0.5 bit. Both conventions are printed so that step is not hidden. Kuhn–Struik gives √k asymptotic scaling, while its finite two-log factor is 1.5 (+0.584963 bits), not exactly √2. The headline’s +0.500 is therefore an asymptotic exponent model; measured small-k constants remain visible.

unspent P2PKH / P2WPKH → HASH160 second-preimage = 160 bits
spent or reused          → public key exposed → ECDLP floor
unspent P2WSH            → SHA-256 script second-preimage = 256 bits
P2TR key-path            → x-only public key exposed at funding → ECDLP floor

The target is one existing output, so collision resistance is the wrong bound. Birthday work belongs only to a separate script-grinding case where an attacker chooses a collaborating cosigner key; this app does not mix that case into ordinary custody.

A BIP39 checksum is computed from the entropy entered. In a hand-conversion workflow, a miscount can produce a different but internally valid entropy string, so the checksum catches 0% of that class of dice-transcription error. Its 4-bit or 8-bit error-detection value applies to later mnemonic-word errors, not to self-consistent source transcription.

BIP39 seed = PBKDF2-HMAC-SHA512(
  password = mnemonic,
  salt = "mnemonic" + passphrase,
  iterations = 2048,
  output = 512 bits
)

candidate work ≈ 2^(seed-search bits + passphrase bits) PBKDF2 evaluations

The 2048 iterations are already represented in the measured candidate rates of 10⁵/s and 10⁸/s. They are a work factor, not 11 extra entropy bits to add to the password.

The supplied prompt’s 8.66×10¹⁷ J figure corresponds to the expected rho walk at 2^127.8257, not to 2^128. With the stated 10⁵–10⁷ irreversible gate-operations per EC group operation, the range is about 140–14,000 world-energy-years, not 14–14,000. This is a lower-bound thought experiment, not an engineering forecast.

Bitcoin SHA-256d hashrate is deliberately absent: those ASIC operations cannot be divided into elliptic-curve group operations. Rho also remains a low-memory attack through distinguished points; there is no invented storage penalty.

exposed secp256k1 public key → one Shor run per required key
hidden HASH160 target       → Grover ≈ 2^80 oracle queries before Shor applies
hidden SHA-256 script       → Grover ≈ 2^128 oracle queries

Shor runs for k keys = k; no classical √k multi-log batching.

Quorum still multiplies total Shor work, but one fault-tolerant capability applies to every correlated secp256k1 key. Litinski also amortizes setup across multiple keys—about (44 + 65/k) million Toffoli gates per key—so “no batching” is too strong even though total work remains asymptotically linear in k. That shared capability threshold is distinct from claiming the extra runs are free.