VS1984 Technical Whitepaper v1

VS1984 is the Anonymous Internet Layer for the new era. It is not only a communication tool, but a combination of a “decentralized content platform + anonymous economic system”.

📘 1. Overview & System Goals

VS1984 is a decentralized anonymous content network for global users. It builds a resilient, privacy-preserving, and sustainable open network via serverless peer-to-peer communication, a custom blockchain, an anonymous identity system, and multi-layer encryption.

The system’s goals are as follows:

1.1 Strong Anonymity

Through the dual-identity model of Guard ID / Real ID, VS1984 ensures:

• Network-layer identity and on-chain identity are fully decoupled
• No way to infer real routes from the chain
• No way to infer the real content publisher from the P2P network

1.2 Anti-Censorship

The system has:

• No central server
• No single access point
• No fixed external dependency

Therefore:

• It cannot be shut down
• No single piece of content can be blocked
• Message sources cannot be traced
• On-chain content records cannot be deleted

1.3 Protection Against Man-in-the-Middle Attacks

With on-chain certificate pinning + forward-secure TLS, VS1984 achieves:

• Resistance to nation-state-level MITM attacks
• Even if root CAs are replaced, communication cannot be intercepted
• All node handshakes must validate pins consistently

1.4 Serverless, No Trust Assumptions

All VS1984 core modules are:

• Peer-to-peer
• Non-centralized
• Governed by autonomous logic chains
• Based on self-verifiable encryption

Users do not need to trust any organization.

1.5 Sustainable Content Economy (Future)

Planned capabilities include:

• Paid BT content
• On-chain settlement
• Automatic key distribution
• A closed revenue loop for content creators

📘 2. Background & Motivation

Over the past decade, the global internet has shifted from an “open network” to a platform-centric system that is easy to censor and easy to surveil. Traditional centralized architectures exhibit clear weaknesses in the following dimensions:

2.1 Inherent Problems of Centralized Services

Easy to Censor

Once communication relies on servers (e.g., Telegram, Signal, WhatsApp):

• Servers can be blocked
• IP addresses can be blackholed
• Protocols can be identified via DPI (Deep Packet Inspection)
• Metadata can be collected at scale

Content platforms (Twitter, Reddit, WeChat Official Accounts, etc.) are even more naturally censored and blocked.

Uncontrollable Privacy

Even with end-to-end encryption (E2EE), as long as:

• Servers control connection graphs
• The service knows who is talking to whom
• The service can control key distribution
• The CA root trust can be redefined

Privacy is never pure.

The most typical threat is nation-state man-in-the-middle (MITM) via:

• Replacing root certificates
• Injecting forged certificates
• Hijacking TLS handshakes

to bypass traditional cryptographic protections.

Data Stored on Centralized Platforms

All content is controlled by platforms:

• It can be deleted
• It can be tampered with
• It can be traced back
• It can be used for profiling, commercial mining, or legal persecution

When users do not control the data, “freedom” is an illusion.

2.2 Potential & Limitations of P2P Networks

P2P networks try to escape centralization, but traditional implementations have issues:

Hard to Defend Against MITM

P2P systems using standard TLS still rely on the CA trust model. Without on-chain pinning, nation-state attackers can still forge certificates.

No Anonymous Content Publishing

In classic DHTs (Kademlia, libp2p DHT):

• Node ID = routing-layer active ID
• Content publishers can be traced via routing paths
• It is hard to decouple chain identity from network identity

VS1984’s dual-identity mechanism addresses this.

Technical Reasons BT Can Only Be “Free”

BT is decentralized but lacks:

• An embedded economic system
• Serverless payment channels
• Real revenue channels for content creators

VS1984 provides on-chain transactions + key distribution, enabling paid BT content.

2.3 Limitations of Traditional Blockchains & Room for Improvement

Traditional blockchains (Ethereum, Bitcoin, etc.) are decentralized, but not suitable as anonymous content publishing systems:

• Chains are fully transparent → privacy risk
• High transaction fees → unsuitable for high-frequency messaging
• Node network behavior cannot be hidden
• No direct way to store keys or sensitive data
• Routing depends on external networks (non-anonymous)

VS1984’s chain is:

• A self-developed lightweight chain
• Multi-logic chain design
• Not storing any real network information of users
• Supporting on-chain certificate pinning
• Used for content hashes, transactions, and key distribution, not for logging communication flows

Functionally, it is closer to an “auxiliary encrypted ledger for anonymous networks” than a traditional public chain.

2.4 Why VS1984?

Because the world needs a system that does not rely on servers but still provides complete encrypted communication + anonymous content publishing + anonymous transactions.

VS1984 is designed for scenarios such as:

• ✔ Anonymous chat
• ✔ Anonymous voice calls
• ✔ Uncensorable content publishing
• ✔ Untraceable on-chain transactions
• ✔ Paid BT content platforms
• ✔ A globally distributed, secure communication network
• ✔ An encrypted ecosystem beyond the reach of nation-state censors

When traditional platforms shut down, censorship rises, and communication is restricted, VS1984 can still operate.

📘 3. System Value Proposition

Business Edition (for external / commercial presentation)

VS1984 is not merely a technical project or a communication tool. It is an “Anonymous Internet Layer”.

What it creates is an entire digital ecosystem that keeps operating freely under censorship pressure, geopolitical tension, network blocking, and privacy violations.

Below are the core value propositions of the system.

3.1 Complete Anonymous Communication

In today’s internet, each communication action exposes:

• IP address
• Connection relationships
• Timing patterns
• Content type
• Behavioral models

VS1984’s architecture guarantees:

✔ No servers required

✔ No reliance on centralized CAs

✔ No exposed network identity (Guard ID ≠ Real ID)

✔ No delivery receipts (to avoid path correlation)

✔ Onion routing & multi-path forwarding

Ultimately achieving:

A communication layer that cannot be censored, traced, or blocked.

This is something traditional IMs (WhatsApp, Telegram, Signal) can never achieve.

3.2 Undeletable Content Publishing

VS1984 provides an anonymous content publishing mechanism:

• Content hashes are written to the chain
• Real ID is used only on-chain, never in routing
• No servers
• Content is immutable and undeletable
• Anonymous creators never need to be exposed

This is:

• ✔ Freer than channels
• ✔ More censorship-resistant than Weibo/Twitter
• ✔ More anonymous than typical blockchains
• ✔ Safer than classic BT

VS1984 is the first global network to offer anonymous yet verifiable content publishing.

3.3 Decentralized Paid BT Content System (Core for Commercial Ecology)

VS1984’s most commercially promising ability is:

Enabling BT content creators to charge users directly, without platforms or servers.

Flow:

1. The author uploads an encrypted BT content bundle
2. VS1984 writes the content hash to the main chain, and the content to subchains
3. Users pay using on-chain tokens
4. The system automatically distributes and transmits decryption keys through the P2P network
5. No intermediaries take a cut
6. The whole process is anonymous
7. It is impossible to censor or block it

This makes it possible to have:

• Distributed content marketplaces
• P2P Netflix-like platforms
• Global monetization for every content creator
• No servers
• No need for App Store / Google approval
• No geopolitical restrictions

This is a completely new business model.

3.4 Network Infrastructure Resistant to Nation-State Attacks

The VS1984 encryption system includes:

• Certificate pinning stored on-chain
• Mandatory pin verification during handshakes
• Forward-secure TLS
• A custom inner layer to prevent TLS downgrade and replay attacks
• Multi-hop forwarding to hide paths

Even if a nation-state attacker controls:

• CA root certificates
• ISPs
• DNS
• Certificate injection infrastructure
• Full-network DPI systems

They still cannot:

• Decrypt content
• Inject fake nodes
• Hijack TLS
• Forge handshakes
• Locate the real position of nodes

Traditional Telegram / Signal / WhatsApp / Matrix cannot reach this level. VS1984 can.

