You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).

I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.

Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

The Twitter spambots which have historically posted positive news on Mastercoin (as well as many other projects, to be fair), are now posting links to bellebite2014 posts to disparage Counterparty: https://www.dropbox.com/s/3qxtbed5dggmwqd/Screenshot%202014-03-30%2015.09.35.png

A sample of the Mastercoin posts these accounts make: https://www.dropbox.com/s/pw89c9dyozvx1dj/Screenshot%202014-03-30%2015.24.41.png

I don't know who is in charge of these accounts or what they are hoping to accomplish, but linking to the biggest troll in this thread as a source of Counterparty news is hilarious.

there is a company which (cant remember name atm) sells bitcoin cards....but it doesnt have the private key on it. u redeem it on their website and they send the funds. this could solve the problem but u now have to trust a third party.

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

Based on a quick readover of https://github.com/PhantomPhreak/Counterparty, it looks like Counterparty wants to be Freimarkets, except Counterparty is built on top of bitcoin bad practices (eg, key reuse, "from addresses", etc) and a not-properly-softforked P2SH-like use of the blockchain's Script, rather than a merged-mined side-chain like this kind of thing should be...

No, it is trivial to block 100% of them.  A proposal to do just that appeared on the bitcoin-development mailing list yesterday from Peter Todd.  This proposed change would relay zero transactions with multisig outputs.

Most of the world is moving to P2SH for multisig, leaving the remaining "bare multisig" users mastercoin, counterparty, etc.

The miners have that duty.

These are the same question.

Too many people were getting the impression that OP_RETURN was a feature, meant to be used. It was never intended as such, only a way to "leave the windows unlocked so we don't need to replace the glass when someone breaks in". That is, to reduce the damage caused by people abusing Bitcoin.

Not exactly. Miners certainly have the ability to decide which transactions they do and don't include, but they have a duty to use that ability to protect the system from abuses. 

And no, "don't abuse us with OP_RETURN" does not mean we are forcing you to abuse us in other ways.
If we lock the windows, we aren't forcing the burglar to break them. Stop trying to blame the victim.

Translation: no need to be an a$$, or how to be a noob who is ignored.

if you are running it on your server for your web site to handle lots of money, you should be able to compile it yourself. If you can't, the incompetent one isn't the project. Mt Gox and others have half-a$$ed it too.

If you are joe user, there are lots of wallets that are available and no need for this. 

To date, I've not seen a blockchain data dumping scheme that could not be securely replaced with a simple hash.

You don't need to store data in the blockchain.  That is purely intellectual laziness.  Timestamping hash(data) is just as secure, while more efficient.

Furthermore, a secondary chain can be provably pegged to bitcoin: http://sourceforge.net/p/bitcoin/mailman/message/32108143/

Who cares?

Hi Jahpowerbit, When I try to install the BoottleXCP for windows 7, I get the error "No Module named apsw". I am following the steps in http://www.reddit.com/r/xcp/comments/1zzhyg/.

Any help?

If you research a bit more, you will find Counterparty has not copied Mastercoin. Instead, Counterparty has created a project in the *same space* using a *different* approach. If Counterparty simply copied Mastercoin, why did Counterparty's development surpass that of Mastercoin's with a team of two core developers and no external funding in only half the time?

Bitcoin Tangible Trust, if you want to issue an asset for a fully-redeemable silver coin that costs you, say, $20 to buy and put into custody?  How does a 5 XCP asset issuance fee effect the end price that you need to charge a customer to buy this silver coin?  

EDIT:  OK, I just did the math.  5 XCP = $32 @ 0.01 BTC/XCP and $640 BTC/USD.  So, basically at 5 XCP issuance fee you would need to charge $52 for a silver coin that otherwise could be purchased from a coin dealer for $20.  So, yes, from my basic analysis, this seems like a blockage, at least for BTT's business model anyways.

EDIT: Porqupine, maybe you see / understand something that I am missing?  Can you please elaborate?  Interested to better understand your perspective, as you always have such good postings on this list.

No, only for the software that they use to store thousands of dollars with.

Use "Git clone http://github.com/...the rest..."

Then make it.

Then run it.