Interesting find from my implementation of the Monero Inflation Checker (MIC). Some actor was sending coins to invalid stealth addresses.
It seems unlikely this was searching for an exploit...
But then it continues for three years, so seems unlikely it's just an undiscovered bug too.
Heres a writeup about it.
There are some badly formed Borromean range-proofs early in the chain but I want to understand those a little better before I post something.
Cheers fam.
1.A single non-subgroup curve point embedded in ~7,355 blocks — the deepest open finding
What: One specific ed25519 point (9b2e4c02…) that is not on the prime-order subgroup appears in 7,355 unique blocks spanning heights 200,382 → 1,839,780, always in the stealth address position. It accounts for the overwhelming bulk of the 8,931 "points outside subgroup" entries. It recurs in a dense cluster around heights 323,000–323,500 (~300 blocks), plus a second, smaller cluster later. A second point (2a74a3c4…) shows the same pattern at smaller scale (36 blocks), and a tail of ~16 minor points appear 1–5 times each.
What it means: A stealth address is supposed to be derived as a valid subgroup point; a non-subgroup point in that position means someone was generating output keys with broken or deliberately tweaked math — and did so thousands of times over 1.6M blocks (~3 years of chain history). The two candidate explanations are (a) one actor (wallet software, bot, or researcher) repeatedly emitting a malformed/tweaked output key, or (b) a systemic generator artifact in some wallet implementation from that era.
It is not an inflation vector — the point is on the curve, funds are still spendable-bound normally by consensus rules, and the checker's fallback verification handles it — but it's a real, previously undocumented census of pathological output keys on-chain. Until the txs embedding it are extracted and examined, this is the scan's most interesting open thread.
Summary in one line: a non-subgroup stealth address is a curve point outside the reach of the protocol's scalar algebra; consensus never forbade it, it's an address so it can't inflate anything, and it's eternally unspendable — so the scan's deepest anomaly is not a crack in Monero's supply, but a three-year archaeological record of someone torching their own coins.
https://stasher.news/uploads/273
ungovernable misfit, monero burner, retard, time traveller or thief?
Wait... there can be burn addresses in Monero, as in, cryptographically verifiable unspendable?
When I was designing downvotes in Stasher I initially had the idea to burn XMR to downvote. I had to go do some research on if burn addresses were possible and how to create one. I eventually scrapped the idea.
Can anyone generate these non-subgroup stealth addresses?
Yes that's my understanding.
using any torsion-carrying point on the curve would result in a proveably unspendable output. Subgroup membership was never a rule and afaict it was never made to be one, so it should still work today. it just requires an extra step in creating the transaction. Seems like a hassle to implement, since there's no library for constructing them and no implementation for finding and counting them (like for downvotes).
Although libsodium rejects them all so they're easy to find I guess.
Not quite clear how this relates to the 2017 inflation bug, I guess this is torsion in the destination point and not the spending proof (torsion in the key image?).
Which of course, there IS a consensus check to confirm since 2017. my guess anyway.
anyway. tbh, I only have the vaguest idea of what torsion on a curve point actually is.
**UPDATE**
Somebody sent me this:
https://github.com/monero-project/monero/issues/8351
These bad stealth addresses are from a hard coded value in the original Bytecoin genesis.
My implemention of the checker found the same strange values (as expected since its a fork of that checker)