Security & limitations

Security statement

Luracoin v0.1.0 is an educational alpha. It has meaningful defensive engineering, but it has not established the consensus, operational, review, or ecosystem properties required to secure public economic value.

Do not use real money, valuable secrets, or production claims on the current testnet/devnet stack. Test balances have no promised continuity.

Trust boundaries

Asset	Trusted boundary	Must not cross into
mnemonic/private key	unlocked wallet signing context	node, RPC, explorer, P2P, logs, website
wallet password	local user-to-vault derivation	server, telemetry, repository
RPC bearer token	node data dir + Electron main/gateway server	renderer, static JS, public proxy
canonical blocks/state	one full-node data directory/process	SQLite as authority, manual live edits
Redis mempool	local policy/trusted node environment	public network service
Explorer API	public read-only data	mutation/admin/private wallet state
website	public static content/API GET client	secrets or consensus decisions

Every deployment should map filesystem users, containers, sockets, reverse proxies, and browser origins onto these boundaries explicitly.

Cryptographic primitives

Implemented cryptography includes:

• operating-system CSPRNG for wallet entropy, salts, IVs, tokens, and ping nonces;
• BIP39 256-bit entropy / 24-word English mnemonic;
• BIP39 seed derivation with passphrase LURA;
• BIP32 master/root secp256k1 private key;
• compressed SEC public key for address hashing;
• SHA-256 then RIPEMD-160 for address payload;
• Base58Check checksum;
• RFC 6979 deterministic ECDSA over secp256k1;
• strict scalar bounds and low-S signatures;
• SHA-256 and double-SHA256 protocol commitments;
• PBKDF2-HMAC-SHA256 with 250,000 iterations for wallet-password derivation;
• AES-256-GCM with random 16-byte salt and 12-byte IV for the Electron vault.

Correct primitive names do not by themselves prove system security. Composition, key lifecycle, implementation dependencies, user password strength, endpoint isolation, and consensus behavior still matter.

Wallet hardening

The desktop wallet:

• enables Electron context isolation and sandboxing;
• disables renderer Node integration;
• keeps RPC bearer reads and calls in the main process;
• exposes a narrow preload bridge rather than raw Electron/Node objects;
• stores only an authenticated encrypted vault in local storage;
• clears private in-memory state on lock;
• supports automatic lock after 1, 5, or 15 minutes, plus manual lock;
• locks on OS suspend/screen-lock signals where available;
• requires the wallet password and literal confirmation before deletion;
• validates addresses and canonical transaction fields before signing;
• separates demo mode from live node state.

Remaining wallet risks include:

• malware or a compromised OS/user account can observe keystrokes, memory, screen, or local files;
• a weak password makes offline vault guessing easier despite PBKDF2;
• renderer/application supply-chain compromise can request signing while unlocked;
• local storage is not a hardware-backed keystore;
• clipboard replacement and address-substitution attacks remain user-interface risks;
• one root key/address and no hardware-wallet/multisig support limit recovery and policy options;
• there is no independent audited transaction display device.

Back up the 24 words offline. Never store them in screenshots, cloud notes, chat, source code, issue trackers, or shell history.

Private RPC hardening

Implemented controls:

• loopback-only bind allowlist;
• high-entropy bearer token;
• exclusive token creation and requested 0600 mode;
• regular-file, owner, size, permission, identity, encoding, and whitespace checks;
• no symlink following where supported;
• constant-time token comparison;
• one unauthenticated minimal health route;
• one-megabyte request-body cap;
• readiness and Redis fail-closed submission gates;
• structured errors and exact 213-byte submission length.

Limitations:

• the bearer authorizes the whole local API rather than named users/scopes;
• there is no rate limit or attempt lockout;
• transport is HTTP because the intended boundary is local loopback;
• local processes under the same user may be able to read memory/files or send requests;
• port forwarding, containers, reverse proxies, or browser bridges can accidentally defeat loopback assumptions.

Never expose RPC through an Internet-facing proxy.

Browser-wallet gateway

When the browser build is served by the node, the gateway:

• retains the bearer server-side;
• proxies only four allowlisted wallet operations;
• uses a per-process HttpOnly, SameSite=Strict cookie;
• validates Host, Origin, and Sec-Fetch-Site signals;
• supplies no permissive CORS access;
• places bounds on request bodies and route shapes;
• serves a dedicated build directory rather than the whole source/data tree.

This narrows cross-site request risk but does not make the gateway suitable for hostile multi-user hosting. A compromised same-origin bundle can act with the user’s local wallet session. Treat its origin and static files as trusted software.

Transaction security

Implemented controls include exact fixed-width encoding, chain-bound transactions, address-to-public-key binding, deterministic signatures, strict r bounds, low-S s, sender nonces, integer balance checks, duplicate rejection, and atomic Redis nonce reservation.

Known boundaries:

• account nonces prevent replay only relative to the same chain ID and state;
• chain IDs are small alpha namespaces, not permanent globally registered identities;
• fixed zero fees are permitted and the official wallet currently uses fee zero;
• no stable replacement policy exists for a stuck sender/nonce slot;
• transaction validity does not create finality without branch-aware consensus;
• private-key compromise permits valid signatures and cannot be reversed cryptographically.

P2P hardening

Implemented controls:

• per-network magic and handshake chain ID;
• exact command registry and payload schemas;
• length validation before payload allocation;
• global and command-specific size caps;
• double-SHA256 checksum;
• peer and inbound caps;
• single-reader stream ownership and send locks;
• send/read/ping timeouts;
• bounded inventory and relay caches;
• IPv4 discovery filtering;
• exponential cooldown after sync failure;
• concurrent bounded relay so one slow peer does not serialize all sends.

