Hacker News Reader

Comment by misterdata | Hacker News Reader

Well, using a blockchain for timestamping alone is pretty much worthless if it's not connected to an application. Bitcoin, Ethereum and others don't use a blockchain just for timestamping either, but store all sorts of data in it (transactions in Bitcoin and even complete programs in Ethereum).

That said, this is obviously not meant to store large amounts of data. But you could quite easily build a currency on top of this (add a 'balances' table, and use grants to determine who can update what - a future version could even provide smart contracts through SQL stored procedures).

View on HN

> Well, using a blockchain just for timestamping is pretty much worthless in practice.

Quite the opposite. Using blockchain for anything but timestamping is worthless, because there are faster and less resource-intensive protocols for about everything. Data storage, for instance, has distributed hash table, and change coordination has leader election or consensus protocols.

> Bitcoin, Ethereum and others don't use a blockchain just for timestamping either, but store all sorts of data in it (transactions in Bitcoin and even complete programs in Ethereum).

You're putting the cart before the horse. These "all sorts of data" in blockchain are in fact documents that get timestamped -- the timestamp says "document X was issued before document Y". A Bitcoin transaction in isolation from all the other transactions is nothing more than a semi-random string of bytes. For it to be a money-like thing you need to have previous transactions (and how do you know they're previous? by timestamp) that testify the account had enough resources for all the output.

Yes, so what this does is timestamp transactions (in this case SQL DML) in a decentralized way between nodes that do not or cannot trust each other. All this while enforcing write permissions ('grants') that were agreed upon earlier.

The idea that some of these transactions store data is not any different from the idea that some transactions in Bitcoin add new coins to the system, or that some transactions in Ethereum create and store contracts (which are code and data).

Now of course you could, instead of storing the actual data and/or SQL, put data in a DHT and reference and timestamp that.

> Yes, so what this does is timestamp transactions (in this case SQL DML) in a decentralized way between nodes that do not or cannot trust each other. All this while enforcing write permissions ('grants') that were agreed upon earlier.

And this should be the very first thing to put in README. This is the single most important thing about any program that uses a blockchain protocol: what exactly is the decentralized, adversity-proof timestamping used for. Right after that should be placed rationale, i.e. how does the hostility resistance help compared to cooperation-based protocols.

Why would that need to be in the README? Isn't it the whole point of blockchain?

> Isn't it the whole point of blockchain?

What "it"? Your question does not match anything I said.

I think it is actually a good idea to describe the whole point of using a blockchain as suggested. A lot of organisations I encounter don't really have a clue and do not realize that even a traditional database could fill their need perfectly in many cases.

Reply on news.ycombinator.com