OpenAssets deficiencies

iddo333 edited this page May 26, 2015 · 15 revisions


OpenAssets deficiencies are already a common knowledge among the people who work with colored coin protocols, but so far there was no document which explains them in details.

Historic context

Problems largely stem from the fact that the protocol was finalized before it was carefully analyzed and reviewed by experts:

  • Flavien Charlon requested feedback for an OBC-based version of OpenAssets (which was radically different from the current version) on April 6, 2014.
  • This version was harshly criticized by Bitcoin mailing list participants.
  • A week later, on April 11, Flavien have proposed a version which encodes color values in OP_RETURN output, which is the same protocol which is in use now.
  • A live version of CoinPrism was launched on May 14, but no source code was provided.
  • Particularly, there was no thin client code (CoinPrism backend was a full node), so thin client code efficiency could not be assessed.

Obviously, backwards-incompatible changes to the protocol could not be recommended after the live launch.


Thin client efficiency: assets are not isolated from each other

Description. OpenAssets protocol requires clients to validate all inputs and outputs of a transaction:

These two sequences are built by taking each input or output in order, each of them adding a number of asset units equal to their asset quantity. The process starts with the first input of the transaction and the first output after the marker output.

After the sequences have been built, the asset ID of every asset unit in the input sequence is assigned to the asset unit at the same position in the output sequence until all the asset units in the output sequence have received an asset ID. If there are less asset units in the input sequence than in the output sequence, the marker output is considered invalid.

This means that client must know asset IDs and values of all inputs before it can validate a transaction.

This can create a significant problem for thin clients, which would need to validate not just the asset that they receive, but also all the assets that they have ever interacted with via atomic swap transactions.

For example, suppose that a wallet is optimized to work with a specific asset of a specific issuer, e.g., gold. But a gold coin that it receives might have been bought for USD coloredcoin at some point of its history, and now this client needs to check both the gold and USD assets history to validate this coin. Thus, in the general case, amount of data which is sent for validation is unbound, even for a wallet which is designed to work with a limited number of assets.

Importance. This deficiency creates a real, intractable problem for applications involving validation on resource-constrained devices, e.g., smart property and applications that require authentication/authorization such as tickets, etc. Indeed, suppose that a smart property device like a car grants access to a colored coin owner. When ownership is transferred, it needs to validate a coin. In a situation where a car was bought using an atomic swap transaction for gold, the car's smart property chip will need to validate both the car coin and the gold coin, but the gold transfer history might involve millions of transactions, and thus it might be impossible to validate it within a constrained memory available to the chip.

Similarly, when a ticket is bought for USD coloredcoin, the ticket verification device would need to go through the USD coloredcoin history, etc.

Thus it can be inferred that OpenAssets is unsuitable for smart property and exchange of digitally-represented assets, which are considered to be some of the most practical colored coins applications.

But this also make it less useful for currency-like applications: if a currency based on OpenAssets protocol can't be used to buy smart property (unlike currency based on other colored coins protocols), it is less useful to its end users.

But even if we put smart property and similar applications aside, this deficiency can lead to a bad performance for all thin clients, as a wallet needs to validate even assets that it hasn't received. Thus it is quite likely mobile wallets built on top of OpenAssets protocol will have to resort to a centralized validation, which largely undermines the whole idea of using colored coins (why not just use SQL if you can't validate it anyway?).

Analysis & possible solutions. The root cause is that OpenAssets input/output matching depends on colorvalues of inputs, and thus cannot be decided locally having only the transaction in question and the transactions link to it.

This could have been addressed on the protocol design stage: the problem could be avoided if marker output included not only output values, but also asserted input values, or just input/output grouping. In that case it could be possible to validate individual groups rather than a whole transaction at once.

A protocol amendment can be made to make validation more permissive. This might lead to disagreement between old and new clients: old clients might not be able to see coins sent by new clients, which makes this protocol amendment problematic.

Comparison to other protocols. The theory of colored coins article recommends to design color kernels in such a way that each color can be validated in separation, thus we can attribute this deficiency to a disrespect to established practices.

Many of colored coins protocols, such as OBC, EPOBC and CoinSpark are free from this deficiency and allow validation to be performed for an individual color, or even on the output granularity.

