This document describes the e-cat (pronounced E cat) protocol. For contributions, look into CONTRIBUTIONS.md.
This protocol depends strongly on bcat protocol, which was introduced to offer a solution for putting files larger than the standard transaction size limit in BitcoinSV. The bcat protocol itself, relies on B://, which is a format for constructing transactions that will contain any type of content, (especially Raw Binary data) and is considered the standard for constructing OP_RETURN transactions so that different parties will be able to deconstruct and read the content of those transactions.
The e-cat protocol combines cryptographic methods to put all types of data on the blockchain. The data is Encrypted in a way where only parties with pre-defined authorizations will be able to decrypt and concatenate the data from the blockchain. The protocol also offers a way of sharing these encrypted data and defining new access rules, without the need to upload and decrypt/re-encrypt the whole file again.
We have changed the principles of B:// and bcat for e-cat and have defined some new ones The way that we are constructing the B parts, is almost identical to the original protocol, with one little exception, we are using our own namespace instead of bitdb's. Our namespace for B parts, is ecat::EPT. So the exact specifications of constructing a B transaction is as follows:
ECATpart namespace:ecat:EPT(OPTIONAL)Order (index) of this part in the list of file chunks- Raw data representing a part of the original file
We are using AES symmetric method to encrypt the file, and therefore we need to generate a secret key. After encrypting the file's content, we will split the encrypted payload to properly sized chunks and construct the B transactions following the specifications described above.
1. A unique `secret key` will get generated
2. The file will get encrypted, using the same `secret key` in a symmetric way
One of the changes that we have made to the bcat protocol, is we have defined something called an decryption key. These decryption keys are basically, an Encrypted version of the secret key used to encrypt the file in the previous step.
We have defined two different parties in our protocol, one is the Owner of the file and the other is ecat.media. The e-cat protocol, enables both parties to access (decrypt)
the file from the blockchain.
The method that we have used to prevent any unauthorized access to the file content, and give the authorized parties the ability of decrypting the file content, is to create decryption keys using authorized parties' Public Keys, so they would be able to use their Private Key and find the secret key required to decrypt the file.
3. The generated `secret key` will get encrypted twice, in an asymmetric way:
* `secret key` + `your public key` (I)
* `secret key` + `ecat's public key` (II)
4. We will call those two payloads, which were generated in the previous step, `encryption keys`
We are following the main idea behind the bcat protocol, and below, we have described the process of creating different parts of this transaction.
After crafting encryption keys, we will be able to create our final bcat (linker) transaction.
These are the specifications for creating a linker transaction:
ECATlinker namespace:ecat:ECT'type'literal string- String providing file MIME type, e.g.
image/jpeg - Hexadecimal
Spacecharacter:0x20 'name'literal string- String providing file name, e.g.
ecat_picture_sample - Hexadecimal
Spacecharacter:0x20 encryption keyrelated to user/owner (I)'okey'literal stringencryption keyrelated to ecat (II)'eckey'literal string- 32 bytes representing the bytes of the hash of the transaction with the
firstpart of data of the file - 32 bytes representing the bytes of the hash of the transaction with the
secondpart of data of the file - ...
5. We will put those `encryption keys` inside the `bcat` transaction that we are going to construct, next