3.5 Steganography-Based Login & Node Sharing

VS1984’s steganography system is not only a “login mechanism” but also:

A mechanism to share anonymous node routing information across platforms.

It solves real-world problems:

• How a node shares its routing entry, Guard ID, and access parameters
• Securely with friends or users
• Without exposing identity
• Without using phone numbers, emails, or accounts

This is a future paradigm for node distribution in Web3 & anonymous networks. VS1984 has already implemented it.

3.6 Serverless & Naturally Scalable

VS1984 scales naturally because:

• Communication is P2P
• Content is P2P
• Keys are P2P
• The blockchain is lightweight
• Routing is distributed
• No central bottlenecks
• No database bottleneck
• The more nodes exist, the stronger the network becomes

Business implications:

✔ Near-zero marginal cost

✔ Larger network → greater stability (positive-sum scaling)

✔ No need for server capacity planning

Traditional server-based architectures will never reach this.

3.7 Future Ecosystem: Distributed “Darknet + Marketplace + Social Network”

The VS1984 ecosystem includes:

• ✔ Anonymous social networking
• ✔ Distributed content stores
• ✔ Anti-censorship publishing
• ✔ Anonymous payments (cross-chain)
• ✔ Multi-platform clients
• ✔ Anonymous search engine
• ✔ Decentralized account system (Stego + Real ID)

VS1984 is:

An infrastructure protocol for the future internet.

It can support:

• Media
• Social networks
• Content platforms
• Distributed applications
• Anonymous e-commerce
• Anonymous communities
• Anonymous data markets

📘 4. System Architecture

VS1984’s overall architecture consists of:

1. Application Layer
2. Content & Blockchain Layer
3. Encryption Layer
4. P2P Networking Layer
5. Platform / Runtime Layer

Core principles:

• Strong anonymity (Guard ID ≠ Real ID)
• Anti-censorship
• Scalability
• Multi-layer encryption
• Content economic model (main chain + subchains)

4.1 High-Level Architecture Diagram

┌────────────────────────────────────────────┐
│             Application Layer              │
│ ────────────────────────────────────────── │
│  • Encrypted Chat  • Voice (WebRTC)        │
│  • File Transfer  • BT Paid Content (Fut)  │
│  • Anonymous Content Publish               │
│  • Web GUI (Future)                        │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│         Content & Blockchain Layer         │
│ ────────────────────────────────────────── │
│  • Main Chain:                             │
│        Content Hash, Tx, Real ID           │
│  • Subchains:                              │
│        Encrypted Content Payloads          │
│  • Fee Model:                              │
│        Size-based On-chain Fee (Future)    │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│        Encryption Layer                    │
│ ────────────────────────────────────────── │
│  • TLS Layer:                              │
│        Forward Secrecy, ECDHE, PKI Pin     │
│  • Custom Inner Layer:                     │
│        Secondary Encryption, Validation    │
│  • Onion Routing Layer:                    │
│        Multi-hop Encrypted Relay           │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│        P2P Networking Layer                │
│ ────────────────────────────────────────── │
│  Guard ID  • UPnP NAT Traversal            │
│  Kad-Lite                                  │
│  Anycast Multi-Path Routing                │
│  Hint-based Relay Routing                  │
└────────────────────────────────────────────┘

┌────────────────────────────────────────────┐
│       Platform / Runtime Layer             │
│ ────────────────────────────────────────── │
│  Linux (Current)                           │
│        → macOS → Windows                   │
│        → Mobile (Future)                   │
│  Libuv Event Loop • File I/O               │
└────────────────────────────────────────────┘

4.2 Module Relationship Diagram

Module Relationship
             ┌───────────────┐
             │   User Apps   │
             │ (Chat/Voice…) │
             └───────┬───────┘
                     │
            ┌────────▼────────┐
            │ Content / Chain │
            │  Main + Subchain│
            └────────┬────────┘
                     │
     ┌───────────────▼─────────────────┐
     │       Encryption Layer          │
     │ TLS → Inner → Onion (Multi-hop) │
     └───────────────┬─────────────────┘
                     │
           ┌─────────▼─────────┐
           │     P2P Layer     │
           │Guard ID • Kad-Lite│
           │Anycast            │
           └─────────┬─────────┘
                     │
            ┌────────▼────────┐
            │ OS / Platforms  │
            │ Linux → macOS…  │
            └─────────────────┘

4.3 Architecture Explanation

(1) Application Layer

Includes:

• Encrypted chat
• Voice (WebRTC)
• File transfer
• Anonymous content publishing
• Search & browsing
• BT paid content system (future)
• Web GUI console (future)

(2) Content & Blockchain Layer

Provides:

• Content immutability
• Verifiability
• Payments
• Key distribution
• Certificate pinning

Core design:

<div>Main Chain</div>
<div>Content hash, Real ID, transactions</div>
<div>Lightweight and fast, unified index</div>

<div>Subchains</div>
<div>Encrypted content body, certificate pins</div>
<div>Store large data without polluting main chain</div>

Future extensions:

• Large content charged by size
• Subchains synchronized on demand
• Highly scalable content network

(3) Encryption Layer

✔ TLS (Forward Secrecy)

• X25519 / ECDHE
• MITM resistance
• On-chain pin verification

✔ Custom Inner Protocol

• Second-layer encryption
• TLS downgrade protection
• Extra encapsulation

✔ Multi-hop Onion Encryption

• Per-hop encryption
• Hidden paths
• Hard to analyze

(4) P2P Networking Layer

Core components:

• TCP
• UPnP
• Guard ID
• K-Bucket
• XOR (Kad-Lite)
• No ACK
• TTL + deduplication

Message flow:

Neighbor → hint-based relay → 5 closest XOR nodes → multi-path dissemination

(5) Platform Layer

Current:

• Linux (stable)

Future:

• macOS
• Windows
• iOS
• Android

Shared:

• libuv event loop
• Custom crypto stack
• Same P2P routing logic across platforms

📘 5. Identity System

The VS1984 identity system is one of the core innovations of its anonymous network design. It uses a Dual-ID Model to separate anonymity, untraceability, and on-chain operations.

The two identities are:

• Guard ID: used for network transport, routing, neighbor management, and node discovery
• Real ID: used for on-chain content publishing, transaction signing, and certificate pinning

These two identities share no mathematical, network, storage, or behavioral linkage.

Their complete separation guarantees:

“On-chain identity ≠ network identity” “Network behavior ≠ content publisher” “No accounts, no linkage information.”

5.1 Guard ID: Network Identity

Guard ID is the “business card” at the VS1984 network layer, used for:

• Establishing TCP connections
• Routing and relaying
• K-bucket storage
• XOR distance calculations
• Hint-based path discovery
• P2P encrypted channel identification

Characteristics:

✔ Not stored on-chain

Guard IDs are never written to the blockchain, so network behavior is not bound to on-chain identity.

✔ Resettable

Users can regenerate Guard IDs without affecting their Real IDs or on-chain assets/content.

✔ Safe to disclose

Sharing a Guard ID does not reveal any personal identity or privacy.

✔ Used in steganographic routing sharing

Guard IDs’ routing entry information is embedded inside stego images, which can be shared with others to connect to your node.

✔ Guard ID authenticity is guaranteed by certificate pinning

Guard IDs do not rely on centralized servers or CAs. Instead:

• Each Guard ID corresponds to a TLS certificate
• Nodes write the certificate pin to the blockchain
• Other nodes verify pins from the chain during handshakes
• If pins mismatch, the connection is rejected as an attack attempt

This:

• Prevents anyone from impersonating your Guard ID
• Prevents MITM from hijacking Guard ID routing
• Prevents malicious nodes from posing as your friends
• Ensures that entries in routing tables refer to genuine nodes

Most importantly:

Real IDs remain pure (used only for content publishing and never used in network routing).

