Ghost Room@GhostRoomSol
Which noise handshake patterns, how are the keys rotated, how is the replay protection implemented?
Uses Noise XX pattern (Noise XX 25519, ChaChaPoly,SHA256) with 3-message handshake keys rotate after 1 hour or 10,000 messages via full rekey handshake replay protection uses a 1024-nonce sliding window that rejects duplicates and old packets outside the window.
Why are you wrapping AES over a primitive that is already encrypted? How are the nonces for AES derived?
AES-256-GCM will be only for password-protected group channels, not over Noise transport it enables shared channel encryption where multiple peers use the same password-derived key AES nonces (IVs) are randomly generated for each message.
The servers have to see the IP, timestamps, and routing info while in transit. Telling people "we don't upload metadata" is completely false in how networking works. Please clarify what you meant?
"No data trails" means no persistent storage of metadata servers don't log contact lists, message content, or wallet balances transit metadata (IP, timestamps, routing headers) exists during packet forwarding but isn't stored or correlated after delivery, similar to how Tor relays forward packets without keeping logs.
Why are you talking about UTXO when this is a Solana based project? Solana is account based not UTXO. Please clarify.
We used the BTC example simply to demonstrate the doability of offline payments, because Bitcoin’s UTXO model is the easiest way to show raw transaction signing and offline settlement. That was just an example, not a limitation. GRoom will be a cross chain system. We are starting with the BTC flow for the demo, but we are also integrating Solana and EVM chains, both of which use account based models instead of UTXO. Each chain will follow its own transaction structure, and our offline engine will support all of them. So mentioning UTXO was only for the BTC example, while Solana and other chains will use their native transaction formats within the same offline payment framework.
For the Bluetooth stuff, what's the TTL, DoS resistance, MiTM resistance, lossy resistance implementations?
TTL is 7 hops for messages, 0 for neighbor-only sync, MiTM resistance comes from Noise XX handshake with static key authentication, lossy resistance uses fragmentation (512-byte threshold) with 30s reassembly timeout, DoS resistance includes seen-message deduplication (10k capacity) and connection limits (8 max normal, 2 ultra-low power), but no explicit rate limiting on packet processing.
BTW we donated $100 worth of our tokens for doing awesome work for the space. It’s not much but as a small project and small dev team. It means a lot to us for getting such attention.
