file protocol

[ryanxcharles]

This is a protocol for files on the blockchain. It is the simplest possible protocol I can think of.

[ryanxcharles]

Idea:

The .bitcoin file format

This is a file that consists of a concatenated list of txids. Each txid has an opreturn with another file in it. The files may be a normal file, or another .bitcoin file.

A .bitcoin file is a way of storing very large files on the blockchain. You can convert, say, a movie to a bitcoin file by breaking it up into chunks that are less than 100 KB. Each chunk gets a file. You then list those chunks in a .bitcoin file.

For very large files, like a movie, there will be too many txids to fit in a single 100 KB txid. So you make one master .bitcoin file that stores a bunch of other .bitcoin files that in turn store the actual movie data one after the other.

• top level: movie.mp4.bitcoin
• second level: movie.mp4.1.bitcoin, movie.mp4.2.bitcoin, movie.mp4.3.bitcoin, ..., movie.mp4.1000.bitcoin
• third level movie.mp4.1-1.bitcoin, movie.mp4.1-2.bitcoin, ... movie.mp4.2-1.bitcoin, movie.mp4.2-2.bitcoin, ...

The lowest level files are a series that contain 100 KB chunks of the movie in a row and can be reconstructed to form the actual movie.mp4 file.

[shadders]

Is it assumed that the reconstructed file uses the same filename with the '.bitcoin' extension stripped off? If so I think it would be helpful for the spec to state that explicity. If that's the convention it saves needing another field.

I would suggest that to cover future cases where there may be many OP_RETURN outputs that list of txids should be a list of txid:vout that is byte[32]:unit32. To stick with bitcoin convention the uint32 would be little endian encoded. Another option to save a few bytes is to use CompactInt format. In the vast majority of cases this squashes 4 bytes to 1 byte. It comes with the disadvantage of making each entry variable length but that is easy to resolve during parsing.

[shadders]

closed as there are more developed forms of this spec: #8