This preserves strict identity separation.

5.2 Real ID: On-Chain Identity

Real ID is:

• The signing identity for on-chain content publishing
• The owner of on-chain transactions
• The identity that writes certificate pins to the chain

When a user first launches the client, a Real ID is automatically generated.

✔ No registration

No phone number, email, account, or password is required.

✔ No attached metadata

Real IDs contain no personal information, IP, or device data.

✔ Never used in the P2P routing layer

No one can infer the existence of a Real ID from network behavior.

✔ Non-derivable

Mathematically impossible to derive Real ID from Guard ID. Network-wise, behavior is never linked back to Real ID.

5.3 Relationship Between Guard ID & Real ID: Complete Separation

<div>Usage</div>
<div>Routing, connections, transport</div>
<div>On-chain content publishing, transactions, pinning</div>

<div>On-chain?</div>
<div>❌ Not written to chain</div>
<div>✔ Written to chain</div>

<div>Resettable?</div>
<div>Can be rebuilt anytime</div>
<div>Generated on first launch, typically persistent</div>

In one sentence:

Guard ID = anonymous communication entry point Real ID = anonymous content publisher / anonymous economic account

They are fully decoupled, forming the foundational infrastructure for anonymous communication and anonymous content publishing.

5.4 Steganography: Anonymous Bridge for Guard IDs

Steganography is used to:

• Hide Guard ID routing entries (node address + port + crypto parameters)
• Inside ordinary PNG/JPG images
• Users share these images via WhatsApp, Telegram, email, etc.
• Recipients can import the images to connect to your node automatically
• Images contain no personally identifiable or traceable information

This allows users to:

✔ Use no account

✔ Use no server

✔ Avoid exposing identity

This is something that is extremely hard to achieve in traditional P2P networks.

5.5 Commercial Value of the Identity System

VS1984’s identity model is not just a security design but also a foundation for business:

1. No KYC Required

Users from any region can start using the system immediately.

2. Identity Not Bound by Legal Frameworks

The system is invisible and unauditable to regulators.

3. Foundation for a Future “Anonymous App Ecosystem”

• Anonymous content platforms
• Decentralized content marketplaces
• P2P paid channels
• Decentralized forums
• Fully anonymous communities
• Special enterprise editions

VS1984’s Dual-ID model underpins all of this.

📘 6. Encryption Model

VS1984’s encryption system adopts a Layered Encryption Model, protecting communication security, anonymity, and tamper resistance from multiple angles.

The system’s encryption layers are divided into three tiers, forming the foundation of VS1984’s communication security:

┌────────────────────────────────┐
│      Layer 3: Onion Routing    │
│ Multi-hop routing encryption   │
├────────────────────────────────┤
│  Layer 2: Inner Custom Crypto  │
│secondary encryption & defenses │
├────────────────────────────────┤
│        Layer 1: TLS 1.3        │
│        Forward secrecy         │
│certificate pinning against MITM│
└────────────────────────────────┘

6.1 Layer 1: TLS (Forward Secrecy & MITM Protection)

The TLS layer provides Forward Secrecy, using modern algorithms:

• X25519 / ECDHE for key exchange
• AES-GCM / ChaCha20-Poly1305 for encryption
• TLS 1.3 handshake structure

6.1.1 Certificate Pinning On-Chain

Traditional TLS has a fundamental weakness:

The CA trust model can be controlled by nation-state attackers → Inject forged root certificates → Break HTTPS/TLS at scale

VS1984 solves this via:

✔ Certificate pins written to the blockchain

✔ Mandatory pin verification during handshake

✔ Pins bound to Guard IDs

This ensures:

• Even with full control of system CAs, attackers cannot forge identities
• Even if nation-state actors replace root certificates, MITM still fails
• Even under ISP-level mass interception, traffic cannot be decrypted

This is beyond what traditional TLS deployments can provide.

6.1.2 TLS Provides True Forward Secrecy (FS)

Once the TLS handshake is established:

• Session keys are not derived directly from certificates
• Session keys cannot be derived from historical traffic
• Past messages cannot be decrypted even if keys are compromised later
• Even if key stores leak, past content stays safe

Forward secrecy is fully provided by TLS.

6.2 Layer 2: Custom Inner Encryption Protocol

This layer does not replace TLS; it reinforces it.

6.2.1 Defense in Depth

Includes:

• Protection against TLS downgrade, redirection, or split attacks
• Obfuscation of TLS handshake fingerprints against passive analysis
• Additional anonymity logic (padding, cover traffic)
• Enhanced node authentication

6.2.2 Core Responsibilities of the Inner Protocol

✔ Derive secondary keys from the TLS layer

→ All internal messages are re-encrypted, increasing covertness.

✔ Provide message-level signatures (not tied to Real IDs)

→ Ensures per-hop authorization validity.

✔ Provide an internal session structure

→ Controls P2P message formats and verification.

6.2.3 What the Inner Protocol Does Not Do

• ❌ It does not provide FS (this is TLS’s job)
• ❌ It does not handle long-term message encryption alone
• ❌ It does not handle handshake encryption alone
• ❌ It does not replace TLS’s core security

In short:

Inner Layer = security and obfuscation enhancement on top of TLS, not a replacement for TLS’s FS.

6.3 Layer 3: Multi-Hop Onion Routing

This layer provides the strongest anonymity.

Every message (except direct one-hop connections) traverses:

• Multiple Guard nodes
• Different symmetric keys at each hop
• Nested encryption layers
• Each relay node can only decrypt a single layer

Each node only sees:

• The previous hop
• The next hop
• The ciphertext for its own layer

6.3.1 No ACK Mode as a Strong Anonymity Baseline

To maximize anonymity:

• No delivery receipts
• No return data that can expose paths
• No session-style fingerprints
• Reduced susceptibility to timing attacks
• TTL used to control expansion

Anonymous messages have no ACK by default, to avoid path correlation.

6.3.2 Multi-Path Anycast Routing

When no direct path exists:

• The same message is sent to the XOR-closest set of nodes (default 5)
• Multiple paths advance in parallel
• Any successful path is enough for delivery
• The network does not depend on deterministic routing

This improves both anonymity and robustness.

6.4 Combined Defense Model of the Three Layers

<div><strong>TLS</strong></div>
<div>Forward secrecy, MITM resistance, on-chain pinning</div>
<div></div>

<div><strong>Inner Protocol</strong></div>
<div>Prevents TLS downgrade, enhances unobservability, normalizes formats</div>
<div></div>

<div><strong>Onion Layer</strong></div>
<div>Hides routing paths, resists analysis, ensures anonymity</div>
<div></div>

Ultimately:

Even if an attacker controls ISPs, CAs, or the network, they cannot correlate behavior, cannot break content, and cannot trace message paths.

📘 7. P2P Network

We now enter one of the core technical modules of the entire system:

P2P Networking Layer

VS1984’s P2P network is a serverless, fully distributed, strongly anonymous, and censorship-resistant network layer.

It is built atop three core components:

1. TCP transport + UPnP NAT traversal
2. Guard ID–based node identity system
3. Kad-Lite Anycast Routing (anonymous DHT-style routing)

7.1 Transport: TCP + UPnP NAT Traversal

VS1984 uses:

• TCP as the transport (maximum compatibility)
• UPnP for NAT mapping
• No STUN / ICE / TURN / TCP fallback for the core network (these are used only in the WebRTC voice subsystem)

Reasons:

✔ Simple NAT traversal logic

TCP + UPnP are among the least blockable NAT modes.

✔ No need for public STUN/TURN servers

Avoids centralized dependencies and censorship points.

✔ Well-suited to anonymity

UPnP allows nodes to function without exposing centralized infrastructure.

7.2 Node Discovery: Guard ID + K-Buckets

VS1984 uses a Kademlia-like K-bucket structure, with anonymity enhancements:

• XOR distances
• Bucketed storage
• Fixed bucket size (e.g., K = 20)
• When new nodes join:
• Compute XOR distance between local Guard ID and target ID
• Return several nodes closest to the target (e.g., 20 nodes)

Benefits:

✔ Fast distributed neighbor discovery

✔ No seed servers required

✔ Naturally scaling routing tables

✔ No exposure of full network topology

7.3 Hint Paths (Relays That Hide Real IPs)

Some nodes cannot expose their IPs.

In this case:

• Router A provides a “hint entry” to the new node
• The hint entry does not contain a real IP
• It only contains a relay pointer describing “who to contact next”

This is conceptually similar to Tor’s entry nodes, but more lightweight.

7.4 Routing Strategy: Kad-Lite Anycast Routing (Core)

VS1984 does not use classic Kademlia’s find_node() or recursive lookups, because:

• RPC calls expose routes
• Susceptible to timing attacks
• Insufficient anonymity

Instead, VS1984 uses Anycast-style anonymous broadcast routing.

Kad-Lite Anycast Routing Process

1. If the target is a neighbor → send directly (point-to-point)
2. If a hint exists → route according to the hint
3. Otherwise:

• From the routing table, select 5 nodes whose XOR distance to the target is smallest
• Send the same ciphertext to these 5 nodes simultaneously

4. Each relay repeats the same logic
5. TTL / dedup / source-exclusion prevent uncontrolled diffusion

Advantages:

✔ Hard to analyze the real communication path

✔ No deterministic shortest path → very strong anonymity

✔ Multi-path fault tolerance and robustness

✔ No ACKs → path exposure is minimized

This implements:

A strongly anonymous, high-performance P2P routing system.

7.5 Node Leave Notification (Leave Gossip)

When a node disconnects:

• Its neighbors broadcast “node offline” messages
• All nodes that store hints for it remove those entries
• Routing tables stay fresh
• No detailed network topology needs to be revealed

7.6 Routing-Layer Security

With pin checking:

• If a Guard ID’s pin does not match → connection is rejected
• Routing tables cannot be polluted by fake or MITM nodes
• Real IDs never participate in routing → never exposed

Thus VS1984 simultaneously optimizes anonymity, security, and decentralization.

📘 8. Anonymous Messaging System

VS1984’s messaging system is designed around one core principle:

“Strong anonymity is more important than deterministic delivery.”

In truly anonymous communication:

The path of a message should be non-inferable, unreconstructable, and non-reversible. This is more important than guaranteeing absolute reliability.

Thus, VS1984’s messaging system uses:

• No-ACK mode
• Multi-hop onion encryption
• Multi-path anycast routing
• TTL + dedup control
• Non-directional design

to achieve extreme anonymity.

8.1 No-ACK Mode: Foundation of Strong Anonymity

Traditional systems depend on ACKs:

• TCP ACKs
• Application-layer ACKs (e.g., double ticks in WhatsApp/Telegram)

ACKs cause:

❌ Paths can be inferred

Because ACKs always “go back”, they create path correlations.

❌ Timing fingerprints exist

Attackers can measure RTTs and build behavioral models.

❌ Persistent “session relationships”

Adversaries can observe who maintains ongoing conversations.

VS1984 therefore intentionally avoids ACKs.

✔ Messages use “best-effort delivery”

✔ No return information that reveals direction

✔ No session correlated path information

✔ No easy RTT-based correlation

8.2 Multi-Path Delivery

When sending a message to a target Guard ID:

1. Is the target a neighbor?

• Yes → direct point-to-point send
• No → go to step 2

2. Is a hint available?

• Yes → relay via hint
• No → enter Anycast routing

3. Anycast routing:

• Select the 5 nodes from K-buckets that are XOR-closest to the target
• Send the same ciphertext to all 5

4. Relay nodes repeat this logic.

Result:

• Multiple paths deliver in parallel
• Any successful path is sufficient
• Attackers cannot know which path is the main one
• True path and decoy paths are indistinguishable

This is the core of obfuscated routing.

8.3 TTL & Loop Prevention

To avoid flooding and message bouncing, VS1984 introduces:

8.3.1 TTL (Time To Live)

Each message carries a TTL to:

• Limit propagation scope
• Avoid broadcast storms
• Gracefully drop messages
• Ensure network expansion ≠ TTL growth (Kad-Lite property)

8.3.2 Deduplication

Each node keeps a short-term LRU hash table:

• On receiving message A (msg_id)
• If the same msg_id is seen again → drop the message

This:

• Prevents flooding attacks
• Blocks replay attacks
• Removes duplicated multi-path copies
• Avoids loops

8.4 Source Exclusion Rule

To avoid message “bounce loops”:

• Each message contains a hash of the previous hop
• Current nodes will not forward the message back to the previous hop
• Messages always flow toward XOR-closer nodes
• The real path structure is not revealed
• The network stabilizes while keeping paths unreconstructable

8.5 Encrypted Message Format

A simplified structure:

{
    msg_id: SHA256(payload + timestamp),
    ttl: 8,
    guard_target: <target Guard ID>,
    onion_layers: [
        layer_3,
        layer_2,
        layer_1
    ],
    signature: sig(inner_payload)
}

Characteristics:

✔ No Real ID

✔ Guard IDs only

✔ No source IP

✔ No return address

✔ No ACK information

✔ No inferable direction

This is the minimal secure structure for anonymous messaging.

8.6 No ACK — So What About Reliability?

Chat Messages: Eventual Consistency (No 100% Guarantee)

For reference:

• Tor Messenger
• Ricochet
• Cwtch

All of these high-anonymity systems do not rely on ACKs.

Clients can:

• Auto retry sending
• Indicate “possibly undelivered” in the UI
• Allow users to manually retry

On-Chain Content/Transactions: Ensured by Blockchain Diffusion

Eventual consistency is handled on-chain, via task mechanisms for block propagation, not via ACKs.

This means:

• Chat does not need ACKs
• The blockchain ensures finality
• System anonymity is maximized

8.7 Commercial Value of Anonymous Messaging

VS1984’s anonymous messaging system offers:

• Tor-level anonymity
• Telegram-like experience
• Cwtch-like architectural strengths
• Stronger anonymity than Matrix/Signal

Applicable to:

✔ Global anonymous chat

✔ Secure communication for organizations/enterprises

✔ Uncensorable communication backbone

✔ Safety lifelines in high-risk environments

✔ Anonymous content creation ecosystems

✔ Global anonymous collaboration networks

📘 9. Voice System

VS1984’s voice system uses the WebRTC stack and is architecturally independent from the core anonymous P2P network.

Reason:

The anonymous TCP transport layer is optimized for anonymity, but cannot fully meet the strict latency requirements of real-time audio/video. WebRTC, on the other hand, is the most mature real-time media technology with strong NAT traversal.

This chapter explains:

• WebRTC’s role in VS1984
• NAT traversal (ICE / STUN / TURN / TCP fallback)
• Why the voice system is independent of the anonymous network
• How signaling is carried through the anonymous network

9.1 Role of the Voice Subsystem: A Plugin, Not a Router

Key principle:

Voice calls = an independent real-time media channel

It does not break anonymity because:

• Voice signaling → travels through VS1984’s anonymous P2P network
• Audio media streams → use WebRTC’s P2P channels
• Does not participate in on-chain logic
• Does not affect Guard ID / Real ID separation
• Does not affect the content publishing system

In other words:

VS1984’s anonymous network “guides the way”; WebRTC “carries the sound”.

Clear division of responsibilities.

9.2 Signaling Path: Fully Anonymous & Untraceable

WebRTC signaling includes:

• SDP
• ICE candidates
• RTP/SRTP parameters
• Internal device fingerprints (WebRTC-specific)

In VS1984:

✔ All signaling goes over the anonymous P2P network

