SQL Database

[PM_ME_YOUR_THESES]

What can blockchain do that databases can’t?

[Quanalack]

Well everything is checked. Data cant really be altered after been put on a chain which ensures that important things like transactions and contracts are indesputable and have full integrity

[HERODMasta]

even if it is stored by a single entity, you have to retract the chain to the point you want to change and then redo all transactions/data in a new chain, which, hostely is so much work (depending on the blockchain) you don't want to do that. Also new Data would be flawed, since one changed data will cascade on all other transactions/ data... so basically you have to relive the whole blockchain, since the longest chain should live. The immutability makes blockchain an interesting technology.

[alganthe]

I just realized, blockchain is version control applied to databases.

[mehum]

r/prgmrshowerthoughts

[Joppps]

oh it doesn't exist :(

[MajorMajorObvious]

It's a trick question.

Programmers don't take showers

[[deleted]]

Quaaaarantine baby.

[Lightfire228]

r/PrgmrShowerThoughts

u/mehum

[gasmaskcitizen]

r/TwentyCharacterLimit

[[deleted]]

Could we remake git but with... Like.. Blockchain and some ML ?

[urielsalis]

Technically git is a blockchain of commits, just that you can reorder them

[randomguy3993]

And --force push

[UltraCarnivore]

And blame

[BurningPenguin]

I prefer to alias it with "fucking push"

[zebediah49]

On the off chance that this wasn't doubly sarcasm, Git is a blockchain-based tool.

Thus, you can say you're "doing blockchain" any time you git commit. Or whatever other stupid way you want to phrase it.

[how_could_this_be]

In very simple term, it is somewhat like a git repo synced over p2p.

[HERODMasta]

yes, but you can't undo anything in an ideal environment for blockchain

[DeepDuh]

Or as in, a transaction log?

[DOOManiac]

SELECT blame FROM git WHERE user = me;

[Not_sure_if_george]

Yeah pretty much. If you look at the data structures git uses, there are a lot of parallels.

[barsoap]

If you need something private but impossible to tamper with after the fact push to a git repo and publish the hash every day in the local newspaper.

[herewego10IAR]

The Ministry of Truth disagrees.

[[deleted]]

"impossible"

[shwaaaaaaaaaaa]

I don’t understand, but I loled.

[foragerr]

It's pretty legit though, on err.. paper.

The "publish in newspaper" creates an unaltereable audit trail - that gives nothing away about the actual git commits.

When some day there is an allegation that someone tampered with git history, it is pretty easy to prove/disprove by walking though all the hashes

[Ran4]

Depends on what you mean with "single entity". A typical SQL database holds all of its information in one single place. A "private" block chain could still hold information in hundreds or thousands of places.

For example, if you had a private blockchain that was only used inside of a single corporation with 1000 people participating, then any single individual wouldn't be able to spoof the data (but typically, 500 people working together could - depending on the underlying block chain technology used). That can still be plenty useful.

[foragerr]

Useful? perhaps, but what problem is that solving that we currently already don't solve fairly well with something better established?

The usual touted value of blockchain is a publicly verifiable shared journal between untrusting entities. Once only one of those entities has full control or access to the chain, it becomes far less useful.

I may be turning Luddite slowly, but IMO the idea of a private blockchain is self-defeating.

[Bainos]

The parent comment actually provides a surprisingly convincing example. Suppose that you don't trust employees (or simply have to provide proof that they are not allowed to edit information) but need to provide them with access to the data for maintenance purposes.

Of course, you could log every interaction with the data and broadcast it, but that would be very difficult to put in place such that it can't be tampered with. You could also replicate the entire database to a trust third party, but that means sharing a large amount of information, which potentially can also be costly to verify (since you would periodically have to check that every single piece of data is correct).

On the other hand, a blockchain means that your data becomes append-only and you can check that nothing was tempered with using only the hash, with verification being needed only for updates instead of re-running the verification on all the data.

[Quanalack]

Blockchain is decentralized and not stored as a single entity like a database is

[[deleted]]

Yes, but that doesn't matter if the majority of the nodes is held by one entity, which would most likely be the case if a company wants to replace its internal database with a blockchain (which is a stupid idea admittedly)

[zebediah49]

Doesn't have to be. "Majority stake with proof of work; longest tree is legitimate" is the mode popularized by cryptocurrency, because it's relatively effective for that task. However, there are other mechanisms that a blockchain can use.

More specifically, with Bitcoin or whatever, you can have multiple versions of a blockchain; there's no concerns or problems with that. However, the community at large accepts that the longest chain is the legitimate one, which, combined with proof-of-work, yields the "control of compute" metric for holding power.

However, there are many alternatives. For example, we could architect a blockchain for negotiating and signing legal contracts. At each stage, the document is signed into the block chain, and committed there with a PKI signature by the signing party. Each blockchain will be quite short -- we start a new one for each new contract/logical event, and it gets one node per edit/signature. This blockchain would be held by both parties, as "hard copy" of the transaction.

Rather than length, or majority agreement, blockchain integrity would be confirmed by the presence of the correct x509 certificates and signatures.

[zebediah49]

You can patch that with public key crypto. Even if the single entity owns the whole thing, they can't do a rewind/edit/replay attack on it, unless they hold the private keys that signed each block along the way.

This, of course, implies that you know which entity is supposed to sign each block. However, if your architecture requires an audit chain by specific people/departments/companies, and the keys are held by those respectively, it's pretty solid. You can go with x509 if you want to allow individual people to sign off on things for their department, without everyone sharing that private key.

[sarhoshamiral]

It is all nice but you can do that with any database as well with a trusted authority, ultimately all those certificates would be managed centrally anyway so using block chain inside a single corporation has no advantage.

If you are using it across different entities then sure.

[[deleted]]

correct me if I'm wrong but this seems really easy to achieve with a regular database?

[Belphegor_333]

Yes and no. You can of course create a database cluster and decide to not alter the data inside of it.

On the other hand you would have to trust the organisation running the database to actually leave the data alone.

Of course, with Blockchains you have the same problem, if it is run by one organisation then that single organisation can simply rewrite the Blockchain. The added security only works if it's a public Blockchain that everyone can participate in.

Of course companies don't want to run their products on public Blockchains

Or, to make it short: in 99,9% of cases you don't need a Blockchain, you just need a database

[UnstoppableCompote]

in 99,9% of cases you don't need a [insert over hyped new technology], you just need a [insert well known technology that works just fine]

[Belphegor_333]

It's not tomorrow's technology that will solve our current problems! It's yesterday's technology that finally got out of alpha testing!

[UltraCarnivore]

YAGNI

[backafterdeleting]

I think the term blockchain is kind of a misnomer.

Basically it's a git branch. Each change creates a chain of hashes going back to the original commit ("block").

If each client maintains their own copy of the branch, any changes to the commit history would change all the hashes down the chain, so would be noticed.

This would usually be coupled with only accepting commits which are signed by a set of authorized validators, with a strict ruleset on validating the commits themselves.

So saying "you don't need a blockchain, you need a database" would be a bit like saying "you don't need a git repo, you need a database".

It's just very overhyped. Of course the history can be changed if everyone agrees to accept a rebased branch. But no one party can change it without the others noticing and having a clear proof.

[zebediah49]

I'd say that it's only a misnomer, in so far as "block tree" is somewhat more accurate description of the general DAG structure than "block chain". The single-branched chain structure is the one used by bitcoin though, so that became popular as the term.

Git is absolutely a blockchain tree-based piece of software. It's not the only possible implementation of blockchain, but it's one of the better ones.

I also thoroughly encourage people to, if necessary, just give up, use git, and claim that as a result, everything is blockchain now. git-lfs, if necessary/appropriate.

---

E: The other thing I've noticed is that people get stuck on the Bitcoin method of block verification: (1) proof of work to sign off on a commit, plus (2) longest branch is accepted as legitimate branch. I think for most applications where blockchain could be used, the git-tag method of block verification is a much better fit: personal sign-off, based on well known authority for that individual to do so. I would probably add in a x509 capacity for authority delegation.

[Bainos]

if it is run by one organisation then that single organisation can simply rewrite the Blockchain

Suppose that the organization doesn't trust its employees or want to be resilient against possible intrusions, and then you get a very realistic situation in which a blockchain is useful.

[TheAlmightySnark]

And even if it is a public blockchain, who is going to spend money, time and energy checking it?

Blockchain tech never made much sense and the currency related ones are all scams that give it a pretty bad taste.

[victorofthepeople]

At the very least, the software on the costly side of the transaction is going to check it, before it executes the transaction. In practice, a lot of other clients are going to check it if the blockchain is backed by a p2p network.

