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 thefile_id
. - The client buys from the server one Merkle branch after another via Lightning payments. The payment's preimage is the Merkle leaf.
- 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.