4 ms·

This is like finding unused bytes in TCP headers and using them to store data for messaging. This is not what the bitcoin's blockchain is designed for and if yo

by kang 11y ago

This is like finding unused bytes in TCP headers and using them to store data for messaging. This is not what the bitcoin's blockchain is designed for and if you want your data to persist across everyone's computer use something specifically designed for it like, say filecoin or ipfs, but please do not store data on the bitcoin's blockchain and burden everyone.

Tinyyy 11y ago
Doesn't that defeat the whole point of it?
williamcotton 11y ago
Yup, totally! The second paragraph of the README states: This protocol is intended for use while developing OP_RETURN based protocols. Mature protocols should switch to a custom OP_RETURN method that uses as few transactions as possible to store data. We're using Blockcast underneath Open Publish... we needed more than just the 80 bytes in a single OP_RETURN because we needed a few different content-addressable keys. We use a combination of IPFS, BitTorrent InfoHash, SHA-1, as well as a URI to where the ACTUAL content is posted. Open Publish is also a digital asset protocol so it very much benefits from the "colored coin" properties of the Bitcoin blockchain. But yes, content itself should be stored and distributed using IPFS, BitTorrent, or HTTP, it only makes sense to use the Bitcoin blockchain for things related to payments and ownership, like with the Open Publish protocol.
- josu 11y ago
  And also: What about polluting the blockchain? We will move this protocol to a Bitcoin sidechain designed specifically for public data as soon as the technology for building sidechains becomes available. In the meantime we've been using this protocol while prototyping other protocols that rely on storing metadata in the Bitcoin blockchain. Woodsy Owl says "Give a Hoot! Don't Pollute!"
suprfsat 11y ago
Maybe you should regulate the problem away.
zekevermillion 11y ago
Bitcoin is permissionless. Whether you, or Gavin, or Nick Szabo, thinks it should be used for a particular application is not relevant, if it in fact works for that application. Maybe your use of bitcoin as a value transfer protocol is burdening me by driving up the costs of storing objects for multiplayer games! Altcoins are often not suitable because there is not a well-maintained software implementation of the protocol for a particular alt, or because there is insufficient mining on that chain to foster adequate security. As it becomes more expensive to send tx on bitcoin, of course, there are opportunities for alts to fill certain niches. Just as there are opportunities for people to find ways like sidechains, or other hacks, to get more out of bitcoin itself.
- ryanlol 11y ago
  Until all of your data gets pruned from the blockchain in an update...
  - zekevermillion 11y ago
    Well, that is also fair game...
  - adrianmacneil 11y ago
    Pruning is/will be a client feature, so your data would never be pruned out of existence, it's simply up to clients whether or not they want to keep it around.
    - ryanlol 11y ago
      What's not a client feature? It'll be pretty annoying when you've only got a couple of custom clients hosting your version of the 10TB blockchain.
      - adrianmacneil 11y ago
        Well, you can't prune the blockchain until you have fully downloaded and verified it anyway. So if no clients are hosting the full, complete blockchain then you won't be able to sync at all, which will be bad for everyone. You could theoretically get around this by starting sync from a known (hard coded) recent block + UXTO set, but at that point you are losing _all_ transaction history, not just your OP_RETURNs. So, I don't think OP_RETURN data added to the blockchain today will be going anywhere fast.
arihant 11y ago
That's shortsighted. Sometimes such practices eliminate the need for additional protocols for related tasks. Maybe instruction slips could be passed on here? This kind of approach can be very helpful in the wild. For delivery of SMS, for example.
- ryanlol 11y ago
  How so? Blockchains would probably be the worst possible way to deliver SMS from a resource consumption point of view... And from a security POV it'd just be silly.

by kang 11y ago

Tinyyy 11y ago

Doesn't that defeat the whole point of it?

williamcotton 11y ago

Yup, totally! The second paragraph of the README states: This protocol is intended for use while developing OP_RETURN based protocols. Mature protocols should switch to a custom OP_RETURN method that uses as few transactions as possible to store data. We're using Blockcast underneath Open Publish... we needed more than just the 80 bytes in a single OP_RETURN because we needed a few different content-addressable keys. We use a combination of IPFS, BitTorrent InfoHash, SHA-1, as well as a URI to where the ACTUAL content is posted. Open Publish is also a digital asset protocol so it very much benefits from the "colored coin" properties of the Bitcoin blockchain. But yes, content itself should be stored and distributed using IPFS, BitTorrent, or HTTP, it only makes sense to use the Bitcoin blockchain for things related to payments and ownership, like with the Open Publish protocol.

josu 11y ago
And also: What about polluting the blockchain? We will move this protocol to a Bitcoin sidechain designed specifically for public data as soon as the technology for building sidechains becomes available. In the meantime we've been using this protocol while prototyping other protocols that rely on storing metadata in the Bitcoin blockchain. Woodsy Owl says "Give a Hoot! Don't Pollute!"

suprfsat 11y ago

Maybe you should regulate the problem away.

zekevermillion 11y ago

Bitcoin is permissionless. Whether you, or Gavin, or Nick Szabo, thinks it should be used for a particular application is not relevant, if it in fact works for that application. Maybe your use of bitcoin as a value transfer protocol is burdening me by driving up the costs of storing objects for multiplayer games! Altcoins are often not suitable because there is not a well-maintained software implementation of the protocol for a particular alt, or because there is insufficient mining on that chain to foster adequate security. As it becomes more expensive to send tx on bitcoin, of course, there are opportunities for alts to fill certain niches. Just as there are opportunities for people to find ways like sidechains, or other hacks, to get more out of bitcoin itself.

ryanlol 11y ago
Until all of your data gets pruned from the blockchain in an update...
- zekevermillion 11y ago
  Well, that is also fair game...
- adrianmacneil 11y ago
  Pruning is/will be a client feature, so your data would never be pruned out of existence, it's simply up to clients whether or not they want to keep it around.
  - ryanlol 11y ago
    What's not a client feature? It'll be pretty annoying when you've only got a couple of custom clients hosting your version of the 10TB blockchain.
    - adrianmacneil 11y ago
      Well, you can't prune the blockchain until you have fully downloaded and verified it anyway. So if no clients are hosting the full, complete blockchain then you won't be able to sync at all, which will be bad for everyone. You could theoretically get around this by starting sync from a known (hard coded) recent block + UXTO set, but at that point you are losing _all_ transaction history, not just your OP_RETURNs. So, I don't think OP_RETURN data added to the blockchain today will be going anywhere fast.

arihant 11y ago

That's shortsighted. Sometimes such practices eliminate the need for additional protocols for related tasks. Maybe instruction slips could be passed on here? This kind of approach can be very helpful in the wild. For delivery of SMS, for example.

ryanlol 11y ago
How so? Blockchains would probably be the worst possible way to deliver SMS from a resource consumption point of view... And from a security POV it'd just be silly.