Concept: The current version of the BVAC system (as of 4/19/21) represents every possible combination of binary in a file, as color in a photo. For example, the current version has the ability to represent two bits of information for every pixel (We are, as of time of writing, making a third version, which will enable four bits of information to be represented by a single pixel), the way we do this is quite simple, there are only four possible combinations for two bits of binary: 1 1, 1 0, 0 1, 0 0. So we have four colors represent each possible combination of these bits, in our case, red represents 0 1, blue represents 1 0, black represents 1 1, and white represents 0 0. We then tell the wallets of our blockchains to write to a .jpg according to an array which can be located in fractal/fractalbvac.cpp
VERSION 3 Version Three of this system will involve storing four bits of information per pixel, as some of you reading this may know, the formula for how many possible combinations for an amount of bits, X, is equal to 2^X. For example, say we want to store 1 byte (8 bits) per pixel, the equation for how many possible combinations, and by extension how many colors we’d need, is 2^8, which equals 256, so we’d need 256 colors to be able to represent 1 byte per pixel. The reason as to why this is such a challenge for us will be discussed in “Challenges”. Though it is quite difficult to represent 8 bits per pixel, 4 - 6 bits is perfectly within our limit. How we do this, is by utilizing RGBA values in place of regular RGB. By setting the absolute value of an alpha value to either 0 or 1, we then double how many colors we can use. For those who don’t know what an alpha value is, it’s the transparency of a color on a scale of 0 – 1. So, the possible combinations of defined as 2^4 = 16: 1) 0000 2) 0001 3) 0010 4) 0011 5) 0100 6) 0101 7) 0110 8) 0111 9) 1000 10) 1001 11) 1010 12) 1011 13) 1100 14) 1101 15) 1110 16) 1111 We then simply assign an RGB value to half of these with their alpha value being 0, then assign the other half with the exact same RGB values, but with an alpha value of 1.
The main challenge that we’ve been having to deal with would have to be Blueprint of the third iteration of the BVAC system. the loss of pixel information due to the compression of .jpg images. As a result, we’ve had to stick to absolute values (either the max or minimal value, a value can be) that way it doesn’t get in the way. If we wanted to represent six bits of information per pixel, then we’d have to tie in a “middle value” that isn’t the lowest a value can be, and not the highest a value can be. Then on top of that, we’d have to tie in alpha values as absolute values like we did with versions two and three. If possible we’d like to use a new image format to avoid these issues and possible store as many color combinations as possible to represent as many combinations of bits as possible. However, it seems the .jpg is the most supported image file format, as a result we can’t move to a new image format without the risk of secluding potential members of the community. Next, we will discuss the limits of the technology.
As we have discussed previously, the formula for how many possible combinations for an array of binary is defined as: 2 𝑥 = 𝑃𝑜𝑠𝑠𝑖𝑏𝑙𝑒 𝐶𝑜𝑚𝑏𝑖𝑛𝑎𝑡𝑖𝑜𝑛𝑠 Where x is equal to how many bits of potential information you want to store. So,first we calculate howThere are three values in an RGB value; Red, Green, and Blue. Each has an absolute value of 255 and a minimal value of 0. Mathematically, we need to account for the lack of color (0) as well, so we use 256 as a “real” interpretation to how many values can be contained within each RGB value. 256 x 256 x 256 = 16,777,216. So, we have 16,777,216 possible combinations of RGB values. We then adjust the formula accordingly: 2 𝑥 = 16,777,216 → 2 24 = 16,777,216 We have now proven that the maximum number of bits we can represent is 16,777,216 without use of Alpha values; However, there are two-hundred-fifty-six possible alpha values for every color, so if we wanted to talk about the max limit of the system with the inclusion of alpha values, we’d adjust the formula so: 2 𝑥 = (256 ∗ 256 ∗ 256)256; 2 𝑥 = 4,294,967,296 𝑥 = 𝑙𝑛(4,294,967,296) 𝑙𝑛(2) ; 𝑥 = 32 For ease of use, we will limit this to 32 bits per pixel. To put into perspective how dense this is, it is 4 bytes per pixel. My resume is 163,840 bits in size (20,480 bytes), we divide that by 4 (because we can store 4 bytes per pixel) and we get 5,120… we find the square root of that, and we get 71.55 x 71.55, we will round that to 72 pixels. So, all we would need is a 72x72 image!
If one were to first obfuscate or encrypt a data string, convert it to binary, then store it into string that gets stored as pixels, not only would you have a compression method, but an encrypted, compression method, where the data is stored locally in the BVAC code as instructions. This has many applications ranging from a method of block storage for blockchains for additional security (unfortunately, at the probable cost of disk space, at least until the consensus grows wide enough for this to have any actual effect as a compression method) to simply inventorying stuff like lab equipment and chemicals. This could also be used as a method of machine learning, as one could dedicate an AI to crunching and storing information as a BVAC code, both accomplishing educating the AI, and storing the information it has processed. To improve the BVAC system further, one can store the resultants of compression algorithms to a BVAC code, so that they may improve current compression techniques, without having to worry about loss of data.