Skip to content

fix(simulator): default to mainnet instead of forcing testnet#2

Closed
moralpriest wants to merge 1 commit into
DEROFDN:community-devfrom
moralpriest:fix/simulator-verified
Closed

fix(simulator): default to mainnet instead of forcing testnet#2
moralpriest wants to merge 1 commit into
DEROFDN:community-devfrom
moralpriest:fix/simulator-verified

Conversation

@moralpriest

Copy link
Copy Markdown

Description

Fixes the simulator to default to mainnet mode instead of forcing testnet mode. The --testnet flag is now respected when provided by the user.

Previously, the simulator hardcoded --testnet=true, preventing users from testing mainnet behavior. This change allows the simulator to default to mainnet while still respecting the --testnet flag when explicitly provided.

Type of change

  • Bug fix (non-breaking change which fixes an issue)

Which part is impacted ?

  • Simulator

Checklist:

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • My changes generate no new warnings

License

I am contributing & releasing the code under DERO Research License (which can be found here).

Previously, the simulator hardcoded --testnet=true, preventing users from
testing mainnet behavior. The simulator would always run in testnet mode
regardless of user input.

This change:
- Removes the hardcoded --testnet=true assignment
- Defaults to mainnet when --testnet flag is not provided
- Properly respects the --testnet flag when explicitly set by user
- Adds defensive nil checking in InitNetwork() to handle missing flag

Fixes simulator network mode selection to match user expectations.
@moralpriest moralpriest closed this Feb 2, 2026
@moralpriest moralpriest deleted the fix/simulator-verified branch February 2, 2026 22:13
DHEBP added a commit to DHEBP/derohe that referenced this pull request Jun 24, 2026
…l scrub test

Addresses the DEROFDN#21 six-perspective review:

- Self-send sites set SenderVerified=true + RingSize (both decode arms): a
  wallet-authored tx has a certain sender at any ring size, so a contract-
  following consumer no longer distrusts the user's own sends. (review DEROFDN#2)
- Add Test_Attribution_Scrub_Behavior: drives the real receiver decode on a
  sim chain and asserts the scrub effect (ring2 keeps Sender+Data[0]; ring>2
  blanks Sender + zeroes Data[0]). Rebuilds until the receiver lands in a
  non-zero ring slot so the Data[0]==0 assertion has teeth. Mutation-checked.
  The source-grep guard is kept as a tripwire. (review DEROFDN#3)
- Document the (RingSize, SenderVerified, Sender) renderer truth table on the
  field; drop the redundant exported_payload[:] slice. (review DEROFDN#6, DEROFDN#9)

The <=->< bounds guard is sufficient: rpc.NewAddress panics on an
undecompressable ring key before the Publickeylist rebuild, so
len(Publickeylist)==RingSize holds and the index cannot go out of range. (review #1)
DHEBP added a commit to DHEBP/derohe that referenced this pull request Jul 2, 2026
…ecoy-probe failures (review DEROFDN#2/DEROFDN#3)

DEROFDN#2 — at ring 2 the assembly loop ("for ringsize != 2") never runs, so
curatedRingCandidates — the only decoy validator — is never invoked:
Strict garbage decoys built and could broadcast while the identical input
at ring 4 hard-errors. Fixed with a fail-closed guard beside the anon
ring-2 guard (after effective-ringsize resolution — the wallet default
can legally be 2 — and before any daemon call, so it validates offline).
Strict-only: lenient has no ring-2/ring-4 asymmetry, and its documented
silent-drop contract is load-bearing for the DEROFDN#23 CLI (Strict:false,
ambient session decoys, any ring size). Lenient ring-2 drops feed the
funnel below.

DEROFDN#3 — the registration probe treated EVERY failure as "decoy invalid":
for a decoy address the daemon's "Account Unregistered" verdict and a
transport failure return as the same opaque error (the unregistered
special-cases require self or non-zero SCID), so a transient blip in
lenient mode silently stripped all curation — the user signed a fully
random ring believing it curated. Probe errors are now classified via
isUnregisteredError (the repo's existing detection idiom): unregistered
verdict -> unchanged (Strict errors, lenient skips); any other failure ->
hard error in BOTH modes ("could not verify … — retry the send"). No
in-probe retry (Keep_Connectivity heals on ~5s; retry belongs at the send
layer). A daemon that rewords the verdict fails closed. Strict's
transient-failure message changes from "not registered" to "could not
verify" (nothing pinned the old text).

O9, same surface — decoy slot capacity: a ring holds at most ringsize-2
curated decoys, but nothing checked the supplied count: valid decoys
beyond capacity were probed, then silently never placed. Strict
over-supply is now a hard error (pre-guarded on the supplied count before
any RPC, re-checked in the validator); lenient surplus drops through the
funnel with a "no decoy slot left" record. Lenient ring-2 gets the same
upgrade, so the former log-only residual now gets the default-verbosity
summary. The guard caught an in-repo instance: the A2 finalization
fixture supplied 8 Strict decoys at ring 8; two validated and were never
placed — it now supplies exactly ring-2.

Two hardenings on the same surface:

- Lenient drops are never invisible: all four drop reasons (unparseable /
  own address / duplicate / unregistered verdict) funnel through one
  recorder — a per-decoy V(1) log and a default-verbosity reduced-curation
  summary before signing. Recording only the daemon-verdict class would
  keep the bug alive for the wallet-side classes (an all-duplicate ambient
  list from the hardcoded-lenient DEROFDN#23 CLI signs a random ring with zero
  signal on a healthy chain). TRUST NOTE on RingPreference: a malicious
  daemon can still veto lenient curation by lying "unregistered" —
  visible, not preventable wallet-side (it already controls random member
  selection); Strict is the fail-closed mode.

- Probe cost bounded and flat: registration verdicts are memoized per
  build (canonical-base-address key, shared by both call sites) — one
  probe per distinct decoy per build instead of O(decoys) per pass under
  transfer_mutex. Sound: registration is permanent; a stale unregistered
  verdict only defers the decoy to the next send. PreferredDecoys is
  capped at 256 (2x max ringsize) — hard error in both modes; list length
  is caller cost, not decoy quality.

Tests, each red pre-fix: curated_ring2_guard_test (offline: Strict
garbage at ring 2 passed every validation pre-fix);
curated_probe_classification_test (sim; client websocket killed so
IsDaemonOnline() stays true and the failure lands inside the probe's RPC
— pre-fix lenient returned curated=0, err=nil); curated_slot_cap_test
(offline, memo-seeded: lenient surplus records, Strict surplus errors at
guard and validator); curated_drop_signal_test (offline: all three
wallet-side drops recorded with reasons, no double-count across passes,
Strict records nothing); rpc_call_timeout_test gains the classification
leg (a hung daemon's probe deadline -> "could not verify", never a silent
drop). Keep_Connectivity deliberately not started in the probe test (no
quit path). RingPreference / curatedRingCandidates docs updated where the
fixes falsified them.

Test_Payload_TX / Test_Creation_TX_morecheck fail identically at base
(pre-existing), as does attribution_self_behavior_test.go's gofmt drift.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant