5 ms·
http://doyouneedablockchain.com/ http://doyouneedablockchain.com/
by shiado 9y ago
http://doyouneedablockchain.com/ http://doyouneedablockchain.com/
- prepend 9y agoNormally I like this flowchart, but the permanent record is useful even within trusted parties. There aren’t many (any?) distributed databases with permanence built-in. So getting that for free is nice to not have to build yourself. Especially self-hosted. If this allowed self hosted, it would be cool. Paying them seems not very useful.
- endymi0n 9y agoOMG, looks like „permanence“ is now to blockchainers what „web scale“ was to MongoDB fanboys. Now if you were so kind to explain to me what about modern, distributed databases isn‘t „permanent“? Permanence is the very definition of a database‘s job. If you really want to make extra sure it‘s permanent, give write-only permissions to the DB user, make backups and if you want to allow mutations, enable change data capture. Now if there only was a way to short blockchain technology as a financial asset...
- prepend 9y agoWhat I mean by permanence is that you can’t delete. Databases typically allow delete and mod and this is a big problem for me. What is a more accurate term? I always used persist for writing to disk, like databases do. With the “workaround” you describe, although a big pain in the ass for lots of nodes, still doesn’t work. How do you know that someone’s backup is correct? Or how do you verify that a remote node didn’t write/delete/sync? There’s many situations that make your idea fail that a blockchain would work. Although, I agree that lots of “blockchain” solutions just need a decent distributed cache since you don’t care much about integrity.
- MichaelGG 9y agoOf course you can delete, just create a new DB and insert the records except the ones you don't want. If you want to have integrity control, you can use digital signatures without blockchain. If all you're trying to fix is making it hard to issue a DELETE statement, then make it easier to set permissions. Which isn't really hard in any mainstream database... It seems like this is a log, which might work better, although existing RDBMS already have high performance versioning/change tracking.
- prepend 9y agoYou can only delete up to the last point you synchronized. So once your record gets onto any other node, then it becomes harder and harder with more nodes to delete or change. Regardless of root/permissions/whatever. Of course you can use signatures as you basically start recreating blockchain at that point (eg, each transaction is signed and linked to the previous; then connected with other nodes doing the same thing. A change to any segment would be detectable, etc etc). Basically, it is just a distributed log that removes any change for changing data and the inability to set any permissions to remove data. Maybe I’m being dense, but please let me know of any mainstream databases that give this functionality without relying on permissions to insure integrity. If an admin is able to change data, then that won’t work in my use case.
- MichaelGG 9y agoDefine "synchronized". If you already have a way for nodes to determine something was valid as of a certain set of data and time, you've already solved it.
- emmelaich 9y agoI guess it means no undetectable delete. Like Git. You can copy it, filter-branch it. But if something is deleted the hash will be different.
- progval 9y ago> There aren’t many (any?) distributed databases with permanence built-in. Git.
- prepend 9y agoGit allows for rebasing. And that’s what I’m currently using with a bunch of code to provide record/db functionality. It’s a pain and would be nice to have software that is designed for this purpose. Also, git is a blockchain.
- emmelaich 9y agoBut end users can detect rebasing. (of published trees)