Hacker News Reader

Comment by kang | Hacker News Reader

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.

View on HN

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.

Until all of your data gets pruned from the blockchain in an update...

Well, that is also fair game...

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.

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.

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.

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.

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.

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.

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!"

Doesn't that defeat the whole point of it?

Reply on news.ycombinator.com