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.
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.