A decentralized file hosting protocol in which clients pay per request. Client and server perform a fair exchange of coins against files, using a Lightning payment combined with a proof of encryption. This document describes a naive system which is probably too slow, however it intends to spark a discussion about which proof systems could make it practical, because that could allow to decentralize the web.
A “Sats4Files protocol” allows users to request data from servers, and upon receiving the encrypted data, they can pay for the decryption key, e.g., via Lightning. The exchange is atomic, ensuring that the user only receives the data if they pay for it, and the seller only gets paid if they deliver the data.
Servers respond to client requests with a zero-knowledge proof, which expresses
file_encryptedis encrypted with the preimage ofsha256_hash- the decrypted
filehashes tofile_id
Servers can sell files via Lightning using a proof of encryption.
- Client requests
file_id - Server sends the encrypted
file_encrypted, a proof of encryption withsha256_hash, and the corresponding Lightning invoice - Client pays that invoice to buy from the server the preimage of
sha256_hashto decryptfile_encryptedand obtainfile.
The bottleneck of this protocol is the time the server needs to prove a response.
- The server has to generate a new proof of encryption for every client for every request. Otherwise, a malicious client could bypass the payment by downloading the encrypted file and reusing an old key. Also in Lightning it's not secure to sell the same preimage twice.
- A malicious client could drain server resources by requesting many encrypted files without ever paying to decrypt them. IP limits might be sufficient to mitigate this attack. Clients could also be required to somehow "sign up" in the blockchain to mitigate sybil attacks.
- We can choose freely the encryption algorithm and the hash function computing
file_id, so we can choose them proof-friendly. - Proving a SHA256 preimage is expensive. Probably, it would be much cheaper to use PTLCs instead of HTLCs, because often it's cheaper to prove a discrete logarithm than a hash preimage. However, it takes probably another one or two years until PTLCs will be rolled out on Lightning.
- Assuming we had PTLCs. Then, to minimize the size of the proof's circuit, it probably makes sense to use the field of secp256k1 as base field of the proof system.
- Maybe it is possible to generate a proof of encryption once for
key_Aand then somehow "reblind" it, to become a proof of encryption withkey_B. Perhaps that is cheaper than proving it for every user from scratch. - While a server is idle it can pre-generate proofs for popular files to serve them instantly during high demand.
- Which proof system could make this system practical? E.g. proving times of less than a second?
- Can we use Bulletproofs as described here in section "Further Applications"?
See also this solution and this optimized solution.
- The first successful Zero-Knowledge Contingent Payment
- Zero-Knowledge Contingent Payments Revisited: Attacks and Payments for Services
- LSAT: Lightning Service Authentication Token
- FileBounty: Fair Data Exchange
- FairSwap: How to fairly exchange digital goods
- Verifiable encryption of discrete logarithms
Sats per branch, the new standard.