✔ Signaling traverses multiple hops, with onion encapsulation and Guard ID routing

✔ No real IP exposure in the signaling path

✔ No location or path information is exposed

Result:

WebRTC signaling is anonymous.

9.3 Media Channels (Audio Streams) via WebRTC ICE + SRTP

Steps for establishing a call:

1. Both parties exchange SDP via the anonymous network
2. WebRTC at each endpoint attempts to build a media connection
3. Uses ICE (Interactive Connectivity Establishment)
4. Prefers UDP
5. Falls back to TCP if necessary
6. If still failing → TURN (if provided by community/users)
7. Finally builds SRTP-encrypted media channels

9.3.1 NAT Traversal Techniques Involved

The following table shows which components belong to VS1984 vs WebRTC:

<div>STUN</div>
<div>Obtain public candidates</div>
<div>❌ External/WebRTC only</div>

<div>ICE</div>
<div>Candidate prioritization</div>
<div>❌ External/WebRTC only</div>

<div>TURN</div>
<div>Optional relay server</div>
<div>❌ External/WebRTC only</div>

<div>TCP fallback</div>
<div>Maintain connectivity in harsh environments</div>
<div>❌ WebRTC only</div>

Key point:

The VS1984 anonymous core network does not use STUN/ICE/TURN; these are used solely by WebRTC for media.

Even if WebRTC fails to establish media, anonymous communication still works (only voice fails).

9.4 Media Security in WebRTC

WebRTC media data is protected by:

✔ DTLS

✔ SRTP

✔ Strong encryption

✔ Content invisible to ISPs

✔ No third-party server required for encryption

✔ Media cannot be decrypted mid-flight

Media-layer security is strong and independent from TLS.

9.5 How Is Voice Anonymity Preserved?

The media channel is ultimately P2P, but anonymity is still maintained because:

✔ The other party is identified by a Guard ID, not a Real ID

✔ Signaling goes through the anonymous network, not direct IP

✔ Media streams may expose public IPs (by nature of P2P)

✔ Exposed IPs can only be linked to Guard IDs

✔ Guard IDs can be rotated at will (switch nodes + new stego images)

✔ Media layer encryption is unbreakable

✔ Voice sessions do not tie to on-chain behavior

So the media channel does not break global anonymity.

9.6 Neighbor-Only Voice Policy

To minimize the risk of exposing public IPs, VS1984 uses:

Voice calls are only allowed between “neighbor nodes”.

Why?

The ICE process:

• STUN exposes your public IP
• ICE candidates include LAN and public addresses
• P2P media flows reveal both parties’ IPs to each other

Therefore:

❌ Calls to random distant nodes

→ Could expose your public IP to strangers

❌ Onion-relayed signaling to arbitrary endpoints

→ Would degrade anonymity significantly

Whereas with neighbors:

✔ Neighbors already see your TCP endpoint IP (you are already directly connected)

✔ They are present in your K-bucket

✔ They are verified by TLS pinning

✔ A higher level of implicit trust already exists

Here “neighbors” are P2P neighbors, not geographic neighbors.

VS1984 voice is “conditionally anonymous”: limited to nodes you trust enough to keep in your routing table.

This keeps anonymity strong yet manageable.

9.7 Commercial Value of the Voice System

VS1984 voice combines:

• Tor-like anonymous signaling
• Discord/Telegram-like UX
• Fully encrypted media streams
• Strong NAT traversal
• No server requirements

Commercial scenarios:

✔ Global anonymous voice network

✔ Encrypted lifelines in high-risk regions

✔ Private voice channels for organizations/enterprises

✔ Uncensorable real-time voice communication

✔ Core infrastructure for decentralized anonymous social platforms

📘 10. File Transfer System

VS1984’s file transfer system uses an end-to-end encryption + relay caching + pull-based link model.

This design offers:

• Full anonymity
• Minimal path exposure
• Decentralized caching
• Elastic transfer
• Content always encrypted
• No exposure of the sender’s Real ID

This is a highly anonymous, undecryptable, relay-capable file transfer protocol, fundamentally different from Signal/Telegram or BT.

10.1 File Encryption Model: Per-Pair Dynamic AES Keys

When node A wants to send a file to node B:

1. A targets B’s Guard ID
2. Uses their shared key (ECDH / inner protocol)
3. Derives a one-time AES file key for A→B

Then:

• A encrypts the file locally with AES
• A gets a fully encrypted file package
• Relays cannot decrypt
• Caching is harmless

Encryption is done only on A’s side

Decryption is done only on B’s side

Relays never see plaintext.

10.2 File Transfer Mode: Generating a File Link

After encryption, A:

1. Packages the encrypted file
2. Computes file_hash
3. Stores the ciphertext locally
4. Generates a unique link:

rsx://file_url

This link is sent anonymously to B.

10.3 Sending: Link Via Anonymous Message

A doesn’t send the file directly. Instead it sends:

• The file link
• The file metadata (still encrypted)

Using the VS1984 anonymous messaging system (multi-hop + Anycast).

Thus:

• Real ID never appears
• A’s IP is not revealed
• Relays only see encrypted metadata
• Only B learns the file size on download

10.4 Receiving: B Actively GETs the File

Once B receives the link:

1. Uses file_hash
2. Issues a GET request
3. Any caching node can respond

Flow:

B → anonymous P2P → relays C/D/E → A or cache nodes → B

The entire file transfer remains AES-encrypted.

10.5 Role of Relay Nodes: Temporary Encrypted Cache

A key highlight of VS1984:

Relay nodes automatically keep temporary encrypted copies of files.

When relay X forwards a file:

• It stores a cached ciphertext
• It does not know the content
• It does not know the file type
• It does not know who sends to whom
• Cache has a short TTL
• It can serve future GET requests

Advantages:

✔ High performance (multiple nodes can serve the file)

✔ Elastic transfer (resumable, robust to disconnections)

✔ Reduced bandwidth pressure on A

✔ Cached content is AES ciphertext → zero privacy leakage

In essence, this is:

A distributed encrypted cache.

10.6 Full File Path: Multi-Hop → Relays → Cache → Fetch → Decrypt

Full flow:

 (1) A encrypts file → generates file_hash
       |
       v
(2) A sends anonymous message to B (with file link)
       |
       v
(3) B issues GET(file_hash)
       |
       v
(4) Kad-Lite Anycast broadcast query
       |
+--++
|                  |
Cache C         Cache D         Original A
|                  |            |
+--+++
       |
(5) B receives encrypted file
       |
(6) B decrypts locally using shared key

Relays see only:

• file_hash
• AES ciphertext

They do not know:

• Who sent the file
• Who will receive it

10.7 Anonymity Analysis

✔ Relays cannot decrypt

AES key is shared only between A and B.

✔ Relays cannot know who sent the file

Caches might serve it; origin is obscured.

✔ Relays cannot know the final receiver

GET requests are anonymous.

✔ Links contain no identity info

Only file_hash.

✔ Real IDs are fully separated

On-chain identities are never part of the transfer.

✔ B’s requests reveal no source

Still multi-hop and anonymous.

This is a highly mature anonymous file transfer system.

10.8 Commercial Value

The anonymous file system provides:

• BT-like functionality → but E2E encrypted, no visible swarm
• IPFS-like content addressing → but content is never exposed
• OnionShare-like security → but without servers
• S3-like usage → but fully decentralized
• Darknet-like opacity → but with better performance

Ideal for:

• Anonymous group sharing
• Sensitive file transfer
• Private file distribution
• Encrypted paid-content ecosystems
• Building IPFS-scale distributed content networks

📘 11. Blockchain System

VS1984’s blockchain is a multi-tier content ledger system, used for:

• Recording content hashes (main chain)
• Storing large content (subchains)
• Performing internal token accounting
• Ensuring anonymous content verifiability
• Enabling on-chain paid content (e.g., BT content charging)

This chapter explains:

