This would allow you to store one 24x24 image with 8 colors in a transaction. Intended to be used as avatar for on-chain text messages.

This would allow you to store one 24x24 image with 8 colors in a transaction. Intended to be used as avatar for on-chain text messages.

This would allow you to store one 24x24 image with 8 colors in a transaction. Intended to be used as avatar for on-chain text messages.

OP_RETURN allows you to put 220 bytes into a BCH transaction.

This is 1760 bits (220*8).

Allow 1728 bits to represent the color of each pixel (24*24*3). The first 72 bits represent row 1 in the image, the next 72 bits is row 2 and so on.

Each pixel gets 3 bits. 3 bits fits 8 numbers (so a pixel can have one of eight colors). Number 0 means the pixel should be the first color in the header.

Allow 32 bits to represent the header (1760-1728 = 32).

The first 8 bits of the header will be a static magic number to let people know that the data is (probably) an image. This is how programs that scans the blockchain for avatar images will find them, simply check if the OP_RETURN starts with this specific byte and that the OP_RETURN length is 220 bytes.

The last 24 bits of the header is color information. Each color gets 3 bits so there can fit 8 color numbers here (24/3). Each of those 8 color numbers can be 0-7 (3 bits fits 8 numbers).

The color numbers are not the color itself, they are references to a position in a lookup table that the protocol has established. The programs showing these avatars all have these lookup tables.

Each color number refers to a unique color lookup. Color number 0 for the first color is not the same as color number 0 for the second color.

This means that avatars will be able to pick from 64 colors total (8*8). An image will always have max 8 colors however each image can have a custom palette built from the 64 colors in the lookup table.

A few colors should have varying alpha values to that avatars with fully transparent or semi-transparent backgrounds are possible. Most should be fully opaque though. Maybe something like 8 stages of black is enough (from full alpha to no alpha), that way people can at least make glowing black borders.

So OP_RETURN consists of 4 bytes header and 216 bytes of pixel data. The first byte of the header is a static magic number.

It might be possible to allow for larger images, lets say 32x32, if everything except the first byte is compressed. A different magic number could be used to let scanners know that the OP_RETURN is (probably) a compressed image.

Then it would work something like this: The user draws his 32x32 image in whatever program is used to create the avatars and then presses the "Make OP_RETURN"-button. He'd then either get a "successful"-message or an error stating that "sorry, could not compress the image below 219 bytes".

Best implementation from the very beginning would probably be if the image was always compressed. That way a 24x24 avatar might not always need to occupy all 220 bytes, which saves on the transaction cost when it is uploaded to the blockchain. It makes it a little harder for scanners though since they need to check for the magic number and then try deflating before finding out whether or not it is an image.