5 ms·

There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retra

by maaku 12y ago

There are better ways to do this. You shouldn't be pushing this kind of data into an OP_RETURN output where you are burdening the entire network to store, retransmit, and validate that information from now until the heat death of the universe. No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. You can even work with your competitors on a common format and have no more than one commitment per block.

asciimo 12y ago
Or use Namecoin, which was designed to store arbitrary information. http://en.wikipedia.org/wiki/Namecoin#Uses http://en.wikipedia.org/wiki/Namecoin#Uses
gwern 12y ago
> There are better ways to do this. No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. > No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. 'Did you just tell me to go fuck myself?' 'I believe I did, Bob.'
- maaku 12y ago
  > No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.
  - gwern 12y ago
    Your reply makes no sense. It's like you didn't read anything I said in pointing out that sending to a Bitcoin address is simple, easy to understand, easy to use, and secure, while its main disadvantage is using a tiny amount of space which would require enormous increase in the use of timestamping to make any meaningful difference to full nodes.
    - maaku 12y ago
      Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. Yes the energetic and capital cost of transmitting, validating, storing, and keeping on hand a few dozen bytes is a minor thing like a speck of dust. But it is something that must -- must!! -- be done by every full node from now until the end of the universe. How many full nodes do you think there will be in the next 100 billion years? That's a lot of specks of dust. Regarding simplicity, the complexity of the underlying protocol has no bearing on that. You can just as easily write an application where you drag and drop a file, and then it does the magic of sending p2p messages to negotiate a position in the timestamp tree, and making a micropayment to pay for it. That tool could be just as easy to use.
      - gwern 12y ago
        > Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. One of the other things I learned there was not letting the perfect be the enemy of the better. > But it is something that must -- must!! -- be done by every full node from now until the end of the universe. Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. > How many full nodes do you think there will be in the next 100 billion years? A relatively small multiple of the number there have been. You seriously think humanity is going to exist for 100 billion years? > That tool could be just as easy to use. Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.
        maaku 12y ago
        > One of the other things I learned there was not letting the perfect be the enemy of the better. Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing. > Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. In a certain form I very much believe it will be, but this is probably not the right venue for that debate. > You seriously think humanity is going to exist for 100 billion years? I plan on being around (at least) that long, though that was not the question asked. > Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write. Actually I am and have: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03514.html https://www.mail-archive.com/bitcoin-development@lists.sourc...
zaroth 12y ago
The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.
- maaku 12y ago
  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 per block.
  - 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.

by maaku 12y ago

asciimo 12y ago

Or use Namecoin, which was designed to store arbitrary information. http://en.wikipedia.org/wiki/Namecoin#Uses http://en.wikipedia.org/wiki/Namecoin#Uses

gwern 12y ago

> There are better ways to do this. No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. > No, put your data into a Merkle hash tree, and do a single 32-byte commitment as frequently as you need to. 'Did you just tell me to go fuck myself?' 'I believe I did, Bob.'

maaku 12y ago
> No, there are not. What there are are ways which are slightly cheaper on a few dimensions which are irrelevant compared to the dimensions of reliability, cost, explainability, and ease of use which are totally trashed by your alternative suggestions. That has no relevance. You build a standard for these proofs, and they are passed around as blobs. It doesn't matter what their internal structure is.
- gwern 12y ago
  Your reply makes no sense. It's like you didn't read anything I said in pointing out that sending to a Bitcoin address is simple, easy to understand, easy to use, and secure, while its main disadvantage is using a tiny amount of space which would require enormous increase in the use of timestamping to make any meaningful difference to full nodes.
  - maaku 12y ago
    Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. Yes the energetic and capital cost of transmitting, validating, storing, and keeping on hand a few dozen bytes is a minor thing like a speck of dust. But it is something that must -- must!! -- be done by every full node from now until the end of the universe. How many full nodes do you think there will be in the next 100 billion years? That's a lot of specks of dust. Regarding simplicity, the complexity of the underlying protocol has no bearing on that. You can just as easily write an application where you drag and drop a file, and then it does the magic of sending p2p messages to negotiate a position in the timestamp tree, and making a micropayment to pay for it. That tool could be just as easy to use.
    - gwern 12y ago
      > Gwern, as a LW'er you should know about scope insensitivity and the danger of discounting possible futures. One of the other things I learned there was not letting the perfect be the enemy of the better. > But it is something that must -- must!! -- be done by every full node from now until the end of the universe. Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. > How many full nodes do you think there will be in the next 100 billion years? A relatively small multiple of the number there have been. You seriously think humanity is going to exist for 100 billion years? > That tool could be just as easy to use. Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write.
      - maaku 12y ago
        > One of the other things I learned there was not letting the perfect be the enemy of the better. Yes, but when the better is significantly better, and only a small marginal cost, it's worth doing. > Don't be ridiculous. Bitcoin is not going to run from now until the end of the universe. In a certain form I very much believe it will be, but this is probably not the right venue for that debate. > You seriously think humanity is going to exist for 100 billion years? I plan on being around (at least) that long, though that was not the question asked. > Yes, this hypothetical tool which does not exist, likely will not anytime soon, and which you certainly are not volunteering to write. Actually I am and have: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03514.html https://www.mail-archive.com/bitcoin-development@lists.sourc...

zaroth 12y ago

The OP_RETURN is provably unspendable, so it's technically superior to dumping data in unspent outputs. UTXO actually does have to be kept around forever, unlike OP_RETURN which can be pruned.

maaku 12y ago
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 per block.
- 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.