Do some of you have non-confidential (useful!) use cases for blockchain databases to share?
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!
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.
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.
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.
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.
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?
Who was taking the picture?
What is the picture of? The car to be protected? Or someone else's car.
> 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).
https://shkspr.mobi/blog/2018/06/how-i-became-leonardo-da-vi...
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.
> 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.
I have a friend with a similar use case. His company solves it by taking Polaroids, and both parties sign the backs.
An app can always show the users fake results, regardless of what's genuinely stored in the distributed ledger.
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.
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.
As CT shows, there are other ways to solve the audit-logging-for-untrusted-parties problem.
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.
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.
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.
Edit: synchronising clocks is one of the hard problems in distributed computing https://en.wikipedia.org/wiki/Clock_synchronization
The Bitcoin block hash cannot be known before it's calculated, and a new one is calculated every 10 minutes. Works great.
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.
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?
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.
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
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.
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?
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.
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.
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...
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.
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.
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)
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?
The other option is private blockchains with limited, authenticated accounts, but then why not just use a timestamped db?
Having recently completed a house purchase and waded my way through reams of paperwork in the process, I'm stunned that there's no "document provenance chain" implementation. At every stage of the process, I was presented with tens or hundreds of pages of paperwork that I was expected to sign, most of which was exactly the same as the paperwork I had approved in the previous round, with changes only on a page or two to reflect the renegotiated terms. However - I had no proof of that similarity, and so I had to read through every page to verify it for myself. If I could have had a programmatic way to show that a) changes only occurred in the following places, and b) the original document that I reviewed is the same as a blessed authoritative template provided by some trusted independent party, the whole process would have gone a lot faster.
Actually, now I come to think of it, this wouldn't even need blockchain - it could just be Version Control, right?
I've seen companies like https://draftable.com providing exactly that (seemingly targeted at lawyers and people who do this all day) and it seems to work pretty well.
For those that would like to use the feature.
What you actually want, I think, is a legal document that says "The parties hereby amend the contract previously agreed to on mm/dd/yy as follows: after paragraph 5, add .... For reference, a full copy of the amended contract is included. In the case of discrepancies, this description of changes, and not the following copy, is authoritative."
Or just a list of sha256 hashes.
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.
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.
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.
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.
If your project doesn't need decentralized trust, using 'blockchain' is simply a marketing move.
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.)
If you want to learn about examples, read throughout the comments. I've read about half the comments and, to no surprise, not much of substance.
Distributed DB ("private Blockchain") has its uses, but it isn't publicly owned like a traditional Blockchain.
* 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...
Proof of Work and currency are inseparable, it is all interrelated to the design of any application using the blockchain.
I used hyperledger and even the example projects from the instructor were talking about all the threaded operations it can do, if there is no cost to the computation then randoms are DDOSing all the nodes in the system for no reason, which is exactly what happenes in real world hyperledger consortiums. Its dumb.
Either accept that speculation is a use case or move on.
Thus, you must really, truly need censorship resistance to accept that sucktitude. So what are people censoring? Financial transaction, social media posts (but they must for moderation anyway.) Websites are also censored, which is layer down the stack from social posts, The low throughput of blockchains makes them inappropriate for this purpose. Probably also for the social posts as well. Good luck!
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.
Obviously the market is primarily enterprise, legal, and insurance companies. We hope to get the cost per transaction (CPT) under €100 sometime in the next five years. Early adoption has still been surprisingly strong, surpassing projections by about 40% per year compounded.
In can do some of the things you'd use a notary for.
Or, just use an entirely conventional database, operated by the notary.
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?)
[1] https://myrobocash.com/ [2] https://uspto.report/patent/app/20200304647 [3] https://drive.google.com/file/d/1c1GyiVVZFDiUuxWkBCQ63qLdJgP...
Re: minus the refundability
The refundability is the main thing that allowed us to patent this. HashCash, and the large PoW required by Bitcoin are meant to strain any attempt to transact on the respective network. Ours only strains bad callers (monetarily) and does not strain good callers.
The argument we presented was that good/bad callers can be simplified as calls that lasts more/less than some time threshold.
Simple, user-friendly, intuitive, and serves the purpose of disincentivizing high volume spam calls while giving legit unknown callers a chance to bypass the blind filter.
Here in France, phone spam is essentially non-existant, and I'm nearly sure there are no block chains involved.
I'd posit that this is a tech workaround for a political problem. Which is fine in my book, but it's not exactly a killer application for the technology that is block chain, if really you'd want (and could have) something that does the job better.
Re: if really you'd want (and could have) something that does the job better.
I'd argue that nothing is better than blockchain in terms of dealing with monetary policy in each country. Since this solution is 100% targeted at the economic incentives that drive phone spam, the reward must be a financial incentive that is easy to globally implement and furthermore allow a user to easily transact with, regardless of country. P2P currencies means someone else in whatever country can worry about designing services that take/use Nano, while I focus on blocking phone spam and don't get wrapped up in potential race/optimization conditions in using "funny money". /rant
Doesn't mean this is a killer app, just as you said, 1 way of trying to solve this 30 year old problem that will only get worse over time as the Internet of Things matures.
[1] https://truecaller.blog/2019/12/03/truecaller-insights-top-2...
Attaching a signature to the end of the file (a la PGP) after the padding rows seems workable.
Another example would be decentralized governance. The bisq.io project has built a system on top of bitcoin to incentivize and pay for their project's future development. They chose their model for censorship resistance (as they have concern that nation-states might not take kindly to a peer-to-peer permission-less bitcoin to fiat exchange) and its been functioning since April 2019. In historical perspective, the bisq network has innovated a new way for humans to work together that rivals the invention of the joint stock corporations by the English and Dutch at the start of the 17th century. There's lots of talk of decentralized governance on top of Ethereum, but so far the only really resilient and decentralized project I've seen in the space is the bisq network. Bisq is the sort of new thing that can be built on top of bitcoin's trust-decentralizing monetary technology.
I expect digital ID will also benifit from an auditable, immutable log (e.g. sovrin)
First of all, you need multiple sources of truth. i.e. Everyone can make transactions with money, therefore everyone is a source of truth.
Second, you want to solve your problem in a distributed fashion and you need to figure out the incentives for each node that contributes. i.e. Everyone wants to participate in the economy and is okay with giving a small commission for a transaction.
On top of all this, you also want to maintain some invariant. i.e. Transactions do not create money.
I have thought of more properties, but they are much more boring. These are enough to throw away pretty much all the hype around blockchain. Every time someone suggests blockchain to solve a problem ask yourself if these properties apply to the problem at hand.
Example: Someone suggests logistic company x could use blockchain in order to keep a log of their distribution. But then, you astute reader ask yourself: If a single company essentially holds all the information, there are no multiple sources of truth. How would this instance of blockchain be different from a centralized database? What values does it add?
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.
And if any messages are deleted, everyone can see that something was there, and when it was deleted, and who deleted it.
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.
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."
https://electriccoin.co/blog/encrypted-memo-field/
It looks like this capability is being expanded with in-band secret distribution:
(Frankfurt Stock Exchange uses a blockchain as a ledger for securities lending)
I think there could be a very powerful set of regulatory technologies created on top of blockchain style databases when used in conjunction with legally binding agreements intended to limit access to reads of the data.
Imagine a data lake for "enforcing" audit-ability of reads --
1. you may "store" some data in the lake -- say for example P2 2. if you "store" data in the lake you agree that you will not store that data anywhere else
"store" above would in actual implementation be something like storing a key for decrypting the data -- which could be stored wherever in an encrypted form and the agreement would mean "i'm not storing the key anywhere and i'm not storing the decrypting contents in any form other than as encrypted by the key".
You would leverage blockchain to ensure that all reads of the data are observable.
Obviously you can't "enforce" that the data being protected is not stored in other places or in other forms -- however the agreement "i will not store anywhere else" can be given legal or regulatory force to provide a way to punish violators.
The goal tho is to build a platform for explicitly acknowledging and communicating to both external auditors and the developers that "i'm not supposed to store this in other places". That's a technology problem which a lot of good faith implementors need help with solving ...
(I make no judgement on whether these sources of friction are worthwhile or not.)
Solve problems with the best solution, don’t start with a solution and then find problems
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))
Blockchain as a system (datastructure + PoW) solves consensus & trust between agents in a trust-less and censorship-resistant way (without introducing a trusted party).
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.
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.
However none of them would be caught dead calling themselves a "blockchain"
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.
The technology enables registration and tracking of the money in the system, including balances and transactions, for all users of the system at the same time. It is important to understand that if until recently the prevailing explanation was that blockchain technology has a right to exist only because of Bitcoin and other cryptocurrencies based on it, then the picture is much more rosy in terms of technology - it seems to accompany us in various walks of life.
Along with voices claiming that many resources are invested in the development of blockchain technology without the certainty that this technology will survive over time, there are many other voices heard across the globe, arguing that using blockchain technology is bringing the future to us and taking part in a revolution that will change our lives significantly .
Blockchain for food, real estate and health Thus, alongside cryptocurrencies, new uses for blockchain technology are currently being developed in various industries.
In the US, Walmart, the giant retail chain, has filed a patent application based on the use of blockchain technology that will allow the company to improve tracking of shipments in various aspects, including: location, temperature and delivery content. Sensitivity of some of the products shipped.
Other food giants, such as Nestle, Kroger and other companies in the food industry, have partnered with computing giant IBM to develop use of a blockchain system to improve food tracking.
The applications in the world also slide into the field of real estate and digital health, where developments leading to change have recently been presented, mainly in the way in which medical information will pass between the various factors.
In Israel, there are a number of companies, in various industries, that are looking to develop services and products based on blockchain technology -
Wave is developing a system that will make it possible to transfer and confirm bills of lading digitally, thus overcoming the need to bring the original document from the bank to the shipping company, as required today (a wider move is currently being made by IBM and logistics and shipping giant Marsk). Maritime trade).
QED-IT is developing a system that allows a claim to be tested in a database without revealing the content of the information itself. This allows the defense industry, for example, to test components without knowing their specific use.
BloxTax is developing a system that allows anyone to know exactly how much they have earned or lost on tokens or cryptocurrencies and to report to the tax authorities in accordance with the law, by collecting and weighting the data from the blockchain network.
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.
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?
1) A public ledger where each new entry includes the hash of the previous one, so you can efficiently attest to history and items cannot be silently removed from history, even if they're signed by the same participant. This is an old idea - Merkle trees are a slightly more advanced take on this idea. Present-day use cases, which are not blockchains in the conventional sense, include Git and Certificate Transparency.
2) A mechanism whereby the ability to add something to the blockchain requires the expenditure of computational power, as a way to solve the "double-spend" problem - namely, if you're storing financial accounts in your ledger, how do you make sure one person doesn't claim to transfer the same dollar to two different people? Bitcoin's innovation is to require some "proof of work" to record the operation and to make "miners" record operations (instead of participants adding things themselves), such that maintaining two branches of the ledger requires you to turn into the most powerful miner, which is computationally prohibitive.
You only have the double-spend problem if you have an object that cannot be used twice. Git does not have the double-spend problem because there's nothing wrong with having two commits branching off the same commit (in fact, it's quite common/encouraged). Certificate Transparency does not have the double-spend problem because CAs can sign an unlimited number of certificates, so if you see two different signed claims on two branches they're both valid. The two ledgers can be trivially merged together (unlike two branches of where money went).
Timestamping has the double-spend problem in its own way: either something happened or didn't happen on a day, and you don't want multiple, different records of what happened on that day. If I want to attest that something happened on June 1st, you need to be confident that I didn't make a second history that diverged at July 30 and merge it back in.
Most people do not have the double-spend problem. Fundamentally, you need a finite resource (like time or money) and you need to track the resource itself on the blockchain for the double-spend problem to exist.
A lot of people think a blockchain is useful for provenance tracking. But private records of provenance do not have the double-spend problem - you're not tracking the thing itself, you're tracking claims about where the thing was. If you see signed claims from me saying both "Lot X consists of high-grade steel that's been inspected" and "Lot X consists of faulty steel that needs to be discarded as scrap," you know I'm lying somehow. You don't need to arbitrarily pick one of those statements. (You actually don't want to arbitrarily pick one, because, again, the ledger here is just a record and not the thing itself: you want to get on my case for lying and find the truth. For the currency-itself use case of Bitcoin, it's fine to arbitrarily pick one.)
A lot of people are interested in so-called "permissioned blockchains" / "private blockchains." For the financial use cases, these usually don't have the double-spend problem because they're just a reconciliation layer on top of a slower payments system, and given a public record, you can just hold someone responsible for their double-spending, because again the ledger is just a record and not the thing itself. (This is largely similar to how "sidechains" like Lightning Network don't need to use the full complexity of the blockchain - because what they really are are records of promises to perform transactions on the primary blockchain. If someone makes two promises, hold them accountable for both.) For the non-financial use cases, you probably don't have anything resembling the double-spend problem in the first place: what you want is, at most, something like signed commits in Git.
There have been some growing pains, but it works.
Note: not interested in explaining what Urbit is, let alone fielding tedious political commentary about its departed founder. Just highlighting a successful non-currency use of a blockchain.
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.
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.
We're used to Venmo in the US but many places in the world don't have an equivalent. Valora is a new Venmo-like mobile app that's built on the Celo blockchain, a new network where mobile devices can efficiency sync with the chain, with a native stable coin, and a decentralized phone number verification protocol.
Check out https://valoraapp.com and https://celo.org
Similarly, an app called BeemIt, which is supported by the major banks here gives you a very similar experience, albeit with a prettier UI/UX. As it stands, there’s now no advantage that cryptocurrency offers in this space anymore IMO.
Maybe im just a stick in the mud, but i always thought it worked pretty great.
If I needed to move all of my money for some reason, I’d much, much rather just go through normal channels and not have to worry about the logistical and legal issues crypto currencies incur.
When you want to use a cryptocurrency to move money between monetary unions, you only have to touch the cryptocurrency for 20 minutes or less. Your chance of any meaningful volatility is very low, even in these systems, the 24/7 trading smoothes out the volatile periods. No, you don't "lose out on exchange rates" especially if you are talking any real money or know how to trade better.
An expected spread for a few million dollars with or Bitcoin or Ether should be 30 basis points, at an OTC desk.
No tax or legal issues encountered.
For payments I primarily use stablecoins like DAI, which are not volatile at all.
Whether you use stablecoins or the native cryptocurrency, it is all way less limiting and cheaper than any exchanges, way less limiting than a random fintech app with random monetary restrictions.
Your currency -> crypto, crypto -> destination currency are the two places you’ll suffer exchange rate losses.
> ... or know how to trade better.
Make a mistake, or you aren’t a trading wizard and you’re irrevocably out of luck though!
> it is all way less limiting and cheaper than any exchanges, way less limiting than a random fintech app with random monetary restrictions.
Until I later discover I’ve got pay tax on the gains or something later on and then have to sit down and work that out. Or that I had to declare it or something because I’m moving an amount above some threshold. Sure, it might take only 20 mins of everything goes nicely and you know exactly what you’re doing and someone doesn’t sneeze and tank the value of the currency out from underneath you, but I’m much happier going through proper channels where I at least know it’s going to work because it’s being done by people whose job it is to make it work.
Why would I use a stable coin, instead of just three fiat currency it’s backed by though?
For you to still write this means you don't know what a basis point is.
And to elaborate on all the random things you think you'll encounter means you didn't really understand a word I said.
My reality is valid, yours can be like mine if you started searching for solutions instead of rehashing outdated problems.
And if you want, stablecoins improve all of that. DAI is not backed by fiat currency specifically, although it can use other fiat-backed stablecoins as collateral.
Why this method over fiat? One reason off the top of my head is that I typically convert what would be an international wire into a domestic wire. So I inherit a lower compliance burden and also the same day settlement capability. I have the capability of avoiding exchange rate and interchange fees when that matters to me. Even apps like Revolut and Transferwise are more expensive and would still have transaction limits. They are also quite restrictive on businesses they will bank, compared to an actual bank, and this list often complies with a foreign standard (usually some carve-out of an EU/EFTA banking license)
A 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.
Digital assets will have their place alongside gold and diamonds in jewelry, and perhaps even entirely replace them.
A significant issue with gold and diamonds in jewelry is that the value is destroyed if the jewelry is lost or stolen. However, Bitcoin and other digital assets do not have this issue since a pointer to the value can be worn, not the value itself.
I made a site which promotes this idea in an open way: thebtcring.com
https://www.engadget.com/2015-05-21-a-bitcoin-engagement-rin...
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.
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