8 replies - 265 views - 2 thanks - 1 tippers - 4 watchers
With the power of AI I made a Monero themed tower defence game in html5.
You have to place towers to destroy the shitcoins that are stealing your Monero. If you let too many shitcoins pass you go bankrupt!
You can also buy Monero miners to earn coins every round.
There is bugs, bad graphics and other weirdness with it but you can play it here https://mtd.monero.forum/
Signature
The forum admin
@comfy Yours is a lot more detailed and thought out. Update us on the forum once you've made more progress :)
Signature
The forum admin
will do, just waking up :3
edit:
so i guess today the AI just went into a cryptographic rabbithole or somethin lol
Tower Defense RPG + Monero.forum Trading Platform
Architecture Document v1.0
Status: In Progress - Phases 1-3 Complete
Last Updated: 2026-03-23
1. Executive Summary
A cryptographically secure in-game item trading platform integrated directly into Monero.forum. Players trade valuable items using Monero with trustless escrow and full verifiability. The system prioritizes:
- No item duplication through signed Merkle tree inventories
- Tamper-evident audit logs via hash chains + blockchain anchoring
- Trustless escrow using Monero multisig
- Forum identity binding for reputation
Target: Replace d2jsp's decades-old trust-based model with cryptographic guarantees.
2. Threat Model
2.1 Adversaries
Threat Actor Capabilities Mitigation Malicious Admin Full server access, DB write access Key splitting, Merkle proofs, blockchain anchoring Item Duplicator Exploit game mechanics to create items Signed item creation, inventory proofs Trade Scammer Claim item not received, claim payment not sent Atomic swaps, multisig escrow, audit logs Man-in-the-Middle Intercept/modify trade communications Signed messages, server-side matching Forum Account Thief Hijack account to steal items 2FA, forum identity verification Replay Attacker Reuse old signed messages Nonces, timestamps, sequence numbers 2.2 Security Goals
- Item Integrity - Zero item duplication possible
- Trade Atomicity - Either both sides complete or neither
- Verifiability - Any player can verify their inventory on-chain
- Auditability - Full history reconstructable from hash chain
- Non-Repudiation - All actions attributable to forum identity
2.3 Fundamental Design Principle: Separation of Concerns
CRITICAL: The system enforces strict separation between game logic and Monero handling.
┌─────────────────────────────────────────────────────────────────┐ │ GAME SERVER │ │ │ │ HANDLES: NEVER TOUCHES: │ │ ├── Tower Defense logic ├── User Monero wallets │ │ ├── Item drops & stats ├── User deposits │ │ ├── Gold/XP progression ├── User withdrawals │ │ ├── Item ownership ├── Any Monero transactions │ │ ├── Merkle trees └── Private keys │ │ ├── Ed25519 signatures │ │ ├── Hash chain logs │ │ └── Trading engine (items only) │ └─────────────────────────────────────────────────────────────────┘ │ │ (data only - anchor_data) ▼ ┌─────────────────────────────────────────────────────────────────┐ │ FORUM INFRASTRUCTURE │ │ │ │ HANDLES: NEVER TOUCHES: │ │ ├── User Monero wallets ├── Game logic │ │ ├── User deposits ├── Item ownership │ │ ├── User withdrawals ├── In-game gold/XP │ │ ├── Trade escrow (Monero) ├── Merkle trees │ │ ├── Anchor transactions └── Game signatures │ │ └── Monero private keys │ └─────────────────────────────────────────────────────────────────┘2.4 Blast Radius Analysis
Component Compromised User Monero Risk User Items Risk Game Server NONE (no Monero access) HIGH (can modify items) Forum Node HIGH (Monero wallets) NONE (no item access) Anchor Wallet LOW (~$1 buffer) NONE (anchoring only) This separation ensures:
- Compromised game server ≠ stolen Monero
- Compromised forum wallet ≠ duplicated items
- Each component has limited blast radius
3. Cryptographic Primitives
3.1 Signature Scheme
Algorithm: Ed25519 (Edwards-curve Digital Signature Algorithm)
Rationale:
- Deterministic signatures (no random nonce issues)
- Small keys (32 bytes) and signatures (64 bytes)
- Fast verification (suitable for high-volume)
- Well-audited, no patents
- Used by Monero for transaction signing
3.2 Hash Functions
Primary: BLAKE3
- 256-bit output
- Fast, SIMD-optimized
- Arguably more future-proof than SHA-3
Secondary: SHA-256
- For tx_extra compatibility (Monero's equivalent of OP_RETURN)
- Used for auxiliary data in anchor transactions
3.3 Merkle Tree
Type: Merkle Mountain Range (append-only, efficient proofs)
Structure: root / \ h12 h34 / \ / \ h0 h1 h2 h3 | | | | item item item itemProperties:
- Items only added, never removed (except via trade)
- O(log n) proof size
- Efficient batch verification
3.4 Key Management
Server Signing Key:
- Ed25519 private key
- Split using Shamir's Secret Sharing (3-of-5)
- Key ceremony with multiple trusted parties
- Hardware Security Module (HSM) recommended for production
Key Rotation:
- New key pair every 90 days
- Old key remains valid for verification of historical items
- Revocation list published
4. System Architecture
4.1 Component Overview
┌─────────────────────────────────────────────────────────────────┐ │ Monero.forum │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐ │ │ │ Forum │ │ Tower │ │ Trading Engine │ │ │ │ Users │ │ Defense │ │ │ │ │ │ │ │ RPG │ │ ┌─────────────────┐ │ │ │ │ Identity │ │ │ │ │ Escrow │ │ │ │ │ Binding │ │ ┌───────┐ │ │ Manager │ │ │ │ │ │ │ │ Game │ │ │ │ │ │ │ │ 2FA │ │ │ Logic │ │ │ ┌───────────┐ │ │ │ │ │ │ │ └───────┘ │ │ │ Trade │ │ │ │ │ │ Reputation │ │ │ │ │ Matcher │ │ │ │ │ │ │ │ ┌───────┐ │ │ └───────────┘ │ │ │ │ └─────────────┘ │ │ Item │ │ └─────────────────┘ │ │ │ │ │ Layer │ │ │ │ │ │ └───────┘ │ ┌─────────────────────┐│ │ │ └─────────────┘ │ Crypto Layer ││ │ │ │ ││ │ │ │ ┌───────────────┐ ││ │ │ │ │ Merkle Tree │ ││ │ │ │ │ Manager │ ││ │ │ │ └───────────────┘ ││ │ │ │ ││ │ │ │ ┌───────────────┐ ││ │ │ │ │ Hash Chain │ ││ │ │ │ │ Logger │ ││ │ │ │ └───────────────┘ ││ │ │ │ ││ │ │ │ ┌───────────────┐ ││ │ │ │ │ Signer │ ││ │ │ │ └───────────────┘ ││ │ │ └─────────────────────┘│ │ │ │ │ ┌───────────────────────────────────────────────────────────┐ │ │ │ Monero Node │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────┐ │ │ │ │ │ Wallet │ │ Blockchain │ │ tx_extra │ │ │ │ │ │ (Multisig)│ │ Anchor │ │ (aux data) │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────────┘ │ │ │ └───────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────┘4.2 Data Flow
Item Creation: Game Logic → Item Data → Sign(item_data) → Merkle Tree Update → Hash Chain Append Item Trade: Seller creates offer → Sign(offer) → Escrow locks → Buyer accepts → Atomic swap signs → Monero multisig → Item transfer → Both Merkle trees update → Hash chain appends Verification: Player requests proof → Server generates Merkle proof → Player verifies signature + Merkle path + blockchain anchor
8. Implementation Roadmap
Phase 1: Foundation (Week 1-2)
- Ed25519 signing infrastructure
- Item record schema with signatures
- Basic Merkle tree implementation
- Database schema updates
Phase 2: Audit Trail (Week 3-4)
- Hash-chained audit log
- All actions logged with signatures
- Log verification API
- Admin monitoring dashboard (via /verification)
Phase 3: Blockchain Anchoring (Week 5-6)
- Monero node integration (blockchair, xmrchain)
- Transaction hash anchoring
- Periodic anchoring scheduler
- Public verification endpoint (/api/anchor/*)
Phase 4: Trading (Week 7-10)
- Merkle proofs in trade listings
- Escrow state machine
- Monero multisig wallet setup
- Atomic swap protocol
- Trade confirmation flow (with Merkle verification)
Phase 5: Disputes & Reputation (Week 11-12)
- Arbiter panel system
- Multisig dispute resolution
- Forum reputation integration
- Trust scoring algorithm
Phase 6: Hardening (Week 13-14)
- Security audit
- Penetration testing
- Incident response plan
8b. Blockchain Anchoring Details
Cost Analysis
Anchoring Frequency Anchors/Day Cost/Day Cost/Month Cost/Year Every hour 24 $0.24 $7.20 $87.60 Every 6 hours 4 $0.04 $1.20 $14.60 Every 24 hours 1 $0.01 $0.30 $3.65 Every 7 days 0.14 $0.001 $0.04 $0.52 Recommendation
Daily anchoring ($3.65/year) is sufficient:
- Items don't appear/disappear hourly
- Trades happen over hours/days
- Real-time Merkle proofs + audit log catch tampering
- Daily checkpoint proves existence
Exception: Immediately anchor after high-value trades (>$1000 XMR).
Threat Model with Daily Anchoring
Attack Detection Method Time Window Duplicate item creation Merkle proofs (real-time) ~0 Item theft (DB change) Merkle proofs + Audit log (real-time) ~0 Audit log tampering Hash chain (real-time) ~0 Fake trade creation Signed messages + escrow (real-time) ~0 Retroactive modification Blockchain anchor (daily) ~24h Conclusion
Daily anchoring is sufficient because:
- Real-time verification catches attacks before they complete
- Anchor provides external proof against retroactive state fabrication
- Combined approach = defense in depth
Anchor Wallet Design
Key Principles:
- Minimal funds - Anchor wallet holds ~$1-5 buffer only
- Automated operation - No manual intervention required
- Community funded - Users donate to keep anchoring alive
- Never touches user funds - Strict separation from forum wallet
Anchor Wallet Architecture
┌─────────────────────────────────────────────────────────────────┐ │ GAME SERVER │ │ │ │ FUNCTION: │ │ - Computes anchor_data = BLAKE3(merkle_root + audit_head) │ │ - Sends anchor_data to Forum API │ │ - Records returned tx_id + block_height │ │ │ │ NEVER: │ │ - Never touches Monero wallets │ │ - Never handles user funds │ │ - Never knows anchor wallet private key │ └─────────────────────────────────────────────────────────────────┘ │ │ anchor_data (HTTP POST / gRPC) ▼ ┌─────────────────────────────────────────────────────────────────┐ │ FORUM INFRASTRUCTURE │ │ │ │ FUNCTION: │ │ - Receives anchor_data │ │ - Creates Monero tx: send_to_self(0.0001 XMR, payment_id) │ │ - Signs with Anchor Wallet key │ │ - Broadcasts to network │ │ - Returns tx_id + block_height to Game Server │ │ │ │ ANCHOR WALLET: │ │ - Balance: ~$1-5 (~$0.001/day consumption) │ │ - Refill: Manual or when balance < 0.5 XMR alert │ │ - Funding: Community donations │ │ - Access: Forum server only (env variable / wallet file) │ │ │ │ NEVER: │ │ - Never touches game logic │ │ - Never handles item ownership │ │ - Never knows game signing keys │ └─────────────────────────────────────────────────────────────────┘Automated Anchor Flow
1. TRIGGER (cron job: daily OR on high-value trade) │ 2. GAME SERVER: │ ├── Computes anchor_data: │ └── H = BLAKE3(merkle_root + audit_chain_head + timestamp) │ ├── POST /api/anchor { data: H } │ └── Records request locally │ 3. FORUM (background worker): │ ├── Receives anchor_data (merkle_root, audit_chain_head, timestamp) │ ├── Checks Anchor Wallet balance (refill alert if < 0.5 XMR) │ ├── Creates Monero transaction: │ └── send 0.0001 XMR to self (to self = tx hash serves as proof) │ └── tx_extra contains: anchor_message (human-readable hint) │ │ NOTE: The actual anchor is the **tx_id** (transaction hash), │ not data stored in the transaction. Anyone can verify │ the tx exists at a specific block_height on the blockchain. │ ├── Signs with Anchor Wallet private key │ ├── Broadcasts to Monero network │ ├── Returns { tx_id, block_height, timestamp } │ └── Logs anchor transaction publicly │ 4. GAME SERVER: │ └── Records final anchor record: └── { tx_id, block_height, anchor_data, timestamp, confirmed: false } │ └── Confirmed when block_height is finalized (~10 blocks)
so yesterday didnt have any anchoring to the actual blockchain setup, it was only timestamps from blocks, but not actually anchoring, which is fine but not sufficient on some threat models, so now the AI implemented some of that cryptography or whatever and doing an anchoring to the actual blockchain every 24 hours
(funny it had more trouble getting monero-RPC to work (it spent hours and hours in loop troubleshooting), while for the cryptography implementation things it went smoothly af lol)
in-game anchoring tracker:
Ed25519 signed items or somethin idk:
anchoring dashboard thingy:
in-game marketplace thing working from a different session:
also spent all morning stress testing how many active users it could handle, so lots of benchmarks, lots of simulations...
since admin's version using javascript and the goal is to use no javascript i guess, server loads are handled differently
so earlier was still running on the flask server (not for production enviornment - can handle 50 users at 2 clicks per seconds)
then got it working with gunicorn sync (4 workers) instead (can handle 400 users at 2 clicks per seconds)
gunicorn gevent (4 workers) was also capping at around 400 users 2 clicks per second
gunicorn eventlet was shit and deprecated anyways
and increasing to 8 workers dont allow more users cause the bottleneck is not on the server but the actual game processing time or whatever it was even saying i dont even know
added an "autoplay" which ofc is not as smooth as with javascript but it helps aleviate the load if too many aggressive clicking users, but for now ill probably leave the autoplay disabled, manual step by step is aight i think
@admin be liek:
😹
edit:
finishing some bug fixes then will do a proof of concept with javascript
tower-defense/
├── app.py # Flask routes
├── game_core.py # Game logic
├── game_config.py # 50 waves, 6 towers, 10 enemies, skill trees
├── items.py # Item generation & crafting
├── models.py # Database for trading
├── verification/ # Blockchain verification system
│ ├── __init__.py # Module exports
│ ├── blockchain.py # Monero explorer (blockchair.com)
│ ├── activity_logger.py # Activity + transfer logging
│ ├── verification.py # Item verification
│ ├── crypto.py # Ed25519 signing + key management
│ └── merkle.py # Merkle tree implementation
├── keys/ # Cryptographic keys (gitignored)
│ ├── signing_private_key.pem
│ └── signing_public_key.pem
├── manage_saves.py # Admin tool for saves
├── templates/
│ ├── game.html # Main game
│ ├── character.html # Tower character sheets
│ ├── inventory.html # Player inventory + dashboard
│ ├── trade.html # Trading marketplace
│ └── rates.html # Rate audit page
└── README.md
templates/trade.html):models.py):pass to raise RuntimeError when cryptographic signing failsmodels.py):payment_status column to trade_listings tablemodels.py, utils/__init__.py):get_mode_suffix() function definitionutils) with explicit error if unavailablerun_with_rpc.sh):activity_logger.py):verified field serialization inconsistency - boolean True serializes as true in JSON, but DB stores integer 1compute_entry_hash() to properly convert boolean True to integer 1 before hash computationapp.py, templates/inventory.html):templates/verification.html):base.htmlapp.py, anchoring.py):mark_anchored() call in create_automatic_anchor() to save anchor detailstemplates/verification.html):GET /verification - Main dashboard pagemodels.py):create_trade_listing(): Now generates Merkle proof at listing timeget_active_listings(): Returns proof data in listing responsecomplete_trade(): Verifies Merkle proof before completing trademerkle_proof column to trade_listingsinventory_root column to trade_listingsitem_id: Item being listeditem_hash: Signed hash of the itempath: Sibling hashes to rootpositions: Left/right position at each levelinventory_rootactivity_logger.py):sequence_number: Sequential entry numberingprev_hash: Previous entry's hash (chaining)entry_hash: BLAKE3(prev_hash + entry_data)verify_audit_chain(): Full chain integrity verificationget_chain_status(): Returns chain head inforebuild_audit_chain(): Migration for existing entriesverification/anchoring.py):compute_global_root(): Merkle root of all itemsstore_merkle_root(): Stores root for anchoringanchor_via_forum_api(): Prepares anchor transactionsubmit_external_anchor(): Records external anchorverify_anchor(): On-chain verificationdaily_anchor_check(): Checks if anchoring neededapp.py):GET /api/chain/status: Chain status for dashboardPOST /api/chain/verify: Verify chain integrityGET /api/anchor/status: Anchoring statusPOST /api/anchor/prepare: Prepare anchor transactionPOST /api/anchor/submit: Submit anchor detailssequence_number, prev_hash, entry_hash to player_activityverification/crypto.py: Key generation, signing, verificationkeys/ directory with secure permissions (600)item_hash: BLAKE3 hash of canonical item datasignature: Ed25519 signature of item_hashverification/merkle.pyInventoryMerkleTree: Per-player inventory treesverify_merkle_proof(): Client-side verificationitem_hash and signature columns to items tablemerkle_roots table for anchoringactivity_logger.py):item_transfer_in, item_transfer_out, admin_transferlog_item_transfer(): Logs both parties of every transferdetect_item_discrepancies(player_id): Compares actual items vs loggedscan_all_players_for_discrepancies(): System-wide scanexpected = pickups + transfers_in - transfers_outlog_admin_action() for all admin operationstx_extra limitations (1060 byte relay limit)/rates): Public transparency page showing all rate changes@admin: There is bugs, bad graphics and other weirdness with it but you can play it here
That's the "power of AI" for you...
just as a quick update thing, currently tryna do a whole mmorpg in webgl with players able to have multiple characters as party members, with like automatic follow and automatic casting through keybinds and whatnot, should be mobile support too hopefully, with a more polished UI
rn all the 3d models and renderings are just placeholders, was just doing a "game engine" thing as a base i guess...
which i remember that streamer over there:
https://www.twitch.tv/ryuquezacotl
he was all like "oh yea i wanna build a videogame thing" but then ended up working on it for 9 whole years and just ended up becoming a whole game engine developer instead....
like aintnoway i gonna spend 9 whole years of my life just tryna get a proof of concept game engine thing... x)
anyways, started as an autobattler, so there's still some of that UI of it on there, gotta clean that up
item, inventories & cryptography will be added at a way later date, it's already fully working in V0.1, maybe do an update on it, maybe a re-write if there's a need but it's already fully working so it can wait to implement it there, and not that it's a big codebase anyways but i guess it's easier to work with smaller codebase or somethin, and automated audits are faster that way, focusing on the game part of it and whatnot
/V0.5d/docs/research$ cat RESEARCH-databases.md
Date: March 28, 2026
Context: V0.5d MMORPG with existing V0.1 cryptographic infrastructure
Purpose: Evaluate database options for production MMORPG environment
Given existing Ed25519 cryptographic signing from V0.1, database selection should prioritize:
Recommendation: PostgreSQL with proper security hardening
From V0.1-NoJS implementation:
Database must support:
Pros:
Security Features:
For Your Use Case:
-- Item table with cryptographic verification
CREATE TABLE items (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
item_data JSONB NOT NULL,
signature BYTEA NOT NULL, -- Ed25519 signature
hash BYTEA NOT NULL, -- BLAKE3 hash
owner_id UUID REFERENCES players(id),
created_at TIMESTAMP DEFAULT NOW(),
merkle_leaf_index INTEGER
);
-- Audit log for transfer verification
CREATE TABLE transfer_log (
id BIGSERIAL PRIMARY KEY,
item_id UUID REFERENCES items(id),
from_player UUID,
to_player UUID,
merkle_root BYTEA, -- Root hash at time of transfer
block_height INTEGER, -- Monero anchor
tx_hash VARCHAR(64), -- Monero transaction
signature BYTEA -- Server signature
);
Hardening:
Status: INSECURE FOR PRODUCTION
Why NOT for production:
Use case: Development, single-player only
Status: Not recommended
Concerns:
If forced to use:
Status: REJECTED
Recent security issues:
Even with hardening: Too high risk for financial items
Status: Use as cache layer only
Purpose:
NEVER for:
┌─────────────────────────────────────────────────────────────┐
│ APPLICATION LAYER │
│ Flask + Game Logic + Cryptographic Verification │
└──────────────────────┬──────────────────────────────────────┘
│ (TLS 1.3, Certificate Auth)
▼
┌─────────────────────────────────────────────────────────────┐
│ DATABASE LAYER │
│ PostgreSQL (Primary) │
│ ├── Items table (with signatures) │
│ ├── Transfer logs (hash-chained) │
│ └── Audit trail (immutable) │
└──────────────────────┬──────────────────────────────────────┘
│ (Streaming replication, TLS)
▼
┌─────────────────────────────────────────────────────────────┐
│ REPLICA LAYER │
│ Read replicas for verification dashboard │
│ Delayed replica (1 hour) for disaster recovery │
└─────────────────────────────────────────────────────────────┘
1. Connection Security
# pg_hba.conf
hostssl items_db app_user 10.0.0.0/8 cert
hostssl items_db app_user ::1 cert
2. Data Encryption
3. Access Control
4. Audit Requirements
5. Backup Strategy
Phase 1: Dual-write (1 week)
# Write to both, read from SQLite
def create_item(item_data):
sqlite_create(item_data)
postgres_create(item_data) # Async, log failures
Phase 2: Switchover (1 day)
Phase 3: Cleanup
Merkle Tree Calculations:
Audit Log Queries:
Verification Dashboard:
| Component | Monthly Cost |
|---|---|
| PostgreSQL Primary (16GB RAM) | $200 |
| Read Replicas (2x) | $300 |
| Backup Storage (500GB) | $50 |
| Monitoring (DataDog) | $100 |
| Total | $650/month |
vs SQLite: $0, but risk of total data loss
For V0.5d MMORPG:
Security Level: Production-ready for financial items
Audit Capability: Full hash-chained verification preserved
Performance: Sub-10ms query times for item lookups
Document Status: Research Complete
Next Step: Implement PostgreSQL migration plan