See my public key blockchain patent for background: us patents 9,973,341 and 10,187,214
A traditional block has a purpose built container for the data structure for the block. Containing a previous block reference, bookkeeping data, the payload, and a nonce.
Any data container can be a blockchain block. In this instance I will describe how to use a PNG image as a block container.
First note that PNG containers have an optional data field that can contain image meta-data. These are the “Textual Information Chunks.” You can use either the comment field or create a new field. It may even be worth the effort of registering a well-known chuck name for this.
So the previous block reference would be a hash of the previous image in the chain. Having a canonical ordering of chunks in the container is helpful but not required. It could also be other ways to name an image: s3 bucket, URL, time from the start of a stream. Any data that is either universal or reactive to agreed upon basis. (for example, it could be a SHA hash slated by a secret salt that only creators and verifiers know).
Any other meta-data about the chain can also be kept in this bookkeeping data field.
Particular streams may want specific configurations of how frequently and from where the blocks can come from (difficulty). So if the PNG comes from a webcam feed at 60fps and we want an image on average every 10 minutes then the difficulty would be set at some value that results in only 1 of every 3600 images being accepted.
Note that all bookkeeping data becomes “frozen” in the chain once part of a picture. This has standard blockchain implications like you can only adjust future accepted difficulty values not the difficulty for the current block.
Other bookkeeping data may be orthogonal concerns like ownership, which stream made the block, “uncle” blocks, etc.
The nonce is a curious beast. Traditionally it is just a number. But with abstract containers there are more frontiers for the nonce.
The payload may be the nonce. If trying to collect rapidly changing ephemeral data then the block is one instance of that ephemeral data.
Other meta-data may be the nonce. Some fields in the container may have loose interpretations and can be loaded with otherwise valid and relevant data. For example: whitespace in a non-canonical XML container.
Data containers also may have flexible ordering of elements. Some have canonical and non-canonical forms, and some just don’t care. Where the data elements can be re-ordered this provides another way to “nonce” the data.
Some cryptographic signing also has signing provided portions to the signature (r values in ECC for example). Those can be used to nonce containers. (This was also mentioned in the patent backgrounds).
Some processing on the "same" payload can also serve as nonceing. JPEG images, for example, could have the compression pramaters tweaed to achieve the needed PoW hash. This is generally true for all lossy containers.
The key insight in this construction is that the container is the payload rather than the payload being part of the container. Rather than having a segregated area for the payload in the block the container is the payload data with a specified area for the previous block reference, bookkeeping data, and nonce.
Which is to say that the container is useful to applications who have no knowledge of the blockchain metadata contained within some of the fields the app would normally ignore. In essence the blockchain metadata is very loosely segonagraphic. Apps that are not aware of the data will ignore it. Rather than encoding in low order bits the data is stored in fairly simple to detect areas that are typically ignored in standard presentations.
That’s not to say that full on steganography couldn’t be used. The relevant data could still be encoded as a byte stream in the low order bits of a lossless image. That would be a “Boss Level” application of this technique.
One concrete implementation of this would be Image Chains. A video stream would be passed through an encoder that would add the blockchain metadata. Standard proof of work checks would be applied so that a sampling of the image in the video stream would produce the “blocks” rather than every image in the chain.
Streams could be done with a single source or multiple sources.
For a single camera stream it has the advantage of a fixed difficulty. In one formulation the difficulty could be fixed for the entire stream. In another formulation the difficulty could target a number of images per hour (6-60) and the difficulty would adjust up or down as a function of remaining time in the stream and number of blocks already found. I.e. if the stream has provided fewer images at the current time than the desired rate the difficulty could go down, and if there are too many images it would go up. There may be some desire for a range (4-8 per hour) before the difficulty goes up or down and in the middle the difficulty is fixed at the middle rate.
For multiple streams, for example having audience members all film a band separately, the difficulty would need to float much like a traditional proof of work blockchain. The difficulty is that the number of available sources can go through dramatic swings on the low end of participation to the high end. Implementations could use a fixed permissionless peer to peer sourcing algorithm or the participants' cameras could be treated like miners in a mining pool, where close pictures are reported to gauge the size of the pool and possibly reward the participant but the central authority controls some of the embedded metadata.
One specific place this could be used at is conferences and other events like concerts, festivals, fairs, or tournaments.
In the single camera model the main stage or main tournament feed could provide one feed. Another model is to have a roving single camera capturing random “candids” of the events, such as on the Build Floor of a hackathon.
Multi-participant cameras provide opportunities for the participants of the events to add to the stream. They could, for example, provide different shots of the speaker/performer. They could also provide candid shots for non-focused events like a fair or hackathon.
Being an image container these image chain blocks can quickly be converted into NFTs available on a number of block chains. For example an EthGlobal hackathon like EthDenver could have multiple chains that can be sold as part of the art auction. Music Festivals could NFTize the participants image and the participant can get a cut of the revenue for the NFT. More elegataring festivals may provide the NFT directly to the participant as a reward directly and let them keep or sell at their discretion.