What is the basic differences between Colored Coins and CP?

I’ve read CoinPrism (OA) breakdown of the comparison here:
Some things are old (CP now uses OP_RETURN as well)

What is the CounterParty view on the feature list and comparison?

I’m looking to implement a token based issuance platform on top of either CC or CP. I’d like to know the pros and cons of each. Token exchangeability is important to me, but so are the abilities to implement whitelists or fees on token transfer.

I’m looking specifically at the free “A” assets in CP. I don’t want to deal with XCP.

Also what are the structural considerations between using Addresses (CP) vs UTXOs (CC)

What is the conderations for SPV type security of wallets?

CP does everything CC can do, and more. The largest advantage of CP is the network effect. There are several CP wallets, block explorers and open source tools. Everyone who holds Folding Coins, LTB Coins, Speels of Genesis cards, etc, all ready have a CP wallet. For them there’s no barrier to also use your tokens.

Token exchangeability - there’s the DEX (decentralized exchange) as well as vending machines.

Whitelists - these you’ll have to define for your use case. It’s not a part of the protocol.

Asset transfer fee - only the bitcoin miner fee - 0.00001-0.0001 BTC

Numeric A-assets are okay, but I recommend an alphabetic one. For the latter you only need a 0.5 XCP (~$0.45) registration fee once. Your users will not need XCP.

Structural considerations - if a CP asset is sent to a non-CP aware wallet, the asset is NOT lost. It can be recovered (i.e. sweeped to a CP wallet) from its private key. Therefore every Bitcoin address is also a CP address. With CC this is not the case, I think. If a CC asset is sent to a non-CC wallet the asset is forever lost.

All CP wallets except the counterpartyd command line wallet, I think, are SPV.

One of the interesting things in the coloredcoin protocol is that it allows for fees to be paid to a 3rd party address in order for transactions to be made. Would this be possible to be supported in CP protocol?

[quote=“JPJA, post:2, topic:1594”]
Structural considerations - if a CP asset is sent to a non-CP aware wallet, the asset is NOT lost. It can be recovered (i.e. sweeped to a CP wallet) from its private key. Therefore every Bitcoin address is also a CP address. With CC this is not the case, I think. If a CC asset is sent to a non-CC wallet the asset is forever lost.
[/quote]I believe this is no longer the case with OA and CC protocols as they enforce sending only to uniquely encoded addresses to prevent accidentally sending to a non-compliant address.

The parts that I’m interested in though is how CP handles atomicity of swaps. The CC guys say that because they use UTXOs they can guarantee atomicity of a swap in a transaction. (which is true) While in CP, how is atomicity guaranteed? I assume by matching two separate order transactions, but say I place an order (and the system should be now escrowing my assets) what keeps me from hand rolling a transaction that spends away those assets?
The only way I can see this working is if my assets are sent into a multisig address in the interim while the order is active, and the CP servers have a key to preform the match when the crossing order is found.
is this how it works?


Excellent questions - maybe @loon3 @deweller @jdogresorg @brighton36 have the answers?

Once you place an order to sell on the DEX, the assets are locked up and you can’t spend them away with any transaction until that order is cancelled and the assets are released from the DEX.

This works because the asset balances are held in a database parallel to the blockchain. And all counterparty nodes verify these balances in their own copy of the parallel database independently to form a distributed consensus.

On a side note, you might want to check out our tools at Tokenly, specifically Swapbot, if you you want a ready-made solution to sell tokens.

I see thanks.

So there is really two levels of security in CP, Bitcoin security and escrow security ( which is weaker than Bitcoin security and relies on counterparty servers consensus. )

The funny thing here is that although CP servers may decide what the state of the token assets ownership a are there is nothing to stop someone to creating “orphaned” txns on the blockchain because the counterparty blocks are a parallel chain which the real blockchain does not verify.

How does the consensus work between CP servers if one has a conflicting view of the state? Majority rules?

I suppose this same problem would happen with colored coins once there is more than one implementation of their API.
But one benefit of the CC protocol is that you can confirm a CC transaction is valid by Just looking at a transaction. Where as with CP you would need to look at many blocks to deduce the state.

Is this an accurate observation. ?

Thanks I’ll take a look at the tokenly swap bots. Do they work only after they have been sent coins and have one block confirm on it?

FYI… there is also an ‘Asset Vending Machine Service’ offered by CoinDaddy which allows you to sell your Counterparty or Dogeparty tokens for Bitcoin, Litecoin, Dogecoin, or any other Counterparty or Dogeparty asset.

Service Info : https://coindaddy.io/services/asset-vending-machine-service
Demo Video : https://www.youtube.com/watch?v=m5snul1tdI8

You would need to look at many blocks to indepently validate the counterparty operations in a transaction, yes. That is the job of the open-source counterparty server daemon, but you could do it with other software with much time and effort.

My understanding is that colored coin protocols also require one to trace all transactions back to a colored coin issuance transaction on the blockchain in order to verify that the specific UTXOs in a transaction are coins that have been colored.

XCP community,

I am currently involved in the implementation of digital securities (work for: newdawnx com & maltadx com). I used counterparty a few years back to experiment with digital assets (https://xchain.io/asset/VESTABYTE) and have always been a fan.

My question is, can a CP smart asset have the ability to call out to a Whitelist held with a data oracle? Something similar to transfer restrictions in CC (https://github.com/Colored-Coins/Colored-Coins-Protocol-Specification/wiki/Rules#holders).

If this works okay. I can try my hardest to push for the integration of XCP into regulated digital asset (crypto-to-fiat) exchanges such as maltadx com but also enable the DEX trading of compliant digital assets. For instance CP tokens backed by Gold (e.g. Canamex Gold instead of using ethereum could use CP). In turn this will result in a greater demand for XCP, hence benefiting the community.

Kind Regards,


Understanding how a user can credit another user with balances of a given asset is key here:

  1. A user can send any X asset to another address.
  2. A user can open orders of any X asset against another Y asset.
  3. A user can pay a dividend of any X asset to any Y asset they own (not just hold, owner of the asset).
  4. A user can exchange BTC to any other asset via a BTCPay.

These 4 actions are permissionless, so there’s currrently no way to prevent a user transferring an asset to another one.

However, there’s a process like a lot of other coins for Counterparty Improvement Proposals (CIPs).

Anyone can redact a CIP and propose a new feature, these features usually are pegged with a bounty sized relative to the CIP’s complexity and importance.

You can start a CIP to have these kind of whitelists and have someone code it, and when it gets merged and slated for maainnet activation then you can count on the feature.

Regarding data oracle, counterparty has a “Broadcast” functionality that serves a lot like data oracles (and in fact, the betting mechanism uses it). There’s also plans to eventually integrate more complex smart contracts, but that shouldn’t be relied on as it could take some time before it gets implemented and we’re planning on implementing a limited, non-turing complete vm.

Some links for your perusal:

Thanks for that. I’ll give this forum post link to our technology lead. The operation will most likely begin on Waves, however we’ll actively work to get Counterparty doing compliant security tokens as well. Cheers, Rob