-
Notifications
You must be signed in to change notification settings - Fork 47
Metadata
The new colored coins protocol supports adding (potentially arbitrary amounts of) metadata to any colored transaction ([issuance](Coloring Scheme#issuance-transaction-encoding) or [transfer](Coloring Scheme#transfer-transaction-encoding)). The metadata is in plain JSON format and it's inclusion is optional.
When metadata is included it is not stored directly on the blockchain but rather using the BitTorrent Protocol which gives a decentralized way to share and store data. We use the new DHT trackerless torrents that remove the need for a centralized host for torrent file trackers, further supporting decentralization of our protocol.
The BitTorrent protocol uses a SHA1 hash to reference the file that stores the actual data. This 20 byte SHA1 info_hash is recorded on the blockchain.
Because SHA1 hashes are no longer considered cryptographically secure this opens up the (somewhat theoretical) possibility that a preimage attack on the torrent info_hash can cause us to load the wrong data from torrents. We provide a simple counter measure to deal with this possibility. The protocol supports recording an additional SHA-256 hash of the metadata on the blockchain. This way we can verify the torrent data integrity before using it. Including the SHA-256 hash of the metadata is optional and metadata recorded on the blockchain without the additional SHA2 for verification can be considered to be of lower security.
The torrent 20 byte SHA1 info_hash referencing the metadata in a colored transaction is currently recorded on the blockchain using a single [OP_RETURN](Coloring Scheme#op_return) output (if 40 bytes are enough) or potentially with one additional [(1|3) multisignature address](Coloring Scheme#multisignature-addresses-multisig) when also the SHA-256 metadata hash is included.
When a SHA-256 hash of the metadata is included for additional security, it is currently (as long as OP_RETURN is limited to 40 bytes) recorded on the blockchain using a (1|2) or (1|3) multisig address, depending on circumstance.
In the future, when the Bitcoin network starts accepting 80 bytes OP_RETURN, we may include both the SHA1 torrent info_hash and the SHA-256 metadata hash after the OP_RETURN. In that case it may be beneficial to further compress the SHA-256 using an additional RIPEMD-160 so that also the SHA2 blockchain record size is limited to 20 bytes.
Metadata support is one of the new novelties introduced by the new colored coins protocol. There are two basic parts: [Static Data](Static Data) and Rules, each discussed in detail in the linked sections. Generally, the data section consists of various static data fields while the rules section encodes an extra layer of logic supported by our rule engine that unlocks smart contracts functionality to colored coins.
[Static Data](Static Data) goes under the metadata key, Rules go under the Rules key.
{
metadata: {...Static data goes here...},
rules: {...Rule definitions go here...}
}Currently only the following keys are recognized:
js
{
metadata: {
assetId: String,
assetName: String,
assetGenesis: String, // block + tx of the genisis for this asset
issuer: String, // Name of the asset issuer
description: String,
urls: [{name_1, url_1, mimeType_1, dataHash_1},{name_1, url_1, mimeType_1, dataHash_1},... ],
userData : {meta: [{key_1, value_1, type_1},{key_1, value_1, type_1},...],
user_key1: user_value_1,
user_key1: user_value_1,...
},
encryptions: [
{key: "user_key1", pubKey: 'RSA Public Key',format:'pem|der',type:'pkcs1|pkcs8' }
],
},
rules: {
fees: [{}],
expiration: {},
minters: [{}],
holders: [{}]
}
}
All the above keys are optional (except for assetGenesis in case of re-issuance by minters).
Moreover, even though the basic colored coins code will ignore other keys, any one can fork the colored coins opensource code and add supporting logic for more keys.