Byte3 is a novelty item with the capability of storing and transmitting merit data. It has the unique ability to retain the merit data in both digital and physical forms.
A single unit of the byte3 is called a byte cube.
A giga cube is a group of byte cubes.
A slice is a group of byte cubes taken out of a giga cube.
A holder is anyone in possession of one or more slices.
Byte3 is built on the foundation of the base-2 numeral system; all of the calculations are based on the power of two (2x). A byte cube is represented with one byte, which consists of eight bits (23). A giga cube is a three-dimensional cube array of byte cubes with the length of 1024 (210) byte cubes in all three directions. This makes a giga cube have a total of 1073741824 (230) byte cubes. Each giga cube has a unique ID and a specific merit type that it uses in concurrence with.
Giga cubes are used to establish the merit type and to hold the data. Slices are used to represent portions of the merit data that are calculated against the total size of the giga cube as a whole. This can be used as a solution to bridge different types of merit data. Having the ability to be both physical and digital, and enables the bridging of merit data in all possible digital and physical variations. Conceptually, byte3 is a self-sustained middleman economy.
To summarise, byte3 is a unique, limited, and secure product that is capable of storing and transferring merit data digitally and physically in ways that have not been possible before.
First, a unique ID and a merit type are assigned to a giga cube. The giga cube is then issued a three-dimensional array that is filled with empty bytes. Our proprietary algorithm goes over each byte, in the new giga cube, and gives it a unique non-repeating value. The giga cube gets locked and is then turned into a read-only entity. From this point forward, it becomes a single source of truth for all of the same merit type transactions.
An exchange can be accomplished when the merit data is of the same size as a giga cube. The merit data value is calculated against the total size of the giga cube. This calculation is represented in the form of a byte cube slice. This slice is issued in exchange for the merit data, and the same slice can be exchanged in return for the merit data.
Each issued slice is assigned a secret key and unique signature that gets logged into an internal ledger. When being returned, the slice can be identified and verified using this data. This validates its right to the specified merit data. After cross-referencing the slice's data against the giga cube, the merit data is exchanged in return for the slice.
The software will always remain closed-source. We believe in security through obscurity.
There cannot be more than a total of 256 giga cubes. Once a 256 giga cube is created, no more giga cubes can ever be created.
All transactions with the giga cube are unilateral. Once a slice is issued or returned, it cannot be reversed. Every action can only be executed once.
Slices are retrieved as rows from the giga cube using modular arithmetic. Rows are calculated with the X, Y, and Z axes. Each giga cube has its own sequence of the three axes. The calculation starts with the rightmost axis and increments it by one until reaching the modulus value of 1024. At that point the axis is wrapped around to zero and the left-hand side axis gets incremented by one. This continues until the giga cube is exhausted and all three axes wrap around and synchronise at zero.
When a slice has been issued from a giga cube, the byte cubes involved in the transaction can never be issued again. They will be exclusively reserved for the validation of the slice when it is being returned.
The minimum allowed byte cube slice length is 10. This is to decrease the probability of a brute force attack.
A slice must be self-contained. It should never need intermediary involvement for completeness. There should never be a need to login, confirm an email, or make any other type of action to get a missing portion of a slice. This does not apply to any additional preventive measures that holders may have implemented to secure their slices.
A slice cannot store any personally identifiable information. As an extra precaution, any submitted slice that contains additional information will be immediately rejected. This is to discourage holders from attaching additional data that may be personally identifiable.
A slice must be mutable while maintaining the same size and retaining the same data within. This is to allow holders to mutate their slices, in case they may have compromised them somehow.
A slice can mutate a maximum of 256 times. If it needs to mutate any more than that, then there is either a serious security issue on the holder's side, or it is time to return the slice.
The ledger cannot store any personally identifiable information. The purpose of the ledger is to verify the integrity of a slice before allowing it to be compared with the giga cube. There should never be a reason to have any other information in the ledger.
The ledger cannot store any slice data derived from the giga cube. The giga cube always stays as a single source of truth. Special measures have been put into place to guarantee the integrity of a giga cube's data; slice data should always be compared against the giga cube since it is guaranteed to be accurate.
The slice meets all of the requirements for classification as a digital product and a physical product.
The slice can maintain a constant, and provable value regardless of shape, size, or current form (physical/digital).
The slice has no expiration date and does not require any special software to store, transmit, transport, or change form.
The slice can be transported and transmitted through any existing or any future created and/or discovered methods of transport and/or transmission.
The slice can be useful in circumstances where merit data does not have all the necessary components for successful transmission and/or transport.
The slice has the unique ability to be mutated upwards of 256 times, all while maintaining the same size and retaining within itself all of the original data. The mutations are forward-only, rendering any previous versions of the slices un-usable. This provides a slice holder with the ability to secure their slice if the data was (or is believed to be) compromised.
Aside from the encryption, each slice is assigned: 64-bit giga cube key, 64-bit ledger key, 128-bit signature, and a 1024-bit secret key. This information is added on top of the data issued from the giga cube. With a few additional pieces of information written into a byte cube slice, the value comes out to be a total of 256 bytes minimum. That is equivalent to a 2048-bit size used in modern-day cryptography.
To explain the difficulty of a brute force attack on a minimum length byte cube slice, a pseudo solution will be demonstrated if you use one of the fastest CPUs available on the market, with a hefty price tag greater than that of an average monthly salary. The 64-core 2nd generation AMD Epyc server CPU, at a maximum clock speed of 3.4GHz. For a very minimal calculation let us assume that a 256-byte array can be incremented by one in under 64 instructions on an 8-bit CPU. The amount of time needed to try and guess all of the possible variations of the slice is so unfathomable that no number can be used for reference. If you take all the time that has ever been in our universe (13+ billion years) and multiply it by itself, that will still not be enough time to guess all of the possible values for a successful brute force attack on the smallest byte cube slice (click here for a more detailed calculation breakdown). This is without considering the bottleneck of sending every variation of the file over the internet, or the financial overhead needed for such an operation.
It is safe to say that there should never be a single instance of where a slice was stolen via brute force. A slice will be as secure as the holder keeps it secure.
Since the product is private by design, there is no discernible or identifiable proof of ownership for a slice. Whoever owns the most recent version of the mutated slice, has full control of it. A slice should be transferred, stored, and secured with the same caution that would have been exercised with the merit data.
This is a quick breakdown of the variables used and how the math was applied to come up with the final number.
target=2^256 // size of the smallest slice
GHz=1000000000 // clock speed of 1 GHz
// The longest possible instruction on x86 is 15 bytes
// thus 256 byte array / 15 = ~17
instructions=18 // number of minimum instructions to increment our byte array
cycles=3 // number of cycles for the instructions to get the final result back
// the instruction/cycle calculation is greatly skewed, but since we do not include any IO and NET calculations, this error margin is in our favour
calculations_per_day=(((cores * 3.4 * GHz) / (instructions * cycles)) * seconds * minutes * hours)) // this is maximum number of results we can achieve in a 24 hour cycle
days=(target / calculations_per_day)
days=332582976899460579686267764845725838273408733529528270000000000 // this is how many days it would take to get all possible outcomes
iot_devices=75440000000 // projected amount of IoT devices online by 2025
days=(days / iot_devices)
days=4408576045857112668163676628389791069371801876054192 // number of days if all IoT devices participated and had same CPU's
universe=13800000000 * 365 // age of the universe in days
universe_spans=(days/universe) // trying to get the number to be smaller by comparing against the age of the universe and not days
universe_spans=875238444680784726655484738612227728682 // still a big number