4 ms·

The issue isn't OP_RETURN, it's one vs many OP_RETURN outputs per block, and stuffing data in the block chain vs compressing it via hash functions to 32-bytes p

• zaroth 12y ago
  If everyone is supposed to share one OP_RETURN, either you're building the tree by consensus or centralized control? It would be an interesting feature to collect the OP_RETURN's into a merkle tree as part of a consensus protocol. But one question immediately comes to mind... Publishing the root node is useless, unless you know where your node is located in the tree, and all the sibling nodes all the way up to the root. You know, so that you can actually prove your node was part of the tree. Just having the root is not enough. Where is the full tree being built, stored, how is it shared, how do I get a copy of it, so that I can find my node in it? If the tree is built from collective inputs, what are the anti-DDoS mechanisms? Etc... Peers would need to share this data structure for some amount of time after the block is published (not indefinitely). Anyone who thinks their hash is part of certain block's tree would need to retrieve the full tree for that block, and if they find their node in the tree, keep their own record of the log(n) hashes required to get from their node to root. It's a big trade-off to impose this external data storage requirement! All these questions / complexity, and what is the actual benefit? Again, these are prune-able OP_RETURN outputs so they don't pollute UTXO in the first place. The relay fee is more than enough to cover the cost of < 100 bytes that never hit UTXO.
  • maaku 12y ago
    The relay fee doesn't go to the people who are actually burdened with maintaining the historical block stream. It is a fully externalized cost.