• Why the main-chain + subchain structure
• How it reduces blockchain bloat
• How restricted PoW improves security
• How the content charging mechanism works

11.1 Overall Blockchain Structure

VS1984 adopts:

Main Chain + Subchains + Multi-Logic Chain Topology

Structure:

Blockchain Structure
        ┌──────────────────────────┐
        │        Main Chain        │
        │  - multi logic           │
        │    content hash          │
        └──────────────┬───────────┘
                       │
          ┌────────────┼─────────┐
          │                      │
┌─────────▼────────┐    ┌────────▼─────┐
│   Subchain A     │    │  Subchain B  │
│  - post content  │    └──────────────┘
│  - trade record  │
│  - cert pin      │
└──────────────────┘

Design idea:

• Main chain as “content registry” (only storing multi-logic content hashes)
• Subchains as “content warehouses” (storing actual content, cert pins, token records)

This prevents main-chain bloat while preserving content integrity.

11.2 Main Chain: Content Hashes & Security

The main chain stores:

✔ Content hashes

(no actual content)

✔ Logical pointers to subchains (subchain_ref)

Its core goal:

Validate content existence, not store the content itself.

11.3 Subchains: Storing Actual Content

Actual content is stored in:

Subchains

Advantages:

✔ Avoid main-chain bloat

Main-chain size remains stable.

✔ Per-byte content fees

Large content pays more.

✔ Unlimited capacity via horizontal scaling

Subchains can be added as needed.

✔ Per-purpose subchains (BT, posts, comments, supplemental data, etc.)

✔ Stronger anonymity

Real IDs are decoupled from network behavior.

11.4 Working Model Between Main Chain & Subchains

Flow:

1. User publishes content
2. System generates content_hash
3. Writes content_hash to the main chain
4. Writes actual content to a subchain
5. Main chain records subchain_ref
6. Main chain is used to verify content
7. Nodes are free to sync desired subchains

Dual guarantees:

✔ Main chain ensures authenticity

✔ Subchains ensure availability

11.5 Restricted Proof of Work (PoW)

VS1984 uses a lightweight Restricted PoW:

Goals:

• Very low energy consumption
• Not a hashpower arms race
• Prevent parallel brute forcing
• Allow fair participation
• Keep block production stable

Rules:

✔ Nodes can submit nonces only at fixed intervals

✔ Difficulty is tied to resource constraints, not raw compute

✔ Parallel submissions are rejected

✔ Randomness prevents mining monopolies

Essentially:

VS1984 is “participation-first”, not “hashpower-first”.

11.6 Post-Quantum Crypto Support (Multi-Crypto Ready)

The chain supports:

• ECDSA
• Ed25519
• Future: Dilithium (PQC)
• Kyber (key exchange)

11.7 Content Charging: Paid BT Content

VS1984 implements:

A serverless, offline-tolerant payment system

Based on:

• On-chain payment records
• Content authors encrypt content keys with buyer public keys
• Key ciphertexts broadcast on-chain
• Only buyers can decrypt

This forms an on-chain content key distribution system.

11.7.1 Full Flow

Step 1: Buyer Initiates Purchase

tx = {
    buyer_realid,
    seller_realid,
    price,
    content_identifier
}

Main chain confirms.

Step 2: Publisher Encrypts Content Key

encrypted_key = Encrypt(content_key, buyer_real_pubkey)

Step 3: Publisher Writes Encrypted Key to Chain

tx_key = {
    buyer_realid,
    content_identifier,
    encrypted_key
}

This is visible to all, but only the buyer can decrypt.

Step 4: Buyer Reads From Chain and Decrypts

content_key = Decrypt(encrypted_key, buyer_private_key)

Step 5: Buyer Uses content_key to Decrypt Content

No relay, no point-to-point messaging needed.

11.7.2 Advantages of On-Chain Key Propagation

✔ No need for both parties to be online

✔ Keys are never “lost” (the chain persists)

✔ No interception

✔ Only the buyer can decrypt

✔ Automatic broadcasting (no servers)

✔ Fully decentralized

11.7.3 Anonymity in the Charging System

✔ Publisher is anonymous (Real ID ≠ Guard ID)

✔ Buyer is anonymous

✔ Content is unseen (hash only)

✔ Content keys are ciphertext only

✔ No message round-trips (no timing attack surface)

11.7.4 Overall Value of the Charging System

This is:

A decentralized paid-content + encrypted access-control + censorship-resistant economic system

Applicable to:

• Anonymous publishing
• Private communities
• Self-published content
• Paid BT content
• Decentralized knowledge markets
• Serialized works
• Paid file sharing

Realizing:

An anonymous, paid, serverless, secure ecosystem.

11.8 Content Moderation & Anti-Censorship

Because:

• No servers
• Immutable blockchain
• Content hashes never removed
• Subchain data is distributed
• File transfer is encrypted
• Real IDs never route traffic
• Guard IDs can be rotated repeatedly

VS1984 provides:

✔ Strong anti-censorship

✔ High fault tolerance

✔ No way to ban a specific user

✔ No way to delete content

✔ No way to stop content from spreading

This is a truly anonymous and free network.

📘 12. Anonymity Analysis

VS1984 is designed specifically for strong anonymity, high anti-censorship, and serverless operation as a communication and content distribution system. This chapter evaluates its behavior under typical anonymity threat models:

• Network-layer attacks
• Traffic analysis
• Parameter correlation
• Route fingerprinting
• On-chain identity correlation
• Key replay / split attacks
• Metadata analysis
• Sybil attacks
• Global passive adversaries

and how VS1984’s design mitigates these threats.

12.1 Five Core Anonymity Principles

VS1984’s anonymity relies on five core strategies:

1. Complete Separation of Guard ID & Real ID

• Guard ID handles routing
• Real ID handles on-chain transactions/content
• They never appear in the same context

2. No-ACK + Multi-Path Delivery (Direction Hiding)

• Messages only travel forward
• No return paths
• Communication direction cannot be inferred

3. Onion Encryption + Multi-Hop (Path Irreversibility)

4. Temporary Encrypted File Caches (Source Obfuscation)

5. Decentralized Public-Key Key Distribution (On-Chain Key Broadcast)

Avoids path exposure from point-to-point key sending.

The overall goal:

“No node can know message origin, destination, content, or real identity.”

12.2 Threat Models & Defenses

We now inspect major threat models one by one.

12.2.1 Network-Layer Attacks

Examples:

• IP exposure
• TCP fingerprinting
• NAT behavioral patterns

Defense:

• All nodes use TLS 1.3 with Guard IDs + pins
• Guard IDs can be rotated
• TCP visibility limited to neighbors
• Non-neighbors communicate only via multi-hop

Result:

• Non-neighbors never see your IP
• Neighbors see your IP by your own choice (direct connections)
• No link between on-chain identity and messaging behavior

12.2.2 Traffic Correlation / Timing Attacks

Attackers monitor network activity to correlate endpoints.

Defense:

✔ No ACK

No return flows that form “round-trip” patterns.

✔ Multi-path Anycast

Attackers cannot know which path carries the real data.

✔ Onion multi-hop

Harder to infer direction per hop.

✔ Temporary caching

Source is further obfuscated by cache nodes.

✔ Randomization & asynchrony

Paths are not synchronized in timing.

Result: Effective traffic correlation becomes very hard.

12.2.3 On-Chain Correlation Attacks

Attackers attempt to infer a Real ID’s network behavior via main/subchain data.

Defense:

✔ Real ID never appears at the network layer

• No involvement in handshakes
• No involvement in messaging
• No involvement in file transfer
• No involvement in voice signaling

✔ Main chain carries no Guard ID info

On-chain data is decoupled from network paths.

✔ Keys are encrypted with buyers’ public keys

On-chain broadcast keys are useless to others.

Result: Node communication behavior cannot be derived from on-chain data.