Moreover, OBC family of the protocols can be further improved with follow-the-satoshi approach, reducing the maximum proof size down to a level which is similar to what is required for SPV validation.

Lack of non-reissuable assets

OpenAssets assets are identified by a hash of isser's scriptPubKey. This allows the issuer to create as many issuance transactions as he wished to, at any time, which means that the total number of colored coins of a specific asset is unbounded.

Flavien Charlon claims that non-reissuable assets can be created by destroying a private key used during issuance, but since it is impossible to prove that the key was destroyed, de-facto it is impossible to guarantee that an asset is non-reissuable.

Historic context

Genesis-based and address-based issuance methods have been extensively discussed since the first colored coin standardization effort in the Autumn of 2012. We found that address-based issuance makes follow-on issuance easy to implement, but it makes control over how many colored coins are issued hard (or impossible to implement), which creates problems both for an issuer and for holders.

A clear solution to this problem was proposed by Albert Hendriks in the April of 2013: he proposed to separate a notion of "color" and "asset". A color is a single, distinguishable batch of colored coins created in a single genesis transaction, and thus finite by definition. An asset is a set of colors.

This allowed an unification of genesis-based and address-based approaches: colors are issued in genesis transactions, but assets can be associated with a particular address (or scriptPubKey), and thus the client software can automatically identify all colors associated with a particular asset.

Early versions of OpenAssets protocol had a notion of non-reissuable colors (particularly, those which were co-authored by Vitalik Buterin), but this was removed in the final version of the protocol.

Problem 1: lack unique assets (smart property)

Many applications require assets to be unique, e.g., when a colored coin is associated with a particular physical object. One example is a smart property: a device which can only controlled by its owner, who is identified by cryptographic means. Another example is property registry: a person who owns a real estate title can authenticate himself by using cryptography.

The whole point of using Bitcoin protocol for this kind of applications is that it enforces uniqueness during transfers (by preventing double-spending), thus making ownership tokens transferable (and thus sellable).

This means that OpenAssets, which lacks a notion of unique assets, is unsuitable for this kind of applications. The fact that the issuer might destroy his private key is obviously not a solution, as it is not possible to enforce or guarantee that. And if the issuer is able to issue more colored coins, he retains control of the property, which means that using colored coin as an ownership tracking method is no better than using centralized ownership tracking.

Let's consider a concrete example: In cases with genesis-based colored coins, a car manufacturer can embed a genesis hash (which identifies the color) into car's ownership check chip. The ownership token can later be transferred to the buyer, and nobody, not even car manufacturer will be able to override this without removing the chip.

On the other hand, address-based colored coin protocols, such as OpenAssets, leave a back door: the original issuer might retain a private key which can be used to create additional tokens, indistinguishable from the original one on the protocol level. The issuer might claim that the private key was destroyed, but this cannot be enforced. Even if the issuer willingly tries to destroy the private key, there is a number of ways how it might be leaked at later time:

  • the device which was used to create the colored coins might be compromised
  • private keys might remain on the device due to a hardware or software defect
  • keys can be leaked due to problems in PRNG
  • keys can be stolen by a rogue employee

Thus we conclude that OpenAssets is fundamentally less secure for these kinds of applications.

Problem 2: lack of finite assets

Some assets are valuable only as long as they exist in finite amounts. Some examples:

  1. limited issuance of music album licenses
  2. closed club membership cards
  3. a currency which is deliberately in a finite supply
  4. non-diluteable shares

Note that in these examples issuer of the coins has no special role after the coins were distributed, as these coins aren't supposed to be redeemed. Thus an argument that "you have to trust the issuer anyway" is not applicable here.

Indeed, a closed club members might want to use colored coins specifically if they do not wish the originator to have any special powers. After colored coins are created and distributed, club members can check each other's card without the involvement of the issuer.

In the fourth example, nominally the company itself is the issuer, but in practice, there is always a particular person who has a higher degree of control over the process. For example, a CTO may prepare software and hardware used for issuance, and he could save a private key (e.g. using a modified version of software) in order to have a backdoor. If a shareholder agreement specifies that a finite number of non-diluteable shares will be issued, and at later point the CTO issues additional shares (in disagreement with the other shareholders), the state of the colored coins based shareholder registry will become inconsistent with the originating contract, leaving it in doubt whether whether the shares could retain any of their value.

