“Ethereum will ultimately (March 2015 release scheduled) be more general, elegant and powerful. Ethereum, when released, will be 100% feature-free. Instead of providing a handful of hard-coded features, Ethereum is a decentralized application programming, deployment and utilization platform which will enable developers to build any ‘features’ they can conceive of.”
Lubin quoted Ethereum CCO, Stephan Tual, who said:
“It went from ‘ethereum is not possible’ to ‘sidechains will kill ethereum’ to ‘we copied ethereum.'”
Lubin’s post lists six possible weaknesses of the Counterparty approach. CCN reached out to Counterparty’s co-founder Adam Krellenstein for replies and thoughts.
It seems that there are a number of misunderstandings about Counterparty and its new contracts system in that post (which, for example, I know that Vitalik doesn’t have).
For instance, it says “Instead of providing a handful of hard-coded features, Ethereum is a decentralized application programming, deployment and utilization platform which will enable developers to build any “features” they can conceive of.” But that’s exactly what we can now do! Same with “We are building Ethereum so we and the world of decentralized app developers can develop DApp services orders of magnitude faster than would be possible on the Bitcoin protocol.” That, too, applies now equally well to Counterparty as it does to Ethereum.
In response to this comment “In summation, this is a marketing event. Nobody who is informed could possibly consider this announcement viable.”, all I can say is that a number of very well-informed Bitcoin developers have lauded this announcement as a major step forward for Bitcoin and for cryptocurrencies. See, e.g., these two tweets by Bitcoin Core devs:
The other comments are largely straw man arguments:
“How will they accomplish decentralized storage of contracts, data? – There is no way to do this in Bitcoin, except in an auxiliary centralized data store. And then you are prone to manipulations of the code and/data.”
There are a number ways to store contracts directly in Bitcoin (in a prunable manner), and we’ve been using them successfully for 11 months now. We will absolutely not use a centralized data store.
“The BTC core devs, already annoyed with Bitcoin 2.0 projects that bloat their blockchain, are going to dislike Counterparty even more, and might make things difficult in the future for them.”
I think the best response to this comment is to point to the above two tweets. ;)
Similarly, his comments about block times and miner centralization are really about plans that Ethereum has to solve major problems in computer science with very risky and unproven technology that’s completely independent of the contract system in question. By contrast, everything that Counterparty does builds on a firm foundation, because we’re interested in building real, usable applications as quickly and securely as possible.
Can your development be considered as a fork of Ethereum?
It’s not actually a ‘fork’, but rather a ‘port’ of their programming language and code execution environment. We have our own code which implements the same processes on a different platform (namely Counterparty and Bitcoin, instead of the Ethereum blockchain).
So now you have stolen the programmable Turing-Complete fire from the Ethereum ;-) Could another Prometheus do the same to you? In particular, there have been suggestions (including mine on the Counterparty forums) that all the features of Counterparty could be reimplemented in a sidechain, which would permit operating in Bitcoin without extra layers. Thoughts?
Counterparty is able to advance as quickly as it does above all because of its place as a layer on top of Bitcoin; because we’re not building our own blockchain, which is both very difficult and very slow (and evidently entirely unnecessary). Moreover, the only other system that has a similar architecture to ours is colored coins, but their protocol(s) are incapable of adding such complex features as this (if nothing else because you need a separate currency to handle the execution fees).
This point is not commonly understood (despite its importance), but the ability of sidechains to develop new features is no greater than the ability of *any other* alt coin to do so. The sole innovation of sidechains in the two-way BTC peg to the main Bitcoin blockchain, but the existence of that peg will only make it *more* difficult to add new features, because now you have to maintain compatibility with Bitcoin. (This all goes without saying that sidechains are highly theoretical and necessarily have very poor security properties, because of their fundamental architecture.)
I don’t see why “[sidechains] necessarily have very poor security properties because of their fundamental architecture.” The only fixed part of a sidechain‘s architecture is the hooks into the 2way pegging gears that will be implemented in Bitcoin core, so it seems to me that any security enhancements could be implemented within the sidechain and without other compatibility constraints (like you use a library without worrying of the internals but only of the interfaces).
As a rule, the security of a consensus protocol isn’t achieved by the addition of new features or enhancements, but rather by the economic incentives that exist to encourage its participants to come to consensus. The pegging to an external currency largely eliminates those incentives.
A sidechain is a blockchain just like any altcoin’s, but without any block reward and therefore with very little reason for miners to mine it. So either the sidechain is much smaller than Bitcoin’s, and much less secure, or the sidechain is merge-mined and Bitcoin miners may attack it for free (and steal the bitcoins it holds).
In addition, sidechains promote miner centralization by raising the overhead cost associated with mining. These two pieces have some more details:
What do you think of the Ethereum cloning saga? Do you agree with Lubin, or with Krellenstein? Comment below!
Images from Counterparty, Ethereum and Shutterstock.