I don't think "built on Bitcoin" is the central idea. "Counterparty protocol" is the central idea.
We can have many choices besides bitcoin.
There are many people out there building Counterparty-like systems, many with their own blockchains. It's an obvious next step for crypto-currencies. Obviously it's the central "idea" of Counterparty in some sense. Maybe I should have said that it was the central "insight" of Counterparty to be built on Bitcoin.
Except... it's not built on bitcoin. That's exactly the gripe of myself, jtimon, and others I'm sure. Counterparty does not interoperate with bitcoin scripting. You cannot have bidirectional transactions between the two. Counterparty rules are not validated by bitcoin nodes. Lightweight clients can't rely on most-work as an indicator of validity. Counterparty is built separate from bitcoin. If I take a bible and start scribbling in the margins, do I get to go on a pulpit and claim a biblical foundation for my scribbled theories? No, it has no relevance.
Counterparty transactions are scribbled in the margins of validated bitcoin transactional data. So what? Bitcoin does gain from this. Counteryparty doesn't gain from this, any more than they would from a fully merged-mined datachain or any other equivalently powerful proof-of-publication sytem. And Counterparty could be doing much better by having miners which validate its transactional data.
Well, we're disagreeing about the meaning of "on bitcoin" here; obviously you're right in one sense, and I'm right in another sense. Counterparty was designed to work within the known existing constraints of Bitcoin, without requiring any change to Bitcoin itself. Getting Counterparty transactions to be verified by miners would require tons of work, and it would be fraught with danger of screwing something up in the basics of Bitcoin itself. However, by doing it this way, if there is something wrong with Counterparty, the larger Bitcoin ecosystem will not be affected at all. Miners still mine, nodes still nodulate, nobody has to download a new client version or anything.
There's a sort of partitioning of dangers and responsibilities which I think makes the overall system more robust. It's kind of like encapsulation in programming: you work on your functions, and make sure that they work; and I'll work on my functions, and make sure that they work; and my functions don't have to know about the inner workings of your functions, and vice-versa. It results in an efficient division of labor, where the Counterparty devs don't have to get involved with Bitcoin development, and Bitcoin devs don't have to get involved with Counterparty development.
In theory, at least. Obviously the current problems are the result of this NOT happening. Bitcoin changed a spec at the last minute, and Counterparty had to adapt in a way that the Bitcoin devs didn't like. Makes me wonder what would have happened if this had simply been kept quiet by the Counterparty devs. If they had just quietly resorted to using multisig (that is what they're using now, right? It's hard to keep up) instead of OP_RETURN, without the furor on this forum, would the Bitcoin devs ever have noticed Counterparty?