[willitpamp573]

>And yes, immutability can be achieved with traditional database systems, enforcing it with cryptography adds another layer.

You mean like... mysql with encryption and sharding? So my company's mysql database is a private blockchain?

[throwaway2016a]

> You mean like... mysql with encryption and sharding? So my company's mysql database is a private blockchain?

No. Not the same. There is more than one use case for encryption. The kind you are talking about protects unauthorized reading and writing of the data. The kind the blockchain uses protects the data from being edited and identifies who wrote the data but does not protect it from being read. Similar to PGP in email.

All data on the blockchain is readable (i.e. not encrypted in the same sense as MySQL) but it is cryptographically signed but you can ensure that:

- Only people with the appropriate private keys can perform certain actions

- Historical data cannot be edited because editing it would corrupt the entire database (after the point of the edit)

Your MySQL example has neither blocks or a chain. Encryption is not sufficient. The encryption of each committed group of transactions (block) needs to be dependent on previous blocks (chain).

[willitpamp573]

I can configure my database to require a private key be verified before data is committed to the database.

Not sure why you think blocks are important, but if you want, you can have the entries to the mysql database be batched into "blocks" and inserted all at once. Being connected to another set by hashing that data and putting it in a single record of the database (the "chain" part) is similarly trivial.

The only efficiency provided by the blockchain in your scenario is that it allows you to use blockchain terminology in marketing materials.

[throwaway2016a]

Please read what I am saying. I am replying not to argue with you but to try to spread knowledge and education on the topic. Like if replying to a Stack Overflow question. If you are not reading this because you actually want to learn more and instead trying to argue with me, please let me know so I can stop wasting my time.

It sounds like you already made up your mind that blockchain is just marketing hype without actually understanding how it works.

> I can configure my database to require a private key be verified before data is committed to the database.

Absolutely not the same. As I explicitly said in my last reply, that is not the purpose of blockchain. That is not a blockchain, that is just encryption.[1]

The thing that makes it a block chain is that the hash of the new transaction is dependent on the hash of previous transactions therefor the history of transactions is immutable. Hence the "chain" part.

That CAN actually be done with a traditional RDBs IFF:

- You store a cryptographic signature with each row.

- You completely disable DELETE and UPDATE queries.

In other words. Blockchain is much more restrictive of what can and can't be done.

But to truly be a blockchain you also need to include previous hashes in row your signature. Something that is not easy to do in distributed systems without batch committing. Hence The "block" part of blockchain.

> The only efficiency provided by the blockchain in your scenario is that it allows you to use blockchain terminology in marketing materials.

The blockchain is not designed to provide efficiency in storage. That's not it's use case. In fact it is incredibly inefficient at that. The blockchain is designed to allow a party to be able to trust the data at a specific point of time without having to rely on absolute trust of the party sending the data and without having to pre-share keys.

It does no know who the person at the other side of a transaction is, it only knows that the transaction is allowable (or not).

The type of encryption you describe relies on both parties being known to each other and having shared secrets.

I have more I could say but books can be (and have been) written about this.

[1] Also I really hope it's not verifying the private key... private keys should never be sent to the server. They can be verified independently using signed data and a public key.