Mostro Spam & Abuse Mitigation — Design Options

[arkanoider]

My question to Opus 4.7 Extra High:

Ok! Great job...now I want to make some order in our discussion and have more structured plan having your opinion, i add two details :

• we are evaluating to remove full privacy mode
• today an attacker used a simple trick to take order just published ( new keypair can do that at the moment)

So adding this two details, prepare me a nice list of options considering both privacy mode availability and also without it. Put the list of your prferred soltuions in these order:

first the most effective with less code modifcations down to the most effective but with high code impact. Prepare your response in a nice markdown format i can copy on github ideas!

Mostro Spam & Abuse Mitigation — Design Options

Context

Two concrete facts are shaping this plan:

1. Full Privacy Mode may be removed. If every order carries a verifiable identity key (via the NIP-06 derivation chain, m/44'/1237'/38383'/0/0), mostrod always has a stable per-user handle. This massively simplifies anti-spam and anti-Sybil design.
2. An active attack exists today: an attacker creates a fresh keypair and immediately takes newly-published orders to grief makers (locking up the order, never completing, forcing cancel/expiration cycles).

Two scenarios are considered throughout:

• Scenario A — Privacy mode removed (every message carries identity key).
• Scenario B — Privacy mode retained (some messages are only ephemeral-keyed).

---

Design Principles

• No sats-up-front. New users without Bitcoin must be able to onboard and trade. Bonds are rejected as the primary gate.
• Cost to attackers ≠ cost to honest users. Honest users pay a one-time cost (CPU) or zero cost; attackers pay per-identity and per-action.
• Reputation is a reward, not a gate. New users can always trade; trusted users get progressively fewer frictions.
• Prefer small policy knobs over protocol changes. Where possible, enforce in mostrod without touching NIP-69.

---

Option List

Ordered by effectiveness × (inverse) code-impact. Earlier options = highest ROI.

---

1. Per-identity takes-in-flight quota (directly kills the current attack)

Problem addressed: The live attack — fresh keypair instantly takes an order and griefs the maker.

Mechanism:

• Limit each identity key to N simultaneously in-progress orders as taker (e.g., N=1 for new identities, N=3 for reputation Tier 1, N=10 for Tier 2+).
• On Action::TakeBuy / Action::TakeSell, count open orders where taker_identity_pubkey == event.sender. Reject if >= N.
• New identities are effectively capped at 1 concurrent take. Multi-order grief attacks die immediately.

Scenario A (no privacy mode): full enforcement, identity key always known.
Scenario B (privacy mode): reputation-mode users are fully covered; privacy-mode takers fall under a combined global cap (see Option 5).

Code impact: ~30–80 lines.

• src/app/take_buy.rs, src/app/take_sell.rs — add pre-flight count query.
• src/db.rs — one indexed query on orders table filtered by taker pubkey and status.
• settings.tpl.toml — new max_in_flight_takes_tier0/1/2/3.

Complexity: Trivial.
Effectiveness: Very high for the concrete attack in production today.

---

2. Minimum identity age at mostrod (first-seen, not self-claimed)

Problem addressed: Fresh keypair used for abusive takes.

Mechanism:

• mostrod records first_seen_at for every identity pubkey the first time it sends any message.
• For high-impact actions (TakeBuy, TakeSell, NewOrder), require now - first_seen_at >= min_age_seconds (e.g., 60–300s).
• Honest new users experience a one-time "register, wait a minute, trade" flow; clients can hide this by auto-registering on first launch.
• Critically: this is mostrod's first-seen timestamp, not a self-reported kind 0 created_at. It cannot be backdated.

Scenario A: full enforcement.
Scenario B: only applied to reputation-mode messages; privacy-mode messages still need Option 5/6.

Code impact: ~50 lines.

• src/db.rs — add first_seen_at column to users table (migration).
• src/app.rs check_trade_index or a new check_identity_age — reject if too young.
• Client-side: optional "pre-register" UX on first launch.

Complexity: Low.
Effectiveness: High against bots that generate-and-trade in one shot. Combine with Option 1 for full coverage.

---

3. Onboarding PoW bound to identity key (replaces bonds, no sats required)

Problem addressed: Cheap Sybil identity generation undermines Options 1 and 2.

Mechanism:

• Any new identity key must present a one-time high-difficulty PoW before its first NewOrder / TakeBuy / TakeSell.
• Proof form: nonce such that H(identity_pubkey || nonce) has D leading zero bits. D configurable, e.g., 22–26 bits (seconds-to-minutes on a phone, GPU-hours for thousands of identities).
• Stored once in users table. Never required again for that identity.
• Explicitly does not require sats. Replaces the bond idea while still imposing real per-identity cost on attackers.

Scenario A: full enforcement.
Scenario B: same; complementary with Option 6 for privacy-mode sessions.

Code impact: ~150–250 lines.

• New Action::RegisterIdentity with {identity_pubkey, nonce} payload.
• Verification helper in src/util.rs.
• Schema: add onboarding_pow_nonce, onboarding_pow_bits columns to users.
• Gate in src/app.rs handle_message_action for trading actions.

Complexity: Low-to-medium.
Effectiveness: High. Makes Sybil attacks expensive in CPU and combines multiplicatively with Options 1 and 2.

---

4. Tiered trust with reputation-based promotion

Problem addressed: Single-size-fits-all limits are either too tight for honest users or too loose for attackers.

Mechanism:

• Define tiers, derived from existing fields in the users / ratings tables:

Tier	Criteria	Quota hint
0 (Trial)	Just onboarded	1 pending order, 1 in-flight take, high per-msg PoW
1 (New)	≥1 successful trade	3 pending, 3 in-flight, medium PoW
2 (Regular)	≥5 trades, ≥4.0 avg rating	10 pending, 10 in-flight, low PoW
3 (Trusted)	≥20 trades, high rating, age	Near-unlimited, minimal PoW

• Tier lookup is a computed SQL view or derived at request time from total_rating, total_reviews, first_seen_at.
• Reputation progression is organic: a user with zero sats can do their first buy trade, get rated, and graduate out of Trial.

Scenario A: works uniformly.
Scenario B: privacy-mode users are pinned to Trial tier by design (no persistent identity = no reputation; documented tradeoff).

Code impact: ~200–400 lines.

• src/db.rs — tier helper function.
• src/app/order.rs, src/app/take_buy.rs, src/app/take_sell.rs — consult tier for quotas.
• src/config/types.rs — per-tier settings.

Complexity: Medium.
Effectiveness: High. Turns every other control (PoW, quotas, epoch limits) into a graduated knob.

---

5. Per-identity, per-epoch action limits (freshness + bounded state)

Problem addressed: Burst spam within a short window; unbounded counter growth.

Mechanism:

• Epoch defined server-side (e.g., 1 hour), published in the kind: 38385 info event.
• Per identity per epoch, enforce:
  • Max NewOrder count (by tier).
  • Max TakeBuy + TakeSell count (by tier).
  • Max total gift-wraps (global DoS cap).
• Counters reset at epoch rollover; state is bounded (two epochs kept live).
• Clients and other Mostros can predict limits by reading the info event.

Scenario A: full effect.
Scenario B: privacy-mode users share a global per-epoch pool (small, deliberate); reputation-mode users have per-identity allocations.

Code impact: ~250–400 lines.

• New epoch_counters table or in-memory map with TTL.
• src/app.rs run-loop wrapper.
• Info event publisher — extend src/util.rs or wherever the info event is emitted.

Complexity: Medium.
Effectiveness: High, especially combined with Option 4. Makes burst attacks ineffective regardless of identity count.

---

6. Blind-signature "epoch tokens" for privacy mode (only if privacy mode is kept)

Problem addressed: Sybil spam from ephemeral trade keys in Full Privacy Mode.

Mechanism:

• User, using their identity key out-of-band, requests N blind-signed tokens tagged with the current epoch.
• Tokens are unblinded locally — mostrod can verify them but can't link them back to the issuing identity.
• Each privacy-mode order carries one token; mostrod marks it spent.
• Epoch rollover invalidates unused tokens and truncates the spent-set.
• No ZK circuit required. Uses standard blind Schnorr or blind RSA (Privacy Pass style).

Scenario A (privacy mode removed): Not needed — skip entirely.
Scenario B: This is the anonymous rate-limit primitive.

Code impact: ~500–1000 lines + one crypto dependency.

• New Action::RequestEpochTokens and Action::RedeemEpochToken handling.
• Blind-signature crate (e.g., blind-rsa-signatures or custom Schnorr).
• Spent-token storage keyed by epoch.

Complexity: Medium-high.
Effectiveness: High — but only relevant in Scenario B. If privacy mode is dropped, this option is discarded.

---

7. Dynamic per-action PoW with book-load scaling

Problem addressed: Static PoW either hurts honest mobile users or fails to deter GPU-armed attackers.

Mechanism:

• Split current single pow: u8 into per-action difficulties: pow_new_order, pow_take_*, pow_rate_user, etc.
• Base difficulties selected per tier.
• pow_new_order scales up when the book has > X pending orders (load-shedding).
• Current difficulty published in the info event so clients can adapt.

Scenario A/B: identical behavior.

Code impact: ~150–300 lines.

• src/config/types.rs — expand PoW fields.
• src/app.rs — move PoW check inside action dispatch (currently gatekeeper in run loop at line ~315).
• Info event publisher — include current PoW schedule.

Complexity: Medium.
Effectiveness: Medium-high. Best as a complement to quotas and tiers, not as a primary defense.

---

8. Sanity filters on order content

Problem addressed: Low-effort spam that obviously doesn't correspond to real trading intent.

Mechanism:

• Hard-reject orders with absurd premium (e.g., |premium| > 25%).
• Hard-reject duplicate orders (same (kind, fiat_code, fiat_amount, payment_method, premium)) from the same identity within a TTL.
• Reject orders whose min_payment_amount / range is outside sensible bands.
• Log-only for ambiguous cases so thresholds can be tuned.

Scenario A/B: identical.

Code impact: ~100–200 lines, concentrated in src/app/order.rs.

Complexity: Low.
Effectiveness: Medium. Catches lazy bots; sophisticated attackers adapt. Cheap insurance.

---

9. Signed-nonce challenge for borderline requests

Problem addressed: Heuristic-flagged but not clearly malicious orders; fire-and-forget bots.

Mechanism:

• When heuristics (Option 8) flag an order as suspicious-but-not-rejected, mostrod replies with action: "challenge" containing a random nonce.
• Client must echo the nonce signed with the same trade key within N seconds.
• Proves an interactive client without any CAPTCHA, external service, or human friction.

Scenario A/B: identical.

Code impact: ~150 lines.

• New Action::Challenge and Action::ChallengeResponse.
• Short-lived pending-challenge map.

Complexity: Low-medium.
Effectiveness: Medium. Mostly valuable as a soft gate between "obviously fine" and "obviously spam."

---

10. Dispute / abandonment penalty on taker identity

Problem addressed: Attackers who grief makers by taking and abandoning orders, even within quotas.

Mechanism:

• Track abandon_count per identity (order taken, never progressed to fiat-sent within a timeout; or disputes adjudicated against taker).
• Demote tier or lengthen cooldowns when abandon rate exceeds threshold.
• Not account-banning — just progressively raises PoW and reduces quotas.
• Combined with the users table structure already in place.

Scenario A/B: identical, but relies on identity key being present (weak in privacy mode).

Code impact: ~200–300 lines.

• src/db.rs — schema additions.
• src/app/dispute.rs, src/app/cancel.rs — update counters.
• Tier resolver from Option 4.

Complexity: Medium.
Effectiveness: Medium-high against persistent griefers; complements Options 1 and 4.

---

11. RLN-style ZK nullifier rate-limiting (only for Scenario B)

Problem addressed: Anonymous per-user rate-limiting with automatic slashing on double-posting, fully preserving privacy mode.

Mechanism:

• Users register a commitment to their secret (one-time, possibly with onboarding PoW instead of a bond).
• Each privacy-mode action carries a nullifier H(secret, epoch, slot) and a SNARK proof of "commitment in the registered set."
• Reusing a nullifier mathematically leaks the secret → registration automatically forfeit.

Scenario A (privacy mode removed): Not applicable.
Scenario B: strongest anonymous anti-Sybil primitive available.

Code impact: 3,000+ lines, plus ZK toolchain (e.g., arkworks, halo2), circuit audit, mobile proof-generation work.

Complexity: High.
Effectiveness: Very high for its niche. Only worth the investment if privacy mode is preserved and blind-sig tokens (Option 6) prove insufficient.

---

Recommended Roadmap

If privacy mode is removed (Scenario A — simpler, recommended)

Phase 1 — Stop the current attack (days):

• Option 1 (in-flight takes quota)
• Option 2 (minimum identity age)
• Option 8 (sanity filters)

Phase 2 — Structural anti-Sybil (weeks):

• Option 3 (onboarding PoW, replaces bonds)
• Option 4 (tier system)
• Option 5 (per-epoch limits)

Phase 3 — Polish (weeks):

• Option 7 (dynamic PoW)
• Option 10 (abandonment penalties)
• Option 9 (signed-nonce challenges) — optional

Options 6 and 11 are dropped.

If privacy mode is retained (Scenario B)

Phases 1–3 as above, plus:

Phase 4 — Privacy-mode anti-Sybil:

• Option 6 (blind-signature epoch tokens) — start here
• Option 11 (RLN/ZK nullifiers) — only if Option 6 proves insufficient at scale

---

Why This Ordering

#	Option	Stops current attack	Scenario A	Scenario B	Lines
1	In-flight takes quota	Yes	yes	yes	~50
2	Min identity age	Yes	yes	partial	~50
3	Onboarding PoW	indirect	yes	yes	~200
4	Tiered trust	indirect	yes	yes	~300
5	Per-epoch limits	indirect	yes	yes	~350
6	Blind-sig tokens	no	—	yes	~800
7	Dynamic PoW	indirect	yes	yes	~250
8	Sanity filters	partial	yes	yes	~150
9	Challenge nonce	partial	yes	yes	~150
10	Abandonment penalty	indirect	yes	weak	~250
11	RLN/ZK nullifiers	no	—	yes	~3000+

---

Guiding Tradeoffs

• No sats required to onboard. Options 3 and 4 together give a free path: one-time CPU → Trial tier → first trade → reputation. No capital required.
• Removing privacy mode is a big simplification. Options 6 and 11 exist entirely to compensate for privacy mode. Dropping privacy mode eliminates the need for blind-sig tokens and/or ZK circuits — a substantial implementation saving.
• Composition multiplies effectiveness. A Sybil attacker facing (onboarding PoW) × (per-identity quotas) × (per-epoch limits) × (tier-gated PoW) hits compounded costs; any single control is weaker alone.
• Don't over-engineer. Options 1 + 2 + 8 alone — all small, all in mostrod policy — stop the attack in production today and buy time to implement the structural pieces (3, 4, 5) deliberately.