| 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. |