Decentralized File Hosting on Lightning

Sats4Files.md

Sats4Files [Simplified]

The client wants to buy from the server the file corresponding to a particular file_id. The following is a very basic scheme solving the problem in a naive way.

• The file gets chunked into 32-byte chunks. They are hashed into a Merkle root, which is the file_id.
• The client buys from the server one Merkle branch after another via Lightning payments. The payment's preimage is the Merkle leaf.

Limitations and Optimizations

• Sending 32 MB requires 1 million Lightning transactions. That means equally many signatures.
• All hops have to store all preimages. Lighting upgrades using sighash_anyprevout like Eltoo or Daric can reduce the storage complexity from O(n) to O(1). On today's Bitcoin, Decker-Wattenhofer payment channels would allow to reduce the storage complexity by resetting it periodically (but only a limited number of times).
• In Lighting, a preimage can be used only once safely. So a server can send a file only once. This can be solved by using PTLCs and reblinding instead of HTLCs. So the leaves of the file_id become curve points instead of hashes. Here's the advantage that the intermediate hops learn nothing about the file.

See also this solution and this optimized solution.

PayPub —> ZKCP —> ZKCSP —> Sats4Files⛈️ Simplified.

I do wonder what services the “s” in ZKCSP can provide beyond trading coins for files. Maybe some useful applications to explore later on.