I think you misunderstood what jgarzik is saying. The idea is that we store the data in a second blockchain, and put hashes of that timestamped data in Bitcoin, which hashes would also be less than 40 bytes. The reason we did not do something like that is not a matter of "intellectual laziness", but rather of implementation complexity. Counterparty is not a project in computer science; it is designed to be a simple as possible, for the benefits in development speed. Even if we have to store our data in multi-sig outputs rather than the too-small OP_RETURN outputs. Worse is definitely better in this space.
In any case, we appreciate the suggestion, jgarzik, and if you think we're still missing anything here, specifically w.r.t. the space of technical possibilities, please let us know. Thanks.
In any case, we appreciate the suggestion, jgarzik, and if you think we're still missing anything here, specifically w.r.t. the space of technical possibilities, please let us know. Thanks.
Also, with the second blockchain, you have a second blockchain to secure, and due to this, Counterparty could not fully leverage the unparalleled PoW security that Bitcoin offers end-to-end. Moreover, unless I am overlooking something here, we would still need to parse out the data from the blocks in that second blockchain (assuming it's a Bitcoin or Bitcoin derivative implementation, at least) to get our stored data. So:
* it would not enable SPV-type Counterparty clients for what Counterparty offers over Colored Coin functionality (i.e. DEx, Betting, asset callbacks, dividends, CFDs, etc)
* it would lessen security of Counterparty transactions
* it would greatly increase the complexity of the implementation (i.e. increasing the chance of bugs and vulnerabilities)
The only dubious benefit would be the *slight* lessening our storage requirements on the block chain (i.e. maybe 20-40 bytes less per transaction?). I just don't see how this would make any sense here.
One more point: Counterparty can bring immense benefits to Bitcoin, and this will especially become more apparent if/as Ethereum (and other similar non-Bitcoin-meta "2.0" type coins) enter the picture. My personal feeling here at least is that Bitcoin may very well need offerings in the ecosystem with this kind of functionality to effectively compete with Ethereum and (future) crowd's feature list and draws -- or risk becoming obsoleted, at least among investors and financial market operators, which offer the ability to bring billions and even trillions into the Bitcoin ecosystem as it gains more recognition, trust, and mindshare with them. This process is, of course, only beginning, but we feel that the clear benefits that the blockchain can offer to finance (for not only Bitcoin payment operations, but for the more advanced finance operations that the technology can enable) will set off the next great phase of Bitcoin's growth, IF allowed to unfold organically.
+1 for Common Sense
When you really think about it in a global way, storing data in a second blockchain is even more wasteful.
Imagine these two future cases:
Scenario 1: Bitcoin + Counterparty
Scenario 2: Bitcoin + BitcoinLikeSecondChain + Counterparty
Scenario #2 will always use up more data globally than #1 because we have to add in the second chain + its overheads.
Scenario #2 makes all parties (Bitcoin, BitcoindSecondChain, and Counterparty) a little less secured.
Why have Counterparty/metaprotocols running on top of a second chain when it's even simpler to integrate directly into the chain like some of the Bitcoin competitors? Why even have OP_RETURN? Why even have script if we really want to save every bit of space?
Counterparty is just tiny writings in the margins of the Bitcoin book. Reducing the margin to 40 bytes and advocating that all metaprotocols write to more books is just encouraging more wasted resources for everyone on the planet -- just so we might save up a few bytes in one book.
Allowing just enough room in OP_RETURN for a hash is like leaving enough room for Fermat to write down one last equation when that one equation could have led to another, and another in a chain of discoveries. It makes sense that a little more room for writing in the margin will make the Bitcoin book more valuable for everyone NOW before the new competitions come.
Please allow some room in the margins instead of encouraging metaprotocols to waste more trees by starting more useless books.
While I mostly agree with your points, I feel that you have made one slight oversight in your consideration. The additional "books" that you refer to needn't be full-blown cryptocurrencies. They could simply be Distributed Autonomous Organisations utilising lite-blockchains that get overwritten or heavily pruned when their balance of outputs are written to the Bitcoin blockchain every 10 minutes.
Also, in this way, Counterparty could deploy a DAO add-on for high(er)-frequency (of the order of single millisecond latency or better) trading. This could be included with Leonardo for example.
