To date, I've not seen a blockchain data dumping scheme that could not be securely replaced with a simple hash.
You don't need to store
data in the blockchain. That is purely intellectual laziness. Timestamping hash(data) is just as secure, while more efficient.
Furthermore, a secondary chain can be provably pegged to bitcoin:
http://sourceforge.net/p/bitcoin/mailman/message/32108143/Greetings Jeff. Thank you for stopping by. I was chatting with Eric and Stephen tonight at Bitpay's new offices about this topic and we had agreed to share an email to explore further, but you beat me to it.
You're absolutely right.
You don't need to store
data in the blockchain.
Timestamping hash(data) is just as secure, while more efficient.
A secondary chain can be provably pegged to bitcoin.
However, Counterparty IS storing data in the blockchain using 256 bytes in each one-of-three multi-sig transactions, as per PhantomPhreak's note below. Additionally, all these multisig transactions are processed by the miners.
On the plus side, we can fit a lot more than 80 bytes into 256 one-of-three multi-sig outputs, and now we have no incentive to use less than that except lower fees.
If OP_RETURN was meant to stop/curtail the multisig behavior (Unspent Outputs) and hereby reduce blockchain bloat, then I fear by reducing the size of OP_RETURN from 80 to 40 bytes, you've inadvertently made multisig
MORE ATTRACTIVE to all the metaprotocols and you've made OP_RETURN less attractive. The cost of paying the miners fees has not reduced the ability to survive with multisig.
The technical details are well beyond my abilities, but PhantomPhreak's assertion that the economics of time/effort of squeezing into 40bytes should be noted. Here are Phantom's words:
It would take some serious shoe-horning to fit all of the data we need into 40 bytes reliably, and in three months they could lower it to 35 bytes (again, for no reason) and then we'd be screwed.
We (All the metaprotocols) WANT to use OP_RETURN as it is in everyone's interests to do so, but if you hobble the feature's functionality such that the costs to use OP_RETURN are too high to consider, then markets will find other, less costly alternatives to achieve its goals.
We have a mutual interest in reducing blockchain bloat. Is there any reason why 80 bytes will reduce both our abilities to reach that shared objective and is there any reason 40 bytes will make it easier?
Best,
BTT
EDIT & NOTE: Jeff, we're totally okay to take this conversation to the bitcoin core dev mailing list if that's a more appropriate location for this discussion. I will cross-post my follow-up here on the bitcoin core dev mailing list as a new topic.
Thanks!
BTT
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
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.