Few (I didn't say none) of those arguments pass the smell test.
- OP_RETURN and 40 vs 80 bytes: If the miners agree with you, you don't have to care what the network relays. Has Counterparty directly approached miners, to get them to mine 80-byte OP_RETURN transactions? What was the response? If the miners agree, great, let's do it. If the miners don't agree, there is no point supporting it in Bitcoin Core software.
- "core devs are censoring and killing innovation!" Counterparty is very clearly misusing a feature intended for ECDSA public keys, in a manner that very clearly results in harm to the overall network, short and long term. Other people/companies/projects are extending the bitcoin protocol and not meeting the same resistance.
- To repeat earlier posts, my criticism is not about counterparty in general, just this ONE CheckMultiSig flaw. Fix that, and my criticism is gone.
- As Peter Todd has noted, CheckMultiSig has other problems also. It may go away regardless.
Please do not paint all Counterparty criticism with a broad brush. My opinions are my own, and in particular I do not agree with all of Luke-Jr's points or point of view.
There are plenty of ways to innovate and extend the bitcoin protocol. People are doing this every day.
It is
always a mistake to base an entire engineering system on a subtle technical quirk that "just happens to work." Counterparty is stuffing its own data where ECDSA public key data is supposed to go. That is clearly not the intended use.
I think from a strategic level one must ask why are some projects unable to communicate intention and influence development, rather than getting into tactical details such as this.
It is quite clear to everyone that p2p systems can be used for all sorts of transactions that make up contracts. If the inability to communicate and resolve needs is causing friction one must ask how the overall system should evolve to mitigate long term harm, while maximizing long term capabilities depth of the network.