Problem 3: private key leakage makes owner registry useless

OpenAssets doesn't distinguish between different issuance batches on the protocol level. This means that additional batches created by an attacker who have stolen the issuing private key(s) will be indistinguishable from the legitimate coins.

Let's consider a concrete example: A company wants to create a new payment system. It issues OpenAssets colored coins and writes a legal contract that defines that these colored coins can be exchanged for US dollars. Colored coins go into circulation, and at a later point in time the private key that was used for issuance is stolen. The attacker creates colored coins worth billions of US dollars and tries to exchange them to bitcoins through anonymous exchanges. Fake US dollars flood the market, which soon get noticed. Exchanges are halted, merchants are notified that they should no longer accept this kind of USD coloredcoins, and users are notified as well.

This is already a bad scenario (as we will demonstrate in the next section, it is preventable), but more importantly, OpenAssets makes damage control and liquidation hard or impossible.

Normally we'd like to separate legitimate coins which were issued by the company itself (and represent claims on its assets) from fake coins created by the attacker. But OpenAssets protocol deliberately does not distinguish between different issuance instances of colored coins. This means that:

  1. Neither merchants nor users can check whether coins they have in the wallet are fake or not. They will need a special "forensic" client to be able to do so.
  2. The contract which is signed by the issuer cannot be restricted to legitimate coins only, which means that company's liabilities can exceed its assets by many order of magnitude, and therefore the assets of the legitimate owners may become diluted (unless the court can recognize the fake coins and specify that they do not represent valid claims).
  3. Investigators and the court will have to use a special "forensic" OpenAssets client (or do a manual investigation that inspects the blockchain by using block explorers), as regular clients cannot distinguish different batches.
  4. Real and fake coins can be mixed. The court will have to define how this should be handled.

This means that in order to deal with a clean up after a private key leak, and unless we want the legitimate currency owners to be diluted (i.e., get tiny fraction of what they should own), the court/investigators/issuer will have to define a protocol which 1) differentiates between different batches and 2) can deal with the situation where coins from different batches are mixed. They will also have to implement this protocol in software.

This means that by itself OpenAssets is very poorly prepared to deal with this situation, which is, unfortunately, quite realistic, as cybersecurity risks are very difficult to eliminate.

It is worth noting that if we had to rely on the issuer's trustworthiness and his ability to keep the ownership database secure, we wouldn't need colored coins in the first place.

A fraudulent issuer might leak private keys on purpose, as it would allow him to steal the assets. The underlying point here is this: it is a bad idea in general to let the person who owes you money to control the records which specifies how much he owes. While the OpenAssets protocol doesn't allow the issuer to manipulate individual entries, it allows the issuer to poison the whole registry by leaking his private keys.

Problem 4: No fine grained control over issuance

OpenAssets protocol supports multi-signature scriptPubKeys, thus allowing configurations more secure than a single private key: it is possible for example to implement a policy where signatures of three board members will be required to approve a new issue of shares.

But there remains the problem that users have no power but to accept new issuance of coins, as long as it is properly signed.

We already described a problem in the previous section: private keys might be stolen. In the case of OpenAssets, it leads to immediate, irreparable damage.

But as was established during colored coin research in 2012-2013, cybersecurity risks can be mitigated through issuance policies. E.g., it can be defined that new batches become effective only 5 days after they were published on the blockchain.

Let's consider the same scenario as was discussed in the previous section. An attacker, who have stolen the issuing private keys, creates colored coins worth billions of US dollars. But he can't exchange them to bitcoins immediately. After this illegitimate transaction is published on the blockchain, the legitimate issuer have 5 days to mitigate the damage by warning the users, traders and merchants.

Thus in this case the attack may lead to a disruption of service, but it won't lead to irreparable financial damage done to traders, users and merchants, nor to the company itself.

Possible solutions

Unique and fixed assets can be added to OpenAssets by introducing a new kind of asset identifier based on genesis transaction hash.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.