Sketch of a protocol I discussed with nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s for proving storage of a file.

before uploading, select 32 random bytes from the file, store their indices and the sha256 hash. do this 1000 more times (select 32 different random byes, calc sha256).

upload the file to the server. every day, ask for the hash of the 32 bytes at the indices stored from the server. if it matches transfer some sats. if not the server no longer has the file. you can check for 1000 days.

Reply to this note

Please Login to reply.

Discussion

Why compute a hash? Just ask for the bytes?

You could use different permutations of the bits by index without exposing individual ones

What's the meaning of "exposing"? Is there some secret to be kept here?

I don't think you have a clear problem statement here.

Any constructive feedback?

Much fewer than 32 bytes will do, too. If the server doesn't have the file but wants to pretend it does, it could report random numbers. Those would be correct for a chance of 1 in 256 for 1 byte or 1 in ~4bn for 4 bytes I think that's safe enough.

Chances would be greater for real world data. It's not perfectly random. Server could record the most common byte sequences and report those.

Correct but then again I'm assuming the file is on the server for archival storage to begin with so it's probably compressed in one way or the other which does a pretty good job at removing the common sequences and making it pretty close to random.

That's why I buy your books and you don't buy mine.

The peasantry is impressed.

Correction: Pleb

This sounds brilliant.

I'm assuming you'd have the ability to just download said file, otherwise why do you care if it's stored or not?

Love seeing you guys chatting. Good things can happen with this! 💜

Is this done on blossom today nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr ?

no, however it wouldn't be very hard to add it to the blossom protocol

Proof of file?

Proof of storage, probably could work well for torrenting as a well to ensure that the service is storing and torrenting your data

I had the same idea but trusting is easier

I def need this for my project. Jimmy you've known about it

So if the checksum does not match we know to stop paying. But at that point we have data loss.

If this file is of any importance it need to be stored in multiple places. If it is not important at all, why pay to store it...

If it is stored in multiple independent places we should be able to check the copies against each other.

No need for this subset selection.

Also, if my math maths, 32 bytes is the exact same size of the sha256 hash. Why do the hash?