12.2.4 Sybil Attacks

Attackers create many nodes to monitor or control the network.

Defense:

• K-buckets restrict nodes per XOR segment
• Guard IDs require certificate pins + on-chain registration
• XOR space is naturally unfriendly to concentrated clusters
• No central server to “take over”
• Each node can only be upstream/downstream for a limited set of neighbors

Result:

• Attackers cannot become “neighbors of the whole network”
• Cannot intercept all anonymous traffic
• Cannot establish global monitoring

12.2.5 Relay Node Attacks

Relays try to infer origin/destination by observing forwarded traffic.

Defense:

✔ Onion encryption

Relays see only a single layer per hop.

✔ Deduplication

Redundant packets are dropped, reducing inference.

✔ No ACK

No reverse-direction confirmation traffic.

✔ Multi-path

True path is hidden among many.

✔ Encrypted file caches

Relays store only ciphertext, with no semantics.

Result:

Relays cannot know:

• Who sent the file
• Who will receive it
• What the file contains
• Where the file originated
• Which path is the “real” one

12.2.6 Global Passive Adversary

Assume an attacker can:

• Monitor the global network
• Capture all TCP packets
• Control many relays
• Analyze all blockchain data

Defense:

✔ Decoupled on-chain and network behavior

No single correlation point.

✔ No ACKs

No round-trip patterns.

✔ Unpredictable multi-path

Each path may be noise.

✔ Pull-based file transfer

Requests from B to caches obfuscate A’s identity.

✔ Voice limited to neighbors

IP exposure constrained to a small, explicit set.

✔ Guard IDs are rotatable

No stable identity for long-term profiling.

Result:

Even a global adversary cannot reliably identify message sources and destinations, cannot reconstruct paths, and sees only encrypted flows.

12.3 Summary of Anti-De-Anonymization Mechanisms

VS1984’s defenses against de-anonymization:

<div>Traffic correlation</div>
<div>✔ Strong</div>
<div>Multi-path + no ACK</div>

<div>Global passive observer</div>
<div>✔ Strong</div>
<div>Multi-hop + no return flows</div>

<div>Relay analysis</div>
<div>✔ Strong</div>
<div>Onion encryption + encrypted cache</div>

<div>On-chain correlation</div>
<div>✔ Strong</div>
<div>Full Guard / Real separation</div>

<div>Sybil attacks</div>
<div>✔ Mitigated</div>
<div>Proof of work + once per node</div>

<div>Timing attacks</div>
<div>✔ Mitigated</div>
<div>Randomized paths + no ACK</div>

<div>Key leakage</div>
<div>✔ Mitigated</div>
<div>On-chain public-key-encrypted key broadcast</div>

<div>IP exposure</div>
<div>✔ Partially mitigated</div>
<div>Only neighbors see IPs; non-neighbors use multi-hop</div>

VS1984 is:

A system that hides paths, not just IPs,

similar to an enhanced mixnet / Tor.

12.4 Anonymity Level vs Tor / Cwtch / Session

<div>Tor</div>
<div>High</div>
<div>Single-path; may be analyzed by large-scale censors</div>

<div>Cwtch</div>
<div>Top-tier</div>
<div>No ACK, multi-path anonymous delivery</div>

<div>Session</div>
<div>Medium-high</div>
<div>Mostly anonymous but relies on server infrastructure</div>

<div><strong>VS1984</strong></div>
<div><strong>Top-tier (Cwtch level)</strong></div>
<div><strong>No ACK, multi-path routing, encrypted caching subsystem</strong></div>

VS1984’s anonymity stands at:

The highest tier among global anonymous communication systems,

especially thanks to:

• Encrypted relay cache for file transfer
• On-chain content key broadcast
• Guard / Real dual-identity separation
• No ACK
• Anycast multi-path anonymous routing
• Neighbor-only voice policy

📘 13. System Security

VS1984’s security model is based on Defense in Depth, across:

• Key and identity management
• Encryption stacks
• Routing-layer security
• File transfer model
• Content charging and key distribution
• Blockchain security
• NAT traversal (WebRTC subsystem)
• Client security
• Anti-censorship
• Anti-traffic-analysis and global monitoring

Together they form a fully serverless security architecture.

This chapter outlines the threat model, attack surface, and corresponding defenses.

13.1 Security Architecture Overview

VS1984’s security stack has three core layers:

(1) Key & Identity Layer

• Guard ID (network identity)
• Real ID (on-chain identity)
• TLS certificates (bound to Guard IDs)
• On-chain public key system (bound to Real IDs)
• Key rotation and dynamic key generation
• Content key encryption and on-chain key broadcast

Features:

✔ Guard ≠ Real

Strict separation of identities.

✔ Pinning cannot be bypassed

Pins are on-chain and immutable.

(2) Network Security Layer

Includes:

• TLS 1.3 (FS)
• Custom inner protocol (second-layer encryption)
• Onion encryption (multi-hop)
• No-ACK anonymous routing
• Undecryptable relays
• Multi-path delivery
• Dedup & TTL

Features:

✔ No return paths (no ACK)

Communication direction is hidden.

✔ Onion multi-hop

Relays see neither full paths nor content.

✔ Multi-path

No single “true path”.

✔ Encrypted caches

Origins and destinations are hard to infer.

(3) Blockchain Security Layer

Includes:

• Main chain
• Subchains
• Restricted PoW
• Content key broadcast
• Token accounting
• Certificate pins on-chain
• Encrypted content hashes

Features:

✔ Content keys via on-chain broadcast

Cannot be intercepted or lost.

✔ Keys encrypted with buyers’ public keys

Only buyers can decrypt.

✔ Main chain stores hashes only

Content integrity but no plaintext.

✔ Restricted PoW

Resists hashpower-based attacks.

13.2 Attack Surface Analysis

We now enumerate potential attack types and defenses.

13.2.1 MITM / TLS Hijacking

Attackers attempt:

• Man-in-the-middle
• TLS cert replacement
• Pin hijacking

Defense:

✔ Guard IDs ↔ TLS pins bound on-chain

Any forged cert is rejected immediately:

• Pin mismatch → connection refused
• External CAs have no influence
• TLS certificate forgery is rendered impossible

Result:

Unless an attacker can break SHA256 or rewrite the blockchain, they cannot forge node identity.

13.2.2 Private Key Compromise

Attackers may:

• Steal private keys
• Replace content keys
• Perform MITM on content key flows

Defense:

• Local encrypted key storage
• Guard and Real keys are separated
• Content keys are one-time use
• File transfer keys derived dynamically via ECDH

Result:

Guard key compromise ≠ on-chain identity exposure Real key compromise ≠ messaging behavior exposure

13.2.3 Routing-Layer Attacks

Attackers may:

• Replay messages
• Perform fingerprinting
• Infer paths

Defense:

• msg_id deduplication
• No ACK → no returns
• Multi-path → no obvious main path
• Onion encryption → non-reversible
• TTL → controlled propagation
• Encrypted caches → obfuscated origins

Result:

Paths cannot be reverse-engineered from packets.

13.2.4 File Transfer Attacks (Tampering / Decryption)

Attackers may:

• Tamper with files
• Relay forged files
• Infer sender identity

Defense:

✔ AES keys are A→B-specific

Derived from Guard ID–based shared secrets.

✔ Relays only cache ciphertext

Cannot encrypt or decrypt.

✔ file_hash ensures integrity

Relays cannot forge valid content.

Result:

Relays cannot forge or decrypt files.

13.2.5 Content Charging Attacks (Key Theft / Substitution)

Attackers may:

• Capture content keys
• Replace keys
• Forge key receipts

Defense:

✔ Content keys are encrypted with buyer’s public key

Only buyers can decrypt.

✔ Keys are on-chain, not point-to-point

Cannot be intercepted or dropped.

✔ Hash & signature verification

Ensures keys correspond to specific content.

