Post
Topic
Board Announcements (Altcoins)
Re: [ANN][XCP] Counterparty Protocol, Client and Coin (built on Bitcoin) - Official
by
PhantomPhreak
on 22/03/2014, 15:09:47 UTC
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.

It's not enough to have a couple of pools mine our transactions. We need to keep the block time as close to ten minutes as possible.

There are myriad ways of imbedding data in the Bitcoin blockchain. We support two already. We based the architecture of Counterparty on that.

Again, Counterparty was originally designed to use OP_RETURN exclusively, which is obviously the technically superior option. You're 'killing innovation' by supporting arbitrary, very low limits on the amount of data that can be stored in the blockchain properly---i.e. with OP_RETURN. If the limit on the size of OP_RETURN is raised back to 80 bytes, then we'll have no need to use CheckMultiSig outputs the way we are doing now.