191–200 of 291 posts
https://www.synaptichealthalliance.com/
Medical insurance companies have a huge problem just keeping their contact databases of healthcare providers up to date. Doctors move offices or retire or stop accepting new patients and never bother to inform the insurers they work with. This system allows competitors to share that data in a fair way which reduces healthcare costs for everyone.
This is because it is designed to have its state stored permanently by thousands of computers, with any entry becoming part of a permanent canonical shared history of the network going forward.
What all of that distribution and synchronization gives you is unparalleled immutability, data permanence and uptime.
So the applications best suited to this highly constrained and highly reliable/accessible computing environment are those which require relatively small data transfer/storage, where the data operations are of extremely high value relative to the computing resources they consume.
So far these applications have been currency, marketplaces and financial contracts, which all benefit from being on an open platform that is effectively resistant to capture by any party. You're also seeing very large markets emerge in digital collectibles.
Earlier quoted context omitted.
Gmail would be just as good. Have them send you an email as part of the handoff process. Time/date/photo will be documented in a source of Truth
If you know anything about email headers, this is a bad solution. Are you suggesting that everyone has a shared Gmail account with one password? What happens when an email gets deleted?
Earlier quoted context omitted.
That's true, but none of that is enabled by blockchain. You can do all of that with an append-only, distributed database that is cryptographically verifiable. You don't need a public blockchain (or any blockchain at all).
> an append-only, distributed database that is cryptographically verifiable 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...
Earlier quoted context omitted.
> where the timestamping party cannot be trusted to act honestly because of conflicting interests 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 le…
To address your concerns: > 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 t…
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.
If you are a large-ish business, you will talk to your insurance broker to insure it. This will probably turn into a multi-thousand page document describing all the assets that you want protected, and what events you want them protected from.
The broker then does "marketing" which means nothing like what marketing means in any other context. It means that they are going out to the underwriters and asking them what parts of that whole package they are willing to underwrite, and at what costs.
The broker then cherrypicks whatever is best for their client by piecing together underwritings for different parts. ("Allianz is underwriting the buildings for the first $800m, Lloyds will do everything beyond that up to $3B, SwissRe had the best weather insurance...") The client wants to know that the broker genuinely did approach as many underwriters as they claim and validate that the underwriters did reply with the quotes that the broker claims were replied. (This is how the client makes sure that the broker and the underwriter aren't colluding.)
The end result is that across the industry there is a many-to-many broadcast and scatter and gather that needs to happen and be notarised. (The broker sending stuff out, the underwriters responding.)
At the moment, there is usually a third party hub through which these documents flow who essentially notarises the communications, but also has no incentive to allow collusion between parties. So everyone trusts that third party.
The only problem is, there is no incentive for the third party to be efficient, and so in every country / state / market where this kind of system operates, the third party inevitably takes a large cut of fees and provides quite remarkably terrible service. (Case in point: "of course it's secure, it's on port 443". "Umm, you are actually just making an HTTP connection on port 443, there's no SSL happening on this connection, as can be seen in this packet trace.")
The brokers hate how it has played out, the underwriters hate it even more. With a bit of handwaving, this is something that can be solved by a blockchain. Although the unencrypted documents themselves probably can't be on the blockchain, the checksums can be, and maybe there's a scheme where the encrypted versions of documents can be there too.
It's one of those situations that blockchains are good for: distributed system, no trust required, the users of the blockchain can afford the appropriate technical skills to keep the system running, can't be replaced by an independent 3rd party, etc. etc.
But it's not likely to happen.
The main problem is that there's no monetary incentive for any individual party to build the system. It's a tragedy of the commons problem: once it is in place, it will get used, but no-one wants to pay for it because if someone else can pay for it first then that's a better arrangement.
So yeah, five years of discussions and learning about the market, and everyone wants it to exist but no-one wants to pay.
Broadly speaking blockchain only solves a singular problem: Trust. If there is some work that needs to be done between parties and you don't trust the parties involved then you can use blockchain to do the work in a trust-less setting. This is why money has been the first and most prominent use case; people are less trusting with their own money. For a specific non-money potential use case of blockchain I would say i…
> If you decentralize the certification process you can have a trust-less system. 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 proposin…
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'.
Earlier quoted context omitted.
Nothing proves that the timestamp accurately reflects when the photo was taken or that the photo itself is even accurate. If I wanted to joy-ride one of these cars I'd simply do so before taking the photo. The odometer display can also be trivially modified for the sake of a photo (i.e. roll back the odo for a photo and then revert to accurate numbers after the photo)
The next entity in the supply chain would have an odometer that didn't match the picture that was previously posted. It limits who is possibly at fault to a minimum of one of two parties, which I'm sure could be narrowed down further by corroborating evidence. It highly discourages it because at the very least, you would be the first suspect with no real finger to point.
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.
Earlier quoted context omitted.
Nothing proves that the timestamp accurately reflects when the photo was taken or that the photo itself is even accurate. If I wanted to joy-ride one of these cars I'd simply do so before taking the photo. The odometer display can also be trivially modified for the sake of a photo (i.e. roll back the odo for a photo and then revert to accurate numbers after the photo)
How do you undo any dents that may occur during a joyride though?
What is one good use case for ice cream scoops other than scooping ice cream? One might exist, but the real question is "who is the obsession of killing digital currencies coming from?"
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?