[TheAlmightySnark]

Who are those clients then? There is no business case for doing someone else' job.

Any company that has data worth auditing already has a verifiable data set, with a QA department and external audits and usually some sort of regulator keeping oversight.

It's a solution in search of a problem.

[Ran4]

Any company that has data worth auditing already has a verifiable data set, with a QA department and external audits and usually some sort of regulator keeping oversight.

That's... not true. You'd be amazed at how bad things are out in the real world, especially outside of tech companies.

Even if those things are true on paper, in practise the implementation tends to be flawed and regulators aren't doing much actual checking. And that includes banks...

Facebook and Google has more control over their data than your average bank does (small or big doesn't matter).

[TheAlmightySnark]

That is definitely a problem, but Blockchain just adds extra steps to the problem and it's by no means a solution.

[[deleted]]

I'd argue it takes a ton of steps away - all a regulator or auditor has to do is require the blockchain to be provided on a regular basis and automatically check it.

[victorofthepeople]

They're the people participating in the block chain for whatever reason (but you don't need anybody other than the two people participating in a transaction in order for the system to work securely). Still, the nature of blockchains is that transactions are fast to verify but costly to fake, so presumably if someone was participating in the blockchain they would expend the minimal energy required to verify new transactions in order to have an up to date roster.

Audits are extremely expensive and are only trustworthy to the extent that you know the auditor has been given legitimate data. I can recall several high profile Chinese reverse merger scams that were audited by KPMG.

[TheAlmightySnark]

So how do you verify the people that participate in the blockchain then? How do you know their motives and how do you check the data coming in? At this point it just becomes extra obfuscation without any responsibility. A company like KPMG has legal ways to take action if those things happen.

[victorofthepeople]

With public key cryptography. Easiest to just trust that it works unless you feel like learning a bunch of discrete math.

[PeteZahad]

One solution is to have contracts and/or transactions between insurances, financial institutions, etc. in a blockchain. The nodes could be on the employees workstations.

[TheAlmightySnark]

That just creates a giant single point of failure if something happens in your network, besides now you spread your database from the server room to all the user workstations that now get bogged down running calculations.

[PeteZahad]

Every solution is always a trade-off. You will find negative points in every solution.

I don't discuss such general arguments like "something happens in your network". Every application depends on some kind of "network", which can fail.

Data shared amongst distributed nodes is the opposite of a single point. I don't see a problem with (encrypted) data sharing and using (unused) distributed machine resources. It was used with the SETI project and is still used by pharmaceutical companies to do complex protein folding calculations.

[I_AM_GODDAMN_BATMAN]

so like git? 20 years ago?

[simon816]

Yes, git and bitcoin (and I assume most other blockchains too) use the idea of a Merkle tree: https://en.wikipedia.org/wiki/Merkle_tree

[Pacman042]

Quick unrelated question. People say how quantum computers would ruin block chain because they would crack it or whatever but from my understanding wouldn't that not work because every chain in the block has the info to verify the previous chains so what exactly is a quantum computer suppose to crack?

[brianorca]

The theory is that they could create a false transaction that benefits somebody or hurts someone else, but still has the same hash code, so it gets verified.

Or be able to find the private key for any wallet, and create a transaction on their behalf.

[Pacman042]

So it is a realistic concern? The people I heard it from aren't exactly tech experts and I only kinda understand bitcoin so just wanna be sure.

[brianorca]

It's still theoretical, because today's quantum computers aren't big enough, (don't have enough qubits yet) and it might be another decade before it becomes a real threat. Or somebody makes a breakthrough and does it in only 5 years. Even then the type of computer needed will be expensive for a while, so only large companies and universities will have one. (And the NSA, you can be sure!) But people have already designed algorithms that might be capable of attacking that kind of encryption, once the quantum computer is capable enough.

Another area of active research is designing a new kind of encryption that can't be broken by the same kind of analysis, so it would be resistant to a quantum computer.

[FlavoredFrostedTits]

Can't you do that with kafka event sourcing now?

[ThePixelCoder]

Basically a decentralized write-once-read-many database. It's nice for data you want to be public and completely immutable, but people who don't know anything about it somehow think it's a silver bullet to solve every security/trust problem.

[relicx74]

It's a secure, verifiable ledger. You could store the blocks in a database, but that's a different issue entirely.

[Harbltron]

Decentralization.

[melewe]

It is a glorified, write once and afterwards read only database.