RansomShield

Inspiration

Ransomware attacks cost businesses $20 billion a year. The attackers demand Bitcoin to return your files. We thought — what if we flipped that? Instead of paying attackers, you pay a decentralized storage network a fraction of a penny via Lightning to recover your data. Bitcoin stops being the ransom currency and becomes the recovery currency.

What it does

RansomShield encrypts your files with AES-256-GCM, shatters the encrypted data into 5 erasure-coded shards using Reed-Solomon (any 3 of 5 reconstruct the full data), and distributes them across independent storage nodes. The encryption key is split via Shamir's Secret Sharing (any 3 of 5 shares reconstruct the key). Recovery is gated by Lightning micropayments using Lightning Labs' L402 protocol. The backup's integrity is anchored to Bitcoin's timechain via a Merkle root in an OP_RETURN transaction. Storage nodes must pass proof-of-custody challenges to prove they still hold your data.

How we built it

Three cryptographic layers — each solving a different problem:

• AES-256-GCM for bulk encryption (confidentiality)
• Reed-Solomon 3-of-5 for data availability (survives node failures)
• Shamir's Secret Sharing 3-of-5 for key recovery (no single point of failure)

Shamir is used ONLY for the 32-byte key, not the bulk data — each Shamir share equals the secret size, so splitting a 1GB file would mean 5GB of shares. Reed-Solomon achieves the same fault tolerance at 1.67x overhead.

Bitcoin integration is structural, not cosmetic:

• OP_RETURN Merkle anchoring — every backup snapshot is committed to Bitcoin, proving it existed at a specific block height
• L402 (Lightning Labs' HTTP payment protocol) — storage nodes require a Lightning micropayment before serving shards during recovery
• Proof-of-custody — spot-check challenges verified against the Bitcoin-anchored manifest

Built with Node.js, Express, the @subspace/reed-solomon-erasure.wasm WASM library, shamir-secret-sharing, and LNbits for Lightning integration on a Polar regtest network. Dashboard is plain HTML/CSS/JS with Server-Sent Events for real-time visualization.

Challenges we ran into

• The Reed-Solomon WASM library uses a single contiguous Uint8Array internally, not an array of separate shard buffers — required writing a conversion layer
• shamir-secret-sharing uses positional parameters and requires plain Uint8Array, not Node.js Buffer — discovered through runtime errors, not documented
• Building the OP_RETURN transaction via Bitcoin Core RPC required handling wallet creation, UTXO selection, and block mining on regtest — more steps than expected
• Scoping the L402 macaroon verification correctly — the key insight is that SHA256(preimage) === payment_hash is sufficient proof of payment without querying LND directly

What we learned

• Shamir's Secret Sharing and erasure coding solve fundamentally different problems (secrecy vs availability) and must not be conflated — this is formalized as Krawczyk's "Secret Sharing Made Short" (1993) and used by Storj, Filecoin, and Tahoe-LAFS in production
• L402 is an elegant protocol — combining Lightning invoices with macaroon bearer credentials makes pay-per-request APIs trivial to implement
• Bitcoin's value in this system isn't as a payment rail — it's as a trust anchor. The OP_RETURN Merkle root transforms a backup from "trust us, it's fine" to "mathematically verify it against the timechain"

What's next

• Discreet Log Contracts (DLCs) for trustless escrow — removing the custodial element from storage payments
• TLSNotary integration for verifiable proof that storage nodes fetched and stored the correct data
• Geographic distribution requirements — enforcing that shards are spread across different regions
• Automatic shard repair when nodes go offline

Built With

• lightning
• node.js