Missing protections:

• transport encryption or authenticated peer identity;
• persistent peer scoring and bans;
• per-IP/subnet quotas;
• proof-of-work or cost for connection attempts;
• bandwidth/rate accounting;
• eclipse and Sybil resistance;
• diverse seed/discovery infrastructure;
• IPv6 and NAT traversal policy;
• privacy protections against topology and transaction-origin analysis;
• DDoS testing at public-network scale.

Run behind a host firewall and OS resource limits. A checksum is not authentication.

Consensus-critical limitation

The largest security gap is not cosmetic: the node does not implement competing branches, cumulative-work fork choice, reorganizations, or state rollback.

This means:

• valid proof of work is checked only for the next local block;
• a node cannot decide between two valid children by accumulated work;
• same-height divergence has no automatic convergence path;
• “confirmations” are local depth, not robust finality;
• partition recovery is not defined;
• transaction histories and balances can differ across diverged nodes;
• public mining competition is not safely supported.

No amount of frontend polish, TLS, wallet encryption, or explorer indexing compensates for this missing consensus layer.

Time and difficulty risks

The alpha requires timestamps strictly above the predecessor and no more than 500 seconds into the validator’s future. Retarget uses direct endpoint timestamps over 480 blocks with a 4× clamp.

There is no median-time-past, chain-work fork choice, or documented adversarial time-warp analysis. Production design must evaluate timestamp incentives, partition/fork interaction, minimum work, hashrate volatility, and retarget compact-encoding edge cases.

Storage and crash consistency

Implemented controls include exact versioned block locations, prefix/length rechecks, file locks, state-transition serialization, RocksDB batches in scoped operations, Redis compare-and-delete scripts, SQLite WAL/per-block transactions, identity metadata, and narrow adjacent orphan recovery.

Limitations:

• block files, multiple RocksDB databases, Redis, and SQLite are not one atomic transaction;
• there is no general verify/reindex/repair command;
• there is no branch rollback journal;
• opening one data directory from multiple writers is unsupported;
• manual corruption recovery is intentionally fail-closed and limited;
• live file-copy backup is not documented as consistent.

Operators must stop processes for coherent backups and preserve evidence on unexplained mismatch.

Explorer exposure

The public API is GET-only at the application contract and keeps private RPC separate. It bounds page sizes, reads large block summaries one at a time, validates IDs/addresses, normalizes money to strings, and gates indexed queries on readiness.

It intentionally has permissive credential-free GET CORS and no authentication. The server itself does not provide rate limiting, user quotas, abuse detection, response caching, or disk quotas.

Publishing requires an external TLS reverse proxy and explicit resource controls. Never proxy local storage paths, Redis, P2P administration, or /v1 RPC.

Website security

The Astro site is static and should contain only public assets and build-time public configuration. Risks concentrate in:

• third-party dependencies and CI/CD credentials;
• custom-domain/DNS/account takeover;
• incorrect public API origin configuration;
• unsafe rendering of API-provided strings;
• misleading stale/placeholder data;
• links or download claims that overstate alpha readiness.

Use dependency review, least-privilege deployment credentials, protected DNS/Cloudflare accounts, explicit content security headers where practical, and visible network/status labeling.

Known-key genesis

Testnet and devnet genesis material is educational and includes known public/recovery assumptions. Genesis allocations on these networks are not scarce or production-secure.

Mainnet is deliberately undefined and fails closed. This is a protective feature: no one should accidentally launch a “mainnet” from test constants.

Public-network blockers

Before a network carrying value, the project needs at minimum:

1. branch storage, cumulative work, deterministic fork choice, and reorganization;
2. reorg-safe accounts, block/transaction/address indexes, mempool, wallet history, and explorer projection;
3. audited mainnet genesis ceremony and immutable network parameters;
4. independent cryptographic/protocol/security review;
5. multi-implementation or rigorous interoperability testing;
6. adversarial network simulation, fuzzing, resource-exhaustion testing, and partition recovery;
7. durable peer discovery, scoring, diversity, and eclipse/Sybil mitigations;
8. supported verify/reindex/backup/restore/upgrade tooling;
9. release signing, reproducible-build strategy, dependency governance, and incident process;
10. explicit economics, fee policy, supply disclosure, and governance for consensus changes.

This list is not a certification checklist; deeper review may identify additional blockers.

Reporting security issues

Do not publish live exploit details or wallet secrets in a public issue. Follow the repository’s SECURITY.md reporting route and include only the minimum reproduction material needed.

Never attach a real mnemonic, private key, RPC token, data directory, wallet vault, or unredacted sensitive log. Generate isolated testnet fixtures for reports.

Safe deployment baseline

For controlled alpha use:

• dedicate an OS user and network-specific data directory;
• firewall P2P to intended test peers when possible;
• keep RPC and gateway loopback/local;
• keep Redis loopback/private and isolated by database/network;
• publish only the Explorer API, behind TLS and limits;
• run NTP/time synchronization;
• cap CPU, memory, open files, and disk;
• centralize logs without secrets;
• take stopped backups and test restoration;
• compare tip ID as well as height across controlled nodes;
• use only disposable test funds and keys.

Security documentation must evolve with implementation. When code and this chapter diverge, stop and resolve the discrepancy before treating either as a reliable control.