Coinprism compared to Counterparty and Mastercoin

  • E72521

    Some updates for each project:

    [1] Colored Coins
    *Protocol Characteristics*
    Length of specification: 7 pages. A straight copy and paste (Abstract to Copyright) into Microsoft Word 2013 at default settings yields 7 pages.

    *Protocol Features*
    Locked assets: False. “Destruction” of a private key is neither possible (see Data Remanence) nor provable nor a protocol feature.

    [2] Counterparty
    *Protocol Characteristics*
    Uses no intermediate currency: True. For the purposes of this comparison, Counterparty does not need an intermediate currency to issue assets. Source – http://counterparty.io/news/counterparty-development-update-4/.
    Protocol specification document: True. https://github.com/CounterpartyXCP/Counterparty/blob/master/README.md.
    Length of specification: 8 pages. A straight copy and paste into Microsoft Word 2013 at default settings yields 8 pages.

    [3] Mastercoin
    *Protocol Characteristics*
    Length of specification: 51 pages. A straight copy and paste into Microsoft Word 2013 at default settings yields 51 pages.

    *Protocol Features*
    Locked assets: False. “Destruction” of a private key is neither possible (see Data Remanence) nor provable nor a protocol feature.

    • flaviencharlon

      Thanks for the comments. Using Word 2013 sounds like a good way to measure the length of a document so we will use your numbers.

      Regarding the Counterparty document though, this can’t be considered a specification. A specification must contain all the necessary details to reimplement the protocol from scratch. You can see that this document is far from containing sufficient details.

      Regarding “Uses no intermediate currency”: Counterparty uses XCP for the decentralized exchange, as well as optionally for asset creation, which are both part of this chart. So we can’t really say it uses no intermediary currency (the tooltip does add that it only relies on it for *some* features).

      Finally the locked asset feature has two parts: the first part is being able to prove to yourself (as the issuer) that neither you or anyone else who would steal your keys can reissue the asset. This can be done by generating a private key, signing the issuance transaction, and immediately destroying the key. Since the key only has to exist in memory for the length of time of signing one transaction (a few milliseconds), it is quite easy to do this safely. It would be also possible to program a sim card to do this within the hardware, in a way that it is provably impossible to access the key.

      The second part of that is being able to use the protocol to prove to others that reissuance of a token is impossible. The problem with that is that the protocol doesn’t control what the real-life asset actually is. So a dishonest issuer can still create an asset X, and offer to redeem it for a real asset he owns. Assuming the asset is locked, he can still create a second asset Y on the blockchain at a later time, and offer to redeem it for the same real asset. From a game theory standpoint, this is exactly equivalent to reissuing more of asset X. In Europe we have “old” 10 euro bills, and “new” 10 euro bills. They look different, however everybody uses them interchangeably because the ECB guarantees they are both worth 10 euros.

      If anything, locking an asset to give a guarantee of no reissuance to users is dangerous at best, because it gives a false sense of security. This is described in more details here: https://coinprism.desk.com/customer/portal/articles/1565998-is-it-possible-to-limit-the-re-issuance-of-a-colored-coin-

      So the only legitimate use for locking an asset is for ensuring theft of the keys is impossible, which colored coins and mastercoin can do through the process I described, without need for a specific protocol feature (though I agree, a protocol feature makes it the simplest to achieve).

      Thanks for your comments, please let us know if anything else looks odd.

      • E72521

        No problem. Before I continue, let me just say that this comparison table is very useful to me as I have an upcoming application which requires user issued assets. I have done my own due diligence on all three of these projects but it is an invaluable resource to have many of these parameters gathered together. Thank you.

        Point taken with regard to the Counterparty Protocol overview document. Like keeping laboratory notebooks in research, another individual (skilled in the art) should be able to recreate the work just from the notebook entries and I understand how this is currently not the case with that particular Counterparty Protocol document.

        I am afraid you are mistaken – XCP is NOT required to use the decentralised exchange (this has been true since day one!). True, it is optionally required for asset creation as an anti-squatting mechanism. I can only repeat this again – if I want to issue assets for free on the Counterparty Protocol AND trade them with any other asset on the Counterparty Protocol I can do so without EVER touching XCP. You are correct that XCP can be used for other features (betting, CFD’s, etc.) that are outside of the scope of this comparison.

        I am not satisfied with your comments with regard to the Locked Assets. I will take some time to prepare a more thorough response to this. For the time being, my assertions based on the evidence are as follows:

        [1] It is impossible to Lock the re-issuance of an asset at a protocol level with this Open Assets Implementation

        [2] It is impossible to provably Lock the re-issuance of an asset, in any way, with this Open Assets Implementation (from the perspective of everyone but the original owner of the corresponding private key)

        As such, I don’t see how Coinprism or Mastercoin have a True for “Locked Assets” in this comparison table. Particularly when it is listed under “Protocol Features”, considering you just said it is not a Protocol Feature (and I agree). You’re proposed solution is flawed, external to the protocol and requires trust in the issuer.

        • flaviencharlon

          Thanks for your response.

          I never claimed XCP was required for those features, neither does the table: the table reads “Uses no intermediate currency”. It would be very misleading to say the Counterparty protocol uses no intermediate currency. I feel it is important to show the fact that the XCP currency is part of the protocol consensus as it can create a moral hazard and incentivize people to fork the protocol. You can see Bitcoin has been forked a hundred times by alt-coins, whereas nobody is feeling the urge to fork something like TCP or HTTP as there is no built-in currency.

          Again I agree that the decentralized exchange doesn’t require XCP (though the experience when trading with BTC leaves a lot to be desired, as you have to keep your client open, the trade is not atomic, and AFAIK, it has been recently been disabled in Counterwallet because of these limitation). But to make it very clear that XCP is not required, I will add a row in the table “Decentralized exchange can be used with BTC only”.

          Regarding the asset locking feature, my point was it is possible to achieve the same effects as locking the asset without needing a specific protocol feature. But you’re right that as such, there is no actual protocol feature, so I will change it to “False”.

  • Jamie Cansdale

    Useful comparison, thanks! On the “Prevents asset loss” row, shouldn’t Counterparty and Master have an ‘x’? Or do they really have this feature?

  • Globe99

    Can you explain “callable assets”? How would you “call back” a colored coin? I understand dividends, but what is repudiation and how is that used to call?