I mean, technically SSA data might be a legitimate use of the blockchain. I am one of the biggest opponents of the whole mess, but there are use cases for a persistent immutable data record, and social security numbers would be one of them.

[–] Vanilla_PuddinFudge@infosec.pub 33 points 4 days ago (1 children)

The not-bullshit version of this already exists.

Many know it as MySQL, Postgres, etc.

Databases don't need Blockchains.

[–] dreadbeef@lemmy.dbzer0.com 1 points 3 days ago* (last edited 3 days ago) (3 children)

Damn why doesn't git just use sql instead of Merkle trees I guess that's just stupid tell Linus to get to using SQLite asap!!!

But no, you're wrong. Cryptographically verifiable merkle trees are a valuable way to store changing data. Unlike your recommendations, they don't satisfy the needs of verification, which is literally a great use-case for ssns. Now I'll admit that the SSN db doesn't need to be distributed, which is the only thing a blockchain adds to that equation. But you are just flat out wrong for suggesting a sql db 😂

[–] senkora@lemmy.zip 7 points 3 days ago* (last edited 3 days ago)

You can store the Merkle trees inside of a SQLite database as extra columns attached to the data.

That way you get the benefits of a high-level query language and a robust storage layer as well as the cryptographic verification.

In fact, there is a version control system called Fossil which does exactly that:

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage adirected acyclic graph (DAG) of Merkle tree structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via the parent's hash.

The difference is that Git stores its objects as individual files in the .git folder or compressed into bespoke key/value pack-files, whereas Fossil stores its objects in a SQLite database file which provides ACID transactions and a high-level query language. This difference is more than an implementation detail. It has important practical consequences.

[…]

The SQL query capabilities of Fossil make it easier to track the changes for one particular file within a project. For example, you can easily find the complete edit history of this one document, or even the same history color-coded by committer, Both questions are simple SQL query in Fossil, with procedural code only being used to format the result for display. The same result could be obtained from Git, but because the data is in a key/value store, much more procedural code has to be written to walk the data and compute the result. And since that is a lot more work, the question is seldom asked.

[–] enumerator4829@sh.itjust.works 5 points 3 days ago

Or you know, trusted timestamps and cryptographic signatures via normal PKI. A Merkle tree isn’t worth shit legally if you can’t verify it against a trust outside of the tree.

All of the blockchain bullshit miss that part - you can create a cryptographic representation of money or contracts, but you can’t actually enforce, verify or trust anything in the real world without intermediaries. On the other hand, I can trust a certificate from a CA because there are verifiable actual real-world consequences for someone if that CA breaks legal agreements.

I’ll use a folder of actual papers, signed using a pen. Have some witnesses, make sure they have a legal stake and consequences, and you are golden.

[–] tyler@programming.dev 1 points 2 days ago

Blockchain is three things, not just a merkle tree.

Distributed
Cryptographically signed
Distrust of all others on the chain.

Git isn’t a blockchain. Blockchain requires mistrust, else it’s just previous technology that existed decades before.

[–] enumerator4829@sh.itjust.works 6 points 3 days ago (1 children)

Distributed blockchains are useful when all of the below are fulfilled:

Need for distributed ledger
Peers are adversarial w.r.t. contents of transactions in the ledger
Enough peers exist so that no group can become a majority and thus assume control
No trusted central authority exists

Here, we have a single peer creating entries in a ledger. We can get away with a copy of the ledger and one or more trusted timestamping authorities.

[–] Adalast@lemmy.world 1 points 1 day ago (1 children)

I didn't say distributed. You are absolutely correct though. I was more observing that of all the BS tech bro babble that our Oligarch in Chief could spew into the universe, blockchain would be one that could be implemented reasonably.

[–] enumerator4829@sh.itjust.works 2 points 22 hours ago (1 children)

If your blockchain isn’t distributed, it doesn’t need to be a blockchain, because then you already have trust established.

[–] Adalast@lemmy.world 1 points 21 hours ago (1 children)

There are actually other comments on this thread that provide other benefits besides trust, like modification tracing. There is more to it than just trust.

[–] enumerator4829@sh.itjust.works 1 points 18 hours ago

You mean a transparency log? Just sign and publish. Or if it’s confidential, have a timestamp authority sign it, but what’s the point of a confidential blockchain? Sure, we han have a string of hashes chained together á la git, but that’s just an implementation detail. Where does the trust come from, who does the audit? That’s the interesting part.

[–] andioop@programming.dev 9 points 3 days ago

My heart breaks for cool ideas that got taken by scammers and are now forever associated with financial predators and will probably never see legitimate use.

[–] T156@lemmy.world 11 points 4 days ago (1 children)

Except that the numbers are also prone to change, like if it's been stolen. They're technically not supposed to be an identification code anyhow.

[–] Tempy@programming.dev 3 points 4 days ago* (last edited 4 days ago)

Right, but you can have entries in a block chain that indicate previous entries are no longer valid, or have modifications. Calculating a final state by walking through all the blocks in the chain. ( A bit like a CQRS based system can have a particular state at a point in time by replaying all events up to that point)

Doing it in such a way also makes auditing what's happened much easier since changes are inherently reflected in the chain. You want to know when (or by who if you keep that information) a record changes, it's right their in the chain.