Ask HN: What are real-life useful use-cases for blockchain (not currencies)?
I am sometimes overwhelmed by people's enthusiasm when it comes to blockchain. I have seen a project using Hyperledger [https://www.hyperledger.org/] as a plug-in alternative for an RDBMS but one party controlled the one node the system ran on.
Do some of you have non-confidential (useful!) use cases for blockchain databases to share?
290 comments
[ 3.2 ms ] story [ 102 ms ] threadA blockchain isn't the only solution available, and it doesn't require a public blockchain. A blockchain could work in this space for storing decentralized time-series signatures.
A blockchain does nothing to ensure that an indoor chicken isn't marked as outside.
How an untruthful information is distributed or secured doesn't matter.
All those blockchain logistics tracking ideas fail at the same point: where the blockchain meets the real, physical world.
For blockchain logistics, you have to trust that the information entered is correct in the first place.
For smart contracts, if you don’t trust the legal system or the other party enough to use standard contract law, you still have to trust that they will abide by the contract (and if the legal system is in such poor shape that you don’t trust it, or the transaction is by nature illegal, then the other party has even less incentive to follow the rules).
It’s not possible to create a purely technological solution to what is essentially a people problem. Our entire civilisation is built on trust, our systems are built to reinforce trust and to provide consequences when it’s broken. Things go badly fast when trust fails and no amount of clever sums can change that.
> A blockchain isn't the only solution available, and it doesn't require a public blockchain.
You are right that Blockchain does nothing to ensure that the data is truthful. Neither does a centralized database.
The options are posting it to something like Twitter, including a newspaper headline in your cryptographic signature if you want to prove an after date rather than a before date, or indeed a notary. While I agree blockchain is a more elegant solution, it's the only solution I see in this thread so far where blockchain has an extra advantage, and I'm curious whether we need to have an extra country on this planet in terms of power consumption just to avoid going to a notary on occasion.
The two Wikipedia articles I found on timestamping aren't really about timestamping of this kind. (https://en.wikipedia.org/wiki/Timestamp and https://en.wikipedia.org/wiki/Timestamping_(computing))
(I make no judgement on whether these sources of friction are worthwhile or not.)
The benefit from using blockchain is that your data will be safely replicated and accessible from the cloud, and at the same time you are the sole owner of the data. Only your private key can access the data.
In this case, blockchain also facilitates a decentralized marketplace for sellers and buyers of data storage.
So it's like an FTP drive where the hosting company makes backups and you encrypt the files before uploading, like Tarsnap?
Trying to come up with any difference (advantageous or no) I guess the point is that there isn't a single owner? Nobody liable to keep your data available, but also not a single party that can go bankrupt or some such?
For most users, the real benefit is price. Also, there might be users who can't use AWS S3 for example, because it's not available in their country for some reason.
There is liability, but it's handled through smart contracts. The hosts have to insert collateral to the system, which they lose if they can't hold their end of the data contract. The data is also replicated to multiple hosts, and encoded with erasure correcting code (with user selected redundancy) which protects against host failures.
Edit: lots of downvotes for this comment but the evidence speaks for itself.
[1] https://tardigrave.io, https://sia.tech [2] ION protocol developed by Microsoft as an open protocol, see https://github.com/decentralized-identity/ion) [3] https://www.getjuggernaut.com/, https://gethaven.app/faq/) [4] https://bisq.network/dao/, running a project, paying for software & protocol development and supporting end-users with no one entity in charge since April 2019.
I'll give you an example, from one of my startup's enterprise customers. This company needs to ensure that their high-end auto inventory remains in the same state through transport — the mileage, the car body, etc. They've had issues with transporters taking these high-end cars for joyrides, and it's hard to detect when this happens.
Our solution lets the transporter timestamp the odometer reading and car body with photos at time of pickup, on a blockchain. When the car is dropped off, it's just a matter of comparing the blockchain record with the car's actual state. Our system lets many parties who don't know or trust each other view the same "shared state" on a public blockchain ledger (Stellar), enforcing between these parties.
We provide a similar service for researchers who want to prove they were the first ones to make a discovery. You can read more about that at https://assembl.net.
Edit: You can try our timestamping app (still in beta so excuse some kinks) online at https://app.assembl.net. I would love to hear your thoughts!
The global, open database provided by a blockchain solves this problem, and also allows anybody to read the state without relying on our company to maintain the database or for uptime.
In the aforementioned case, the pickup time in known, so all that matters is that the photos are timestamped before or at pickup time. We don't worry about 51% attacks because we use the Stellar blockchain, also used by Franklin Templeton investments and IBM and Keybase... The chance of a 51% attack going unnoticed is virtually zero.
The ledger is public, and anyone can view the history of the ledger using Stellar's API (a hosted version is available at https://horizon.stellar.org) or a blockchain explorer like https://stellar.expert.
The great thing is that the data is stored on a distributed series of nodes, so no syncing is needed.
But how are the many other people in the auto supply chain supposed to know that? With this solution, they don't have to trust our company, just the SHA256 hashing algorithm.
Math is easier to trust than a small startup.
Edit: To clarify, many of the people checking against the blockchain record are not our clients.
I'd also argue that the "person who owns the database" is not just trusted but also trustworthy. They have an incentive to keep lies out of the data.
If the people you can't trust are your users, then blockchain doesn't really add anything. They can insert lies, and you have to verify them. All you get is a guarantee that no one changed their lies to something else.
If the issue is that people are taking cars for joyrides why not just have the car post a route file to a database or to its own computers of all the trips. Are auto suppliers really taking joyrides AND hacking into the computers? If you are capable enough to do that wouldn't it also stand to reason you'd be capable enough to disable any tracking units?
Certificate Transparency gets the same guarantees as well, without using a blockchain.
The biggest hiccup with this proposal is that whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions. This is not the case on a public blockchain. With the solution you describe, we would basically be running our own psuedo-private blockchain, with no advantages over a private blockchain like IBM Hyperledger.
But we use a public blockchain for a reason.
I think it's often used as a joke for how broad the definition of "a chain of blocks" is. Probably some people take the comparison too literally. Unless we manage to convince everyone and their moms that when EvilCorp pushed TheirCoin as "blockchain tech" (when really EvilCorp is the party controlling it) we should just laugh and call it EvilCorp Credits, which (last time an evilcorp tried that) we didn't, we need a more specific term than blockchain to distinguish EvilCorp Credits from Bitcoin.
Because Git is a Merkle DAG and blockchain is a Merkle chain. (I think that's the word)
So, although it would be ugly, you could store data in Git as a linear series of commits and get the same public or private ledger.
> whoever is provisioning the Git repository (most likely us) would also have the ability to change read/write permissions
But if your clients who don't trust you are monitoring the repo, and you do something like a `push --force`, they would see the hashes change.
> But we use a public blockchain for a reason.
I've tried to guess the reasons:
1. If the public ledger is watched by 100 other people, it's much harder to roll back an event than if it's only watched by a few clients who might not notice if you post an event and then immediately revoke it.
2. Since the public ledger gets a lot more traffic, its clock is more accurate. With a private ledger (Like the Git hack) you could still use the latest Bitcoin hash to prove "Commit B is made after Time A", but the window for "Commit B is made before Time C" is very large.
Honestly, my problem with blockchain is just the word "blockchain". I love public notarized ledgers. But I don't want to buy something that's riding off the hype of Bitcoin and buzzwords, and I don't want to sell that to people.
I need an audit log for something at work and I'm trying to figure out if this is useful. If it is, I would never tell my boss that someone called it blockchain. Non-programmers will think it's unbreakable Hollywood magic crypto.
How about we start calling real use cases PNL (Public Notarized Ledger) use cases? I love that term.
I'm also thinking, how do they trust my server?
With photographs it makes sense - A server that can tamper with photos live is not sci-fi, but it's also just a little bit expensive.
In my case I want to notarize text. What if I store "evil message" in my database and publish "good message" to the PNL?
Unless the end recipient of "evil message" is also logging to the PNL, (Which is hard, they're supposed to be a dumb client) nobody will ever contradict the server. I could round-trip the messages through the PNL. Make the recipient pull them from there instead of the server. But that sounds like extra risk.
It's a tricky problem, and in the end I'll have to cut lots of corners for convenience. That makes me sad.
RE: Timestamping text, check out https://app.assembl.net and open "Chronos". It should be self-explanatory to create a timestamp.
As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.
And you think the actual implementation of the blockchain will be more secure and tamper pro of?
>And you think the actual implementation of the blockchain will be more secure and tamper pro of?
Yes, absolutely. Again XRPL as example because I know it best. There has never been a single byte tampered with in the last 8 years and its several TB of Tx data by now.
I've been trying to analyze the robustness of their approach but I think their hashing algorithm (sha of json content blob) and the trustworthiness of the blockchain (they use EOS) are the two only components. Can someone who has more background in cryptography and blockchains perhaps share some thoughts about their approach?
Congrats to the team for their EU grant and traction, but this feels to me like a "problem looking for a solution". Take this with a grain of salt, as we are somewhat adjacent competitors.
Edit: apparently I don't know how to read. (Asked what parent post was working on)
Doesn't protect against the owner saying you didn't send the photo, or that it didn't arrive in time, ...
> Actually, why doesn't the owner take a picture himself?
Because they're not present when the car gets transferred between transportation companies.
The owner could be required to send back a confirmation.
But I agree, a trusted hash/timestamp service might provide better usability.
People made insane money with Bitcoin, Ethereum and others. People then dropped lots of other "coins" that eventually no one cared about. "Blockchain as useful technology" is the story to sell the next "coin". Employing a couple of devs and funding a few blockchain startups is trivial money in this context, often sponsored by "believers" (who got rich in the early days)
Blockchain tech comes with inescapable complexities and problems: bugs and security issues can't be fixed in blockchain programs. Any trivial action on the blockchain requires mining, i.e. the very thing that's done with specialized hardware in areas where energy is cheap.
My last point seems to be tangential, but do try it yourself with a small project on a private Ethereum chain, using geth, web3.js, there are good tutorials out there. Usually when you try out a fancy new tech you "get it" after a while, but I definitively did NOT see any way this is feasible.
You just described a blockchain. Why rebuild what already exists? A blockchain is a great drop-in solution and reduces our costs and implementation worries massively. And the distribution of this public blockchain is much more decentralized than we could ever achieve running our own nodes.
I purposefully did not describe a blockchain, although that depends on what your definition of blockchain is.
If we're defining blockchain as something descending from Satoshi's 2008 paper, then what I described is not a blockchain.
The distinction I'm making is one of trust. I was describing a database with centralized trust.
> Why rebuild what already exists? A blockchain is a great drop-in solution and reduces our costs and implementation worries massively.
I didn't say you should rebuild anything.
It sounds like you think that the only easy-to-use, mature append-only databases with cryptographically verifiable logs (popularly called "ledger databases" these days) are blockchains. That's not true. All the major clouds have such databases now.
> And the distribution of this public blockchain is much more decentralized than we could ever achieve running our own nodes.
I still don't see any evidence (either from you or anyone else advocating blockchains) that this is good for you use case.
Can you please explain an attack that is possible against something like Amazon's QLDB[1] but is impossible against a public blockchain?
There's also the issue of speed and usage costs of public blockchains, not to mention the frequent bugs, 51% attacks, and other uncertainties that come up.
We know the costs of building on public blockchains. I'm dying for someone to come up with a benefit that is only possible on that blockchain. Every time they try, it seems to be benefits that are shared with services like QLDB or a variety of FOSS solutions.
1. https://docs.aws.amazon.com/qldb/latest/developerguide/verif...
The blockchain adds nothing useful to the setup, you could have the exact same level of confidence if each link in the chain e-mailed a photo to a central inbox.
That there is an immutable log of the events is an implementation detail and could be solved with a write only DB completely independent of blockchain.
A public DTL has a public state unlike a normal DB everyone knows the complete DB and its distributed. If you write to it you can read form anyone else including your own node to verify it has in fact been written. Instead of trusting who is in control of the read only DB you trust that a no majority of nodes collude to tamper. Its important to know that there is a negative incentive to collude because almost all participant are participant in such a system because they theme self want to use an immutable ledger.
This does not apply to BTC or similar blockchains where the people (miners) in "control" (collectively) are not the primary users of the immutable ledger. Because there is a false incentive (money/block reward) to participate even if you have no interest in using the system at all.
I have a friend with a similar use case. His company solves it by taking Polaroids, and both parties sign the backs.
Edit: synchronising clocks is one of the hard problems in distributed computing https://en.wikipedia.org/wiki/Clock_synchronization
It's complex to synchronize clocks perfectly, but to within a few seconds is easy and there aren't many cars that could rack up an appreciable mileage in such a short time.
The Bitcoin block hash cannot be known before it's calculated, and a new one is calculated every 10 minutes. Works great.
But in this case, isn't whoever controls your code the "timestamping party"?
Looking at two examples:
A: With blockchain
The timestamp that the photo was taken is immutably, publicly logged.
B: Without blockchain
The timestamp the photo was taken is logged by you, the software provider.
What is a scenario where (B) is less secure than (A)? In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.
So it sounds like all you're doing it creating a public, verifiable record of something that you have no incentive to alter and something that doesn't actually verify the state of the vehicle at any point in time.
From personal experience, the most common types of fraud in this space are (1) just posting an old photo as though it were taken right now, and (2) posting a photo of a different vehicle. I don't see how either of these are prevented.
What am I missing?
(Full disclosure: I built software that does something similar for different types of clients, so I've worked on the problem of "verifying vehicle state" for ~10 years.)
> When was it taken?
We currently verify this by including the last Bitcoin block hash in the photo, giving us a ~10 minute time window in which the photo was taken. Also, the whole handoff period is under 20 minutes, so the transporter only has access to the cars for 20 minutes (with many others around), before a timestamp is required.
> Who was taking the picture?
We've never run into this as a problem, but we can require a continuous video including a selfie of the transporter.
> What is the picture of? The car to be protected? Or someone else's car.
This we verify by checking the VIN in the frame (frame number check).
Had an interview for a company like that once, where they required that no work-related communication happen outside of their chat client. And they had cameras to check for that. The turnaround rate was through the roof.
I genuinely hope that you'll try and solve these problems using other methods. Building these systems just makes your employee's lives hell.
We don't do any of what you describe. When I said "continuous video", I was referring to the transporter taking a video of the state of the car — two minutes max. No livestream or tracking or anything.
I don't watch or control my employees or the transporters (they are just a client of a client). I don't even see the pictures they take before transport, usually just our customer.
It feels like you're wilfully misunderstanding something.
https://shkspr.mobi/blog/2018/06/how-i-became-leonardo-da-vi...
> isn't whoever controls your code the "timestamping party"?
No (and sort of yes). The result of the timestamp is instantly verifiable against the timestamped data, meaning the results of the timestamp can be viewed on a public blockchain explorer or using an API that interfaces with the blockchain, without trusting our code. If another party doesn't trust our frontend code, they can build their own frontend logic that interfaces with the blockchain in the backend to independently verify results. If someone is using our app, they implicitly trust our code, yes, but they don't have to trust our database. That's the difference.
> In both scenarios, you have no proof of when the photo was taken. It could've been two hours or ten minutes ago. There is no way to digitally verify it.
This is a solvable-ish problem. What our app does is require the photos to be taken in-browser, and adds a small stamp to the photo before hashing it with the most recent Bitcoin block hash. This way, we have a window of ~10 minutes within which we know the photo was taken.
Can this be abused? Yes. But the transporter is exceedingly unlikely to know how, and they also don't have access to the cars before handoff, so the concern is really negligible. Faking the photos is now at least a few order of magnitudes harder than before. We can improve on this in the future.
> posting a photo of a different vehicle
We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.). This is a pretty foolproof solution.
I think you misinterpreted the attack I was describing.
Let's say you rewrite your front-end code to change the timestamp. Sure, someone could read it, but reading source code every time it's updated is not a sustainable security practice. It's also especially easy to hide malicious code in JavaScript.
How does blockchain prevent that attack? Your blockchain is memorializing data that you have interfered with. Someone can definitely verify that whatever photo is on the blockchain was really added to it at whatever timestamp. But how does that give them any proof that the photo was actually taken at that timestamp?
All the blockchain does is say, "At [timestamp], this photo was added to the blockchain." It doesn't offer proof of who took it, where it was taken, what the subject was, or (crucically) when it was actually taken.
And that basic guarantee (that the photo was taken at a certain timestamp) is just as easy to accomplish with an append-only database.
Regardless, this is all about mitigating an extremely unlikely attack: your own company. Why do your own clients need to verify that you are trustworthy?
> What our app does is require the photos to be taken in-browser
> We ask the transporters to take a photo of the VIN in the frame, along with other photos (body, odometer, etc.).
I agree that these measures likely stop close to 100% of attempts to defraud you, especially because there is a chain of custody that makes fraud more difficult.
But I still don't see any reason this couldn't/shouldn't have just been built on a vanilla RDBMS. Hell, if you want to verify the timestamp, you could just instantly email the photo to someone via Gmail, since you can't fudge Gmail's SMTP timestamps.
As I said before, using blockchain here decentralizing trust in a situation where the source of truth is... you. And it still doesn't make you trustworthy, since you can alter the photos before ever hashing them.
An app can always show the users fake results, regardless of what's genuinely stored in the distributed ledger.
This way both parties could verify the transaction was completed as contracted (IE no joyrides).
I'm still in the camp this probably doesn't need blockchain, but that would at least handle the image manipulation problem.
But yes, depending on the application, photos can be manipulated. But that is stating the problem with using photos, not the timestamping app.
Basically, yes, you could, in theory, maybe, sort of, possibly, build a similar system without a public blockchain. But why? I'm sure there are people who can build houses with a few hand tools, but there's a reason we have power tools and heavy machinery — they are more efficient and fit the job better. The same goes for blockchain in this case.
If you can point out where my logic is incoherent, please do, but to me the following: "oh, just set up a distributed git repo or database with checksums and append-only permissions that you control but replicate to other servers not controlled by you so that you can't tamper with the outputs and read from that global state and verify against the other mirrors of the database or repo every time you read from global state" sounds like a stupider alternative to blockchain.
This is what blockchains were made for!!! Distributed consensus!
Also what is the point of mining or and proof of $whatever system? The thing your customers provide is a signed attestation of some fact and you provide a signed attestation of the time that fact was received. Why is there a need to "vote" in way on what is true? This is just a database or honestly a folder of signed messages.
And I say signed, but none of this really need to be cryptographic in any way since they're customers that could just authenticate to you which is as much a proof of their identity as any key.
The way the transporters know they're getting a fair deal is precisely because we are not the source of truth — a database outside of our control is (a blockchain, in this case).
We're not voting on what is true, we're relying on the blockchain as an immutable representation of state. An append-only, distributed database that we do not control.
And please don't downvote my comments out of a misunderstanding. That's juvenile.
This is a trust problem. Either people trust you, or they don't. You've attempted to increase their trust in you by creating a system that would increase somebody's trust if they had your understanding of the underlying technology. Very few people have this, and the overlap between the people with that understanding and your customers and clients is vanishingly small.
Trust really isn't binary.
> would increase somebody's trust if they had your understanding of the underlying technology.
Or if they had a handwaivey "I've heard that blockchain increases the verifiability of things" level of understanding.
It would require cooperation from auto manufacturers but I'm sure you could come up with a scheme where the car itself signs and timestamps mileage data.
In this specific example, what would they change to photo to? The case is to stop joyrides. Who would be able to take a joyride and end up with the odometer exactly as they had Photoshopped it to hours or days ago?
But yes, depending on the application, photos can be manipulated. But that is stating the problem with using photos, not the timestamping app.
I'm not discouraging you. Just to say your blockchain backed solution is a fair solution but it's not the only solution.
Could someone tweak the image? Of course. But as a practical concern, probably less than 20 people have the image manipulation skill it would take to do something like this in the ~20 minute handoff period. The transporters certainly don't. This is a bullshit argument, and you know it. And these pictures are not just of the odometer, but the entire car, including the VIN. Photoshopping all of this believably would cost you more than just paying the damages on a joyride. It's a non-issue.
And I think you're misunderstanding something: the issue is not the time before the transporter get custody of the cars, but the many days that the cars are in transit cross-country. If the timestamp didn't exist at the time the transporter starts their journey, the next handoff knows something is up.
As for already trusting us, our clients do, yes, but the point of this solution is to increase the trust-level of custodianship handoff between people who are not our clients. A blockchain is a great solution for this, and a database is simply an inferior solution. And NO, they don't have to trust us to "push the right data on-chain". This logic runs in a very simple SPA and is immediately verifiable on-chain, without using our software, because the blockchain's global state is open.
If you're arguing to put everything in a spreadsheet, or have us control the database and do without timestamping, I don't know what to say to you. Blockchain works here. Our business model isn't changing because you're saying we don't need it. Build a system like this yourself and we'll talk about it then.
Carfax is a vertically integrated service with very little of the complexity we're dealing with. And of course you can make do without blockchain. People made do without electricity and power tools. But here it's a cheap, faster, easier to use, and more trusted alternative. What's wrong with that?
Done. It's an email server. The person shipping the car takes a photograph of the odometer, emails it to the recipient, and then the recipient compares the photograph of the odometer with the car odometer. Any tampering which could be performed on the photo or its timestamp could be done equally to whatever log is entered into the blockchain, and the recipient knows that the photo must have been taken before the date when they received the email.
And if you use gmail, it's free.
Blockchain is not a "killer" feature of the app, but it's another layer of security. Databases are the core, but staff with access can edit a database in seconds. Maybe one way to think of it is like cash registers. The person operating a cash register can still steal it, but it's a lot harder than if it were just a box. It won't stop a dedicated person, but will greatly discourage doing it casually.
A lot of people talk about the benefits of blockchain and then describe a cryptographically-secured, append-only database (something like Amazon's QLDB[1], which does not have distributed trust or ownership).
If you're not actually using a blockchain, then disregard.
If you are using a blockchain, how does it add trust? Isn't your company, which controls the I/O for the system, still the central authority?
1. https://aws.amazon.com/qldb/features/
But where this seems to fall apart is if you need very precise ordering (think stock trades), as an unpermissioned chain won't going you a high enough block rate. So you move to a trusted node that mints blocks, and at this point you might as well call it a ledger computer, issuing signed receipts.
The big unsolved problem is the analogue gap though, and how to get something from the real world into the chain - the person or device making the observation inherently need to become trusted oracles. In the odometer example, you could surely take a photo of the odometer before the joy ride, then submit the old picture once the vehicle is leaving your custody? Client side restrictions this is a live photo don't help as they can't be verified on-chain, so now the next person gets blamed? Or have I missed something here?
AFAICT, this is not such a problem where a third party cannot be trusted (the only incentive would be if they contacted you and tried to bribe the modification, which doesn't seem worth it).
Otherwise, if the DBA can be trusted, it's not clear to me that the blockchain offers any additional verification, encryption, audit-ability, etc -- and it doesn't seem to me that the "DBA cannot be trusted" is a sufficiently possible risk scenario to try to eliminate from the equation
https://electriccoin.co/blog/encrypted-memo-field/
It looks like this capability is being expanded with in-band secret distribution:
https://zips.z.cash/protocol/canopy.pdf
Imagine that all land records are in a distributed ledger. The land owner has a signed certificate that can be verified anytime for authenticity. The only way to access the certificate is with a 12 word passkey.
> If a file is signed and it can be matched against a distributed ledger, it can help ensure the authenticity of the file.
So I guess the point is that you don't want to have a central, trusted party. So someone can't simply hack or bribe that party. But what prevents a malicious actor from pushing their file's signature onto the blockchain? If only certain keys are allowed to use for signing, we're back to the trusted party: those with key access. What is the benefit here?
> Imagine that all land records are in a distributed ledger. The land owner has a signed certificate that can be verified anytime for authenticity.
Is this related to the file authentication thing? Perhaps because I don't know what benefit the former should have, I don't get what this is supposed to have in common. Here too, though, I don't see an advantage of doing it on a blockchain. The department of land records can publish a public key corresponding to the private key they use to sign land certificates: "that can be verified anytime for authenticity."
For a specific non-money potential use case of blockchain I would say identity services. For example, currently the internet runs based on implicitly trusting a set of root CAs (hundreds just counting the big ones!). The CAs certify that a site is what it claims to be. But if the CA becomes malicious (either through intent or hack) there are limited mechanisms for combatting this.
If you decentralize the certification process you can have a trust-less system. This also works beyond CAs - any sort of identity management falls under the same principle: Credit scores, citizenship, etc
Okay so with a bit of hand-wavey stuff I'm sure we can make a parallel where you also solve world hunger with blockchain and trustless systems where there are no centralized parties that can do bad things. But realistically, how would this work? Whose key will end up signing the TLS certificate for my website? You're not really proposing anything more concrete than "let's move CAs to a blockchain".
Placing things on a blockchain is a paradigm shift. Yes you can 'just' do it on a blockchain, but you're likely not taking full advantage of the capabilities you receive. Looking at the TLS signing example - why do we actually need to sign the TLS cert?
The purpose of a CA signing a cert today is so that the CA can say a cert is what the CA saw and has not been modified. Well if we put it on a blockchain we know it cant be modified (as this is an inherent property of a blockchain). Instead of asking 'can I verify this cert with the CA pub key' I ask 'can I find this cert on the blockchain'.
Under some schemes (see the EiDAS regulations if you have trouble to going to sleep some night soon) that also vouch for company registration numbers, company roles granted within the EU financial system etc etc.
I'm not sure how (or why) you would do that with a blockchain.
Certificate Transparency does this - each monitor adds records to their ledger and signs them, and the latest record includes a hash of all previous records (via a Merkle tree). Auditors trust any hash they see which is signed by a monitor. If they see two ledgers where one is not a subset of the other, they trust all the data in both ledgers. If this persists, they have cryptographic proof that the monitor is trying to not include some record it previously included.
Git does this. Each commit object has the hash of the parent commit objects. You can walk through a commit object and see what the ancestry is. If you push to a server, it can make sure that your new history includes all the old history, and similarly, if you pull from a server, you can do the same check.
I have been looking around https://github.com/google/trillian, looks interesting.
It is technically true that one application of blockchains is solving problems that can be solved by regular chains, just like it is technically true that one application of self-driving cars is the ability to turn off the automation and let a human drive. But if someone asks about the applications of self-driving cars and you say "Driving on the open road is fun," I think most people would not accept that as answering the question asked.
(And I'm not just being pedantic: blockchains have a significant computational/environmental cost, so if you don't need the block mining feature, you will get many orders of magnitude faster performance and run many of orders of magnitude cheaper and cause fewer negative externalities if you just use a plain old hash chain.)
Bits & bytes can be cloned effortlessly by computers which is why a version of Photoshop ripped from a DVD is indistinguishable from the same version downloaded from a CDN as an iso. As long as the hashes match, you wont be able to tell apart the master copy from its 1000th copy.
For money to be valuable, in addition to trust, it also needs to be scarce in the physical sense. Blockchains allow us to engender that illusion of scarcity in the digital world, otherwise it would be impossible to tell apart the binary representation of a $10,000 currency note in one computer node from counterfeits held by other nodes in a network.
If your project doesn't need decentralized trust, using 'blockchain' is simply a marketing move.
This is only true in the cryptographic sense when talking about data on the blockchain.
Blockchains do NOT solve any trust problem outside of data on the blockchain, and in real world use cases when we're not dealing with how many coins each person has in a wallet, this is the most important thing.
Specifically your cryptographic tamperproof data on the blockchain is useless if you have bad actors entering garbage data.
It's useless if the data on the blockchain is out of sync with state in the real world.
Even in the internet commerce use case where bitcoin was supposed to take over, once the bitcoins are transferred you still have the unsolved trust issue of verifying delivery.
Saying blockchains solve the trust issue in the real world is disingenuous magical thinking, and I wish people would stop doing it.
Swift GPI allows banks to credit the receiving parties' account in 10 minutes rather than overnight.
It's an example where the existing party (swift) already had accumulated all the trust necessary and the consolidated ledgers were updated overnight.
Swift GPI allows a bank to track any inbound payments and recognize it to clients before it is formally received by the batch process.
In my mind it also sets the only way to successfully launch a blockchain solution... by the incumbents who already have the trust centralized and are interfacing with a very large amount of parties (8k banks in the swift network).
The best solutions in my opinion should come from governments as they often act as notaries often act as trust providers. Examples here are real-estate titles, assets and potential liens on those.
Hell, we should require the whole federal budget to be spend in crypto-dollars so citizens have full transparency of what happens with their taxes.
Governments that grasp cryptocurrency could remove so much transaction inefficiencies caused by the current registration processes and uncertainties around ownership.
Other potential solutions would be for multinationals their accounting. Their accounting of every subsidiary is in a different system and creating consolidations is usually done periodically (and expensively).
Allowing an open accounting architecture for multinationals could boost innovation and kill companies like SAP who really is the only player in town that can handle the complexities multinationals face.
A company like facebook or google could develop this and open-source it
SWIFT has been playing with blockchain for years, always backing off. They had a partnership with Ripple once, some hackatons, a lab dedicated to blockchain. Former CEO even bragged about making bitcoin transactions himself.
There was one corner use case around GPI and R3 Corda announced in 2019, but I doubt it ever was used in production.
Well, I guess that brings the useful applications I know of to 0
You can do this by appointing someone as a trusted authority. But, in practice, this has overhead and no one is completely trustworthy at least absent a lot of overhead. You also often have to deal with reconciliation when there are a bunch of different data stores scattered around.
BTW, Hyperledger is the overall foundation of projects. Hyperledger Fabric is the most popular blockchain platform under the foundation. (There are also various libraries and so forth.)
(And if one of the agencies has the ability to acquire more computing power than the others are currently contributing to the blockchain - which is almost always true in this era of cloud computing - they can attack the blockchain just fine. Yes, it will be "obvious" in that it won't match anyone else's records, but the whole point here is that you're not trusting the majority's records, you're trusting the blockchain, right? Who is to say the majority are not lying?)
Not sure how to phrase this in a way that doesn't sound suggestive. I don't mean it suggestively at all, I'm just curious why I heard of it at its inception but then never heard of anyone actually using it. You say it's a marked improvement so I would expect people to jump on it and stop paying the random companies running our TLDs?
There's opportunity for a significant privacy and authentication improvement over DNS. Two key advantages:
1. One can run one's own node, reducing or eliminating DNS privacy leakage. Today your ISP can't read your traffic with https://secret-newsletter.example.com/ but they do know that you looked up the IP address of secret-newsletter.example.com. which is about as bad. DoH is somewhat better because you can choose your DoH provider, but in practice people will probably use one of a few major offerings, which they'll have to trust.
2. Info about a name can be authenticated, so in response to query you could receive both the ip address corresponding to a name, and a hash of the TLS certificate that ip address should use, removing the ugly hack of certificate authorities. There's lots of details to get right here, but the potential advantages are enormous.
IMO those are the key advantages of DNS on the blockchain. But there's a big gap between having an idea and executing on it. There's tons of existing DNS infrastructure, and it's not going away overnight, so work is needed for interop, and there are complex questions to resolve around regulation and trademarks etc.
As the saying goes, it takes years to be an overnight success.
Do you actually hold the position blockchain was never hyped beyond what it could do for currency or are you just talking about a completely different topic than this post entirely?
In can do some of the things you'd use a notary for.
Or, just use an entirely conventional database, operated by the notary.
I myself am the head of all blockchain engineering at Poloniex, a large and old crypto currency exchange. I try and advocate for this industry but it is very difficult vs. all other technologies.
For everything else there's a much cheaper option, even for time stamping. Anything involving "proving" something, meaning making some assertion at some time is not a good case. For those look at certificate transparency for a better example of how to handle that. When people say "storage", I say no. All valid cases which involve that are really about the handling of payment for storage, not the storage itself.
For anything that involves timestamping some assertion that many parties care about on an ongoing basis it's much cheaper to have a distributed system of watchers. See certificate transparency. There's a lot of commercial inventive to want to falsify that, but is anyone able to in practice? There's no blockchain there.
Some things money can't buy, but for everything else a blockchain can organize payment for it.
An observer can verify that the log remains consistent (thus nothing can be retrospectively inserted or removed as opposed to appended - without an observer detecting this) and that specific things that carry SCTs saying they were logged were, in fact, appended to the log.
This isn't a blockchain. If you want to call it "blockchain technology" you can probably squint hard enough to do that, see also various "Internet technology" companies from the turn of the century that just consisted of a normal company plus a web site most of which were failures - but I don't think you learn anything from it.
And in fact not all of CT is actually finished and deployed. There ought to be a Gossip system, which would allow clients to er, gossip about things they'd learned, and thus discover any inconsistencies which they can't see individually. e.g if from Turkey the log seems to show one entry for this www.google.com certificate but when seen from France the entry is different, Gossip potentially allows a Turkish client to tell a French client what it saw and the alarm is sounded. Gossip is necessary to ensure logs can't deliver a split horizon view and to loop back the trust from SCTs to actual log records, but it's fraught to do this in a privacy-preserving manner.
The actual deployed system works for two reasons, which I've no doubt would horrify Blockchain proponents who worship at the altar of distributed consensus:
1. The actors (root Certificate Authorities, trust stores) are basically honest. They're not always competent or diligent or open but they mostly don't deliberately spread falsehoods, so the records in CT would probably be almost as useful even if it was just a huge text file or something with no cryptographic basis of trust.
2. The main clients mandating CT are Safari and Chrome and both of them require that certificates are logged with Google (and somebody else, but you can pick who). So attacks that require falsifying the logs can't work unless Google does them. If you're Google this is enough. If you're not Google it's still pretty satisfying, why would Google build this complicated and relatively expensive system just to lie to me about something I otherwise would have no way to know about in the first place?
I should correct this. MD stands for "Message Digest" which is what this type of algorithm is for. So then it's just a coincidence that it's also the initials of (Ralph) Merkle and (Ivan) Damgård whose method for making a cryptographic hash out of a compression function was used.
> We are not making "the" blockchain, and we do not claim to support decentralisation.
This does not use a blockchain in the bitcoin/ethereum/... sense of the word. Perhaps in a "git" sense of the word, but I don't think that's what OP meant when asking for legitimate uses.
* https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf
* https://doi.org/10.6028/NIST.IR.8202
The DHS originally created it, but I can't find a definitive DHS source. Also here, at bottom:
* https://www.fedscoop.com/blockchain-for-government-technolog...
For SDVs to really take off, it needs to surpass the safety of a human driver but the only way to do this reliably in a way that avoids the high costs and ugly protrusion of roof-mounted LIDARs is for SDVs to use low-cost internal sensor inputs and fallback on low-cost external sensor outputs from nearby vehicles[§] and road infrastructure.
Essentially, what I think is missing from all SDVs currently in development today is an important ingredient behind why Internet-use is so widespread today: a common communication protocol between SDVs from different manufacturers.
Once a common protocol is adopted/legislated, all SDVs will be expected to record any accidents encountered during any trips in a partial copy of the “road blockchain”. Stated differently, details of accidents and near misses will be recorded with timestamps on the partial blockchain maintained by each SDV in a way that the exact position of all SDVs within the vicinity of a car crash can easily be reconstructed. Of course this will mean SDVs will use clocks that are network synced.
If 6 cars are in the vicinity of a crash between 2 cars, the trajectory of all cars before and after the crash could be reconstructed using the blockchain data from those 2 cars. If the 2 cars’ “black box” are lost due to them exploding on impact, the data could still be reconstructed using the partial blockchain data from the 6 SDVs proximate to the crash.
The “road blockchain” would be especially useful in accident investigations but its privacy implications would need to be properly thought out.
§: If a SDV has front sensors that start to return conflicting inputs while in operation due to inclement weather for instance, rather than the onboard computer aborting the ride in the middle of nowhere, it could switch to operating at partial instead of full situational awareness. In this state it could routinely query any three nearby vehicles for help: the vehicle in front, behind it & to its left to regain some level of situational awareness.
Another use case would be falling back on wireless beacons when Internet access over cellular is lost. The SDV could start an adhoc network over wireless where it can broadcast a request for help from nearby SDVs. Something like: “I’m traveling from LA-SF. I need a recent copy of the point cloud from anyone traveling in the opposite direction (SF-LA)”.
For this to work at scale, a common protocol that allows a SDV to start a wireless conversation with any nearby SDVs would be required.
One straightforward way to solve that is to say that only known car manufacturers may upload results and it must be signed by something that chains to the manufacturer's key - but at that point, you don't need a blockchain for this.
The SDV-to-SDV protocol could borrow from the contact tracing protocol used for COVID which requires about 60% of prior contacts for a positive match [§].
If SDV A says that at 11:00pm today it passed SDV B, C, D at location X, then if we were to reconstruct the blockchain from the perspective of each of SDV B, C or D, the collected data should be identical to the chain reported by SDV A, otherwise we would simply discard records that conflict with the longest chain, similar to how the blockchain mechanism works with Bitcoin.
§: https://ncase.me/contact-tracing/
IMHO it'd be much easier to sell people a $10,000 self-driving option that worked immediately, than a $2,000 self-driving option and a promise it would start working at some point in the future, when xx% of vehicles on the road had deployed it.
The other option is private blockchains with limited, authenticated accounts, but then why not just use a timestamped db?