Result:

Keys cannot be stolen, replaced, or forged, and paid content cannot be decrypted by unauthorized parties.

13.2.6 Blockchain Attacks (51% / Parallel Mining)

Attackers may:

• Use hashpower to rewrite history
• Rebuild blocks
• Conduct 51% attacks

Defense:

✔ Restricted PoW (not hashpower-driven)

No GPU/ASIC advantage.

✔ Non-parallel mining model

Each node can only submit one nonce at a time.

✔ Multi-logic chain

Hard to dominate all chains simultaneously.

Result:

Chain rewriting via raw hashpower is not feasible.

13.2.7 Voice System Attacks (WebRTC IP Exposure)

Attackers may:

• Use WebRTC to reveal IPs
• Build network fingerprints via ICE
• Analyze media metadata

Defense:

✔ Voice allowed only between neighbors

IP exposure radius is minimized.

✔ Signaling via anonymous network

No IP/geo leakage in signaling.

✔ SRTP-encrypted media

Content is protected.

Result:

WebRTC does not significantly weaken system anonymity when constrained to neighbors.

13.3 Key Security Strengths

VS1984’s security stack provides:

✔ Serverless → no single chokepoint

Shutting down servers cannot kill the system.

✔ Dual identities → no direct linkage

Guard ≠ Real.

✔ Multi-path → non-directional flows

Paths are not obvious.

✔ No ACK → no round-trip signatures

✔ On-chain key broadcast → no interception

✔ Temporary encrypted caches → obfuscated file sources

✔ Hash-only main chain → strong content privacy

✔ TLS pins on-chain → no forged nodes

✔ Restricted PoW → resilient to hashpower attacks

In summary:

VS1984 = hidden paths + hidden identities + hidden links + hidden correlations

A model beyond simple “IP hiding”.

📘 14. System Feature Summary

VS1984 is a truly serverless, uncensorable, strongly anonymous, and scalable distributed content network.

It unifies:

• P2P networking
• Distributed ledgers
• Anonymous communication
• Encrypted content distribution
• Built-in content charging

into a single system.

Core features fall into four categories:

• Anonymous communication system
• Decentralized content network
• Encrypted file transfer & caching system
• Built-in content charging economy

Below is the final summary.

14.1 Core Highlights

✔ 1. Dual-Identity Model (Guard ID / Real ID) — World-Leading Anonymity Design

• Guard ID = network-layer identity (replaceable)
• Real ID = on-chain identity (publishing/payments)
• They never appear in the same context
• Network behavior cannot be linked to on-chain identity

Thus:

Anonymity = routing anonymity + identity anonymity + on-chain anonymity combined.

Very few systems achieve this level of separation.

✔ 2. TLS Pinning On-Chain — Resistance to CA-Level MITM

VS1984 completely bypasses classical CA trust issues:

• Guard IDs’ certificate pins are written to the blockchain
• Handshakes must verify these pins
• Mismatches are rejected immediately
• Even governments controlling CA roots cannot forge node identities

This is a root-level correction of the traditional TLS trust model.

✔ 3. Multi-Path Anonymous Messaging (No-ACK Anycast Onion Routing)

• No ACKs (no source←→dest correlation)
• Multi-path delivery
• Onion encryption
• XOR-closest 5-node Anycast
• TTL + dedup
• Relays cannot infer direction

Anonymity is at Cwtch level, among the strongest currently available.

✔ 4. Encrypted File Transfer + Relay Caching (Works Even if Source Is Offline)

Model:

• AES A→B shared keys
• Relays only caching ciphertext
• B issues GET requests; any cache can respond
• A can go offline after upload
• Relays cannot decrypt or attribute

This is:

A serverless encrypted CDN-like system,

more secure than IPFS and more anonymous than BT.

✔ 5. On-Chain Content Key Distribution (Non-Interactive Decryption)

Content keys for paid content are not sent via direct messages, but:

• Publishers encrypt content_key with buyers’ public keys
• Encrypted keys are written to the blockchain
• The chain handles broadcasting
• Visible to all, decryptable only by the buyer

Thus:

• Keys are never lost
• Cannot be intercepted
• No need for real-time interaction
• No servers or relays required

This is a rare example of a non-interactive paid-content system.

✔ 6. Main Chain + Subchains for Content Accounting

• Content hashes on the main chain
• Full content on subchains
• Fees proportional to content size

Benefits:

• Main chain stays slim
• Subchains scale horizontally
• Charging is naturally size-dependent

A ledger structure purpose-built for a decentralized content network.

✔ 7. Restricted PoW (Anti-Mining-Cartel)

• No hashpower races
• GPU/ASIC not rewarded
• Per-node block production rate limited
• Parallel attacks are rejected
• Encourages broad participation

VS1984 is a participation-driven chain, not a miner-driven one.

✔ 8. Steganographic Login (No Accounts, No Phone Numbers, No Email)

• No account registration
• Real ID generated automatically on first launch
• Guard routing info encoded into stego images
• Images can be spread via WhatsApp/WeChat/email
• No phone number, email, or social account needed

Truly:

No signup, no phone, no social account, fully anonymous.

✔ 9. WebRTC Voice, Restricted to Neighbors

• Signaling over VS1984 anonymous network
• Media channels via WebRTC (UDP / TCP / TURN)
• Only neighbors learn each other’s IPs, not random nodes
• IP exposure becomes explicit and limited

This is a best-practice design for voice in anonymous systems.

14.2 Technical Innovations

VS1984’s innovations include:

① Routing: Anycast + Onion + No-ACK Anonymous Model

• More flexible than Tor (multi-path)
• Lighter than I2P (for instant messaging)
• More deployable than classic mixnets for real-world products

② On-Chain Content Key Broadcast (Non-Interactive Decryption)

• No need for live handshakes
• No requirement for both sides to be online
• Completes the loop of payment + key distribution fully on-chain

A very hard piece of the secure paid-content puzzle.

③ Encrypted Relay Caching

• Effectively a serverless encrypted CDN
• Relays know nothing about content
• Can still provide bandwidth and storage
• Resistant to censorship, disconnections, and heavy blocking

④ Dual-Identity Split Between Routing & On-Chain Behavior

• Network layer never sees Real IDs
• Blockchain never sees Guard IDs
• Compromise on either side is insufficient for de-anonymization

Many systems (Session, Nostr, etc.) have not achieved such strict separation.

⑤ Main Chain + Subchain Content Ledger

• Main chain logs hashes and payment logic
• Subchains store large-scale content
• Supports domain-specific chains (BT, posts, comments, attachments, etc.)

⑥ Steganographic Routing Sharing

• Routing data inside an image
• No need for account or URL sharing
• Naturally suited for highly censored environments

⑦ Restricted PoW

• Retains PoW’s security properties
• Avoids hashpower arms race
• Keeps block production more democratic

14.3 Future Roadmap (2026–2027)

Suitable as a public roadmap on the whitepaper or website.

2026 Q1–Q2

• macOS client (internal & community builds)
• Web dashboard
• Stablecoin vaults
• External chain bridges
• Token ↔ stablecoin swaps

2026 Q3–Q4

• On-chain governance (voting/proposals)
• Distributed content marketplace (Market v1)
• Full BT integration (anonymous tracker + encrypted torrents)
• iOS client
• Android client

2027

• Windows client
• Full anonymous community ecosystem (Groups, Channels, Feeds)

14.4 Conclusion

VS1984 is not:

• A simple chat tool
• A basic blockchain wallet
• Or a centralized “encrypted social app”

Its goal is to build:

A truly free, uncensorable, and completely non-centralized human information exchange network.

It enables:

• Content to exist freely
• Users to remain fully anonymous
• Knowledge to spread safely
• Payments to flow directly
• Information to cross censorship and firewalls

VS1984 represents a new path:

An encrypted internet that does not rely on servers.