Quote from: jtimon on March 31, 2014, 05:57:53 PM

Quote from: Peter Todd on March 30, 2014, 03:33:53 PM

Short answer: you're assuming the data exists to validate at all client-side. Unfortunately that's not something you can assume. If you're just putting hashes of Counterparty data in the blockchain what is a client supposed to do if they can't find the corresponding data? If they assume it doesn't exist then you can be sybil attacked by someone who later reveals the data and changes the consensus out from under you. On the other hand, if you assume it must exist, and wait until you find that data, a trivial attack is to put fake hashes of alleged counterparty data in the blockchain.

You wouldn't have to solve any problem if your chain validated your transactions. You wouldn't need to bloat your chain with open orders like mastercoin and counterparty (if I understand correctly) do.
Colored coins don't put the open orders in the chain, but not all colored aspects of a colored coins transactions are validated.
If your chain validated all you need it to validate, you could even have SPV clients consuming a committed UTXO (something non-hardfork colored coins cannot give you).

I don't know mastercoin and counterparty deeply but I believe they use "accounts" (like ripple.com) instead of inputs/outputs (like bitcoin and freimarkets), which is another design mistake.

Too many efficiency sacrifices only to avoid bootstrapping your own chain like namecoin did when it wanted to support additional features.
If we all bitcoin users want to support these features in the bitcoin chain, there's a better way to do it: a hard fork.
I'm all for this features (asset issuance, p2p trade, ripple-like transitive trades, options, etc) in Bitcoin's main chain myself, but the right way.

You've also failed to read deeply into this thread. Reposting service: free, tips - welcome.

Quote from: xnova on March 21, 2014, 04:03:05 PM

The blockchain itself would be most benefited by the use of OP_RETURN here, but it seems to me at least that there is a disconnect in the logic of why the size was halved among some, pointing to theoretical reasons as justification on why that would be a good idea instead of the *actual real world current uses*. While the optimal solution in your mind for Counterparty and others may be to move to their own side chains and store hashes in the Bitcoin blockchain using OP_RETURN, you have to understand that doing so is highly complex, rife with potential security issues, and that the only evidence supporting this is (as far as I know) essentially a theoretical-type thread on the Bitcoin developers mailing list. This would be a bit like me telling the Bitcoin devs that Bitcoin should move to using GHOST (https://eprint.iacr.org/2013/881.pdf) immediately as it's technically the optimal solution over the longer block times today. While the latter could be argued to be the case, it is a proposal that has not been fully vetted in the real world, and would introduce major protocol-level changes that could cause potential security and usability problems.

LightedLamp

Posts

Merits