A complete cryptocurrency economy will require a comprehensive suite of financial tools, only one of which is the cryptocurrency itself. The financial cryptography tools provided by Open-Transactions fill in many gaps that are not handled by blockchain-based currencies, however the cooperation between OT goes even further.
Many of the advanced features of OT require the cooperation of a blockchain in order to function. In particular, multisig output scripts are required for voting pools to securely hold deposits. Another feature that will see significant usage in OT is colored coins.
Colored coins will enable two important features in OT: the immutable naming of mutable asset contracts, and the ability for OT assets to transcend individual servers (federation).
Naming with Hashes
One extremely common operation in computing is to name things. One of the most common ways to name something is with a hash.
Using hashes as names has several advantages:
- Hashes are a constant small length regardless of the size of the object being hashed
- Hashes are easy to verify
- Any change to the object being hashed will result in a different hash.
That last advantage implies: one feature of hashes as names is that hashes can only refer to immutable data (data that never changes). This is fine in many cases because applications often work with static data, but there are cases in which it would be desirable to create a permanent, objective name for data which can change.
Immutable naming of mutable data
One situation where this need arises is in Open-Transactions, specifically in the asset contracts for voting pools. These contracts must be able to change over time as they add new key data, and add or remove pool members. Because of this, it’s not possible to use a hash to unambiguously identify them.
This situation presents hard problems to solve: if the contract can change, and if only one version can be valid, how do we know which of several proposed versions is the correct one? Who is authorized to make changes to the contract? How do we distinguish valid changes from invalid changes?
Problems like this can not be solved by hashes, but they can be solved by blockchains.
“Colored coins” is a general description for schemes that track individual Bitcoin (or other cryptocurrency) outputs and assign special meaning to them. There are several methods for assigning color values to outputs, and the one that is most useful in this case is transaction-based coloring.
In transaction based coloring, a coloring scheme can be defined with two parameters:
- Genesis Output: this is a specific output from a specified transaction (the genesis transaction).
- Color Kernel: this is the set of rules that will be applied to any future transactions which spend colored outputs in order to determine the coloring of the child outputs. An example of the most common type would be POBC (padded order-based coloring). The kernel used to create indivisible smart properties is IFOC (indivisible first output coloring).
Once the parameters have been chosen, they can be expressed as a color definition as follows:
where txid refers to the hash of a specific transaction in the blockchain, output is an integer index identifying the colored output in that transaction, and height is the block in which the transaction was first confirmed.
Here’s an example of a color definition:
Using Smart Property as a Naming System
One of the new features in Bitcoin Core 0.9 is the standardization of an output script type for storing up to 40 bytes of arbitrary data. This script type is named for the opcode used to create it: OP_RETURN. This ability to add arbitrary data to transactions is what makes it possible to use smart property coins to identify mutable objects.
Here’s how to use a color definition to track a mutable OT asset contract:
- Create an IFOC colored coin (smart property)
- Create an OT asset contract, and include the color definition in the contract header.
- Move the smart property, and in the transaction include an OP_RETURN output that contains the hash of the OT asset contract
- If the asset contract ever changes, repeat step 3 with the hash of the revised contract.
Now it’s possible to use the color definition to unambiguously resolve the asset contract. The blockchain will enforce an implicit policy that holding the private key(s) necessary to spend the smart property is both necessary and sufficient to revise the contract. The choice of addresses where the smart property is held should reflect the intended behavior. This means that if a single person is authorized to revise the contract then normal addresses could be used, and if changes to the contract should require multiple entities to concur then multisig addresses should be used.
Issuing Assets as Colored Coins
The previous discussion showed how to use colored coins as smart property, which is probably not what most Bitcoin users think of when they hear the term “colored coins”. The most commonly-known usage of colored coins is to issue redeemable tokens, such as shares of stocks. Open-Transactions will use this functionality as well. Unlike IFOC coins, colored coins of type POBC are divisible and encode the number of units in the balance of the output. POBC coins can be split and merged as desired.
Open-Transactions can take advantage of this property to create server-independent assets which can still be processed on OT servers.
The process for creating federated OT asset contracts is:
- The asset issuer should create a POBC coin that encodes the number of units they wish to issue.
- Create a smart-property asset contract as per the previous section. In this contract, reference the POBC color definition in the body of the contract.
- Deposit some or all of the colored coins into one or more voting pools to allow transaction servers in those pools to process contracts denominated in the issued units.
At this point, transaction servers have an objective and server-independent way of verifying a balance denominated by this contract. Users can “wire funds” from one server by moving the colored coins.
Extending Transaction-Based Coloring
The primary advantage of a transaction-based coloring system (as opposed to address-based coloring) is that the blockchain enforces the quantity of issued units. The disadvantage of this is that it’s not possible to issue more units of a given type after the initial creation of the colored coins, and the resolution of a blockchain balance may not be large enough to keep the monetary value of the colored coin insignificant compared to the color value.
OT contracts can solve both of these downsides while retaining the advantage.
Since we’ve used smart property to make OT asset contracts mutable, now it’s easy to extend an asset contract to reference multiple POBC color definitions. In the event it’s necessary to issue more units, the issuer can issue new colored coins, then simply append the definition to the contract and activate the new version by moving the smart property. The same procedure can be used if needed to get higher resolution – the original contract is not limited to a single color definition any more than the revised versions are limited.
Tying it Together
As is usually the case, the merger between OT and blockchains is greater than the sum of the parts. Colored coins provide capabilities that OT could not otherwise obtain. Using OT contracts to define the semantic meaning of other colored coins solves outstanding problems with transaction-based coloring that could not otherwise be solved without OT.
Once colored coins are powering OT asset contracts, the sky is the limit in terms of functionality. Colored units will be usable in any smart contract OT can process. Those units can be traded on exchanges, held in escrow or used as currency. Users will get full-speed operations made possible by a client-server architecture without being completely at the mercy of the good behavior of the server (if the colored coins are held in voting pools). By proper application of colored coins and OT, we can get the best of both worlds.
- Open Transactions Server Set Up Tutorial
- Open Transactions Development News: May 2014