I asked a few questions and he dodged them like a professional politician:
* what do you do if you need to reverse a transaction (lets say, court order)
* what if someone loses his wallet/password
* some people claims blockchain is over-hyped
He said that I being skeptical proves my ignorance and I should study more about the subject instead of challenge him.
Remembered the short tale "The Emperor's new clothes", I'm unable to see the king's clothes because they are made of a magic fabric invisible to the stupid. I guess the magic fabric is made of blockchain.
So if there's a danger of forgery, or you have an interest in security, a blockchain with proof of work provides a really trustworthy way to know you're getting authentic data, because you can look at the chain, and know things like it would cost about 100,000,000 to forge this full history, and 1,000,000 to forge to last block.
Might be just my misinterpretation, but when I hear blockchain I usually just think of conventional totally trustless and identity-less protocols that necessarily require proof-of-work - which is a security level which is not needed for most applications.
Pardon my ignorance, but isn’t that what a blockchain is?
This is a handy reference to decide if you're building a cryptographic ledger or a blockchain: https://gist.github.com/joepie91/e49d2bdc9dfec4adc9da8a8434f...
In addition to this github gist, I like http://doyouneedablockchain.com/ .
The key innovation of the blockchain was the use of proof-of-work in order to associate an amount of computer-time with a given block, and then pick, from competing views of a blockchain, which view took the most energy to arrive at... all while being resistant to a small number of subversive actors.
In short, the blockchain solved the Byzantine Generals’ Problem, and happened to use a append-only cryptographic ledger as part of it.
Correct. In other words, proof of work is only a tool to make everybody slow in producing data while keeping everybody fast in verifying it.
> In short, the blockchain solved the Byzantine Generals’ Problem,
No. It's a common misconception, but in fact it does not solve Byzantine generals problem, with the simplest reason being that the problem requires the solving protocol to terminate (blockchain does no such thing).
> and happened to use a append-only cryptographic ledger as part of it.
The correct terminology is not "ledger", but "document timestamping". You don't need to record transactions in blockchain, they can be any statements. Cryptographers already had such systems, except that each of those required trusted third party to produce timestamps.
One implementation of it, google's, uses leveldb:
https://github.com/google/certificate-transparency
Another one out there uses postgres. It turns out that you can use traditional databases in many cases where you think you need a blockchain, and you'll be able to waste vastly less energy on proof-of-work and vastly less time dealing with the terrible mess that is "blockchain".
The reason not to use "blockchain" is that it has 200 definitions, all of them full of people trying to get rich, not getting things done.
Databases have long-since solved the problem of storing and distributing data.
Distributed stores like etcd, zookeeper, and so on have long since solved the problem of duplicating data.
Very few people need byzentine fault tolerance (due to having a large number of untrusted actors with write access), which is the only time the additional complexity blockchain includes is actually useful
Hence we shall issue signed receipts to all clients and providers then setup a system to pay out a large bounty if someone can produce a signed receipt not in our weekly-published-log. We'll automate the bounty, but perhaps a third party will also offer a validator. We will not even need Postgres for it, just nginx and a filesystem.
But that is not interesting enough by itself, and mentioning digital signatures just confuses people more. So we call it a Single-Issuer-Blockchain: Now people instantly get the idea.
In my case, this sentiment accompanies an implementation in the form of an easily-deployable open source microservice.
https://github.com/paragonie/chronicle
If it's too hard for people to build, they can use what I wrote.
> What is this hypothetical non-blockchain, where are you going to get it, and why not just use a blockchain if that's what you need?
That's the tx/s limit on Bitcoin today? I can do hundreds of writes per seconds to Chronicle on a modest VM without sweat. This is possible because it's centralized, albeit supports mirroring (i.e. replication) and cross-signing.
...
Are people still fighting about this or have they come to a consensus?
I'm probably the worst person to represent whether there's a consensus or not since I'm one of the designers of Ripple. But the important thing, at least in my opinion, is that there is no "secret sauce".
The software is open source. People are free to modify it however they please. We run the exact same software that we make available on our public servers and our validators. Others are free to run validators and they do so.
As it happens, much of the network infrastructure is run by us today. But we are more than happy to turn that over to others who are willing to do it.
Why do you care if something is decentralized? The main reason is usually that you don't want the users of the system to be forced to accept changes made by an owner/operator of the system whose interest may be averse to them. Ripple is decentralized in this sense.
For example, eBay is not decentralized. They don't warehouse their goods. But if eBay the company says no auctions of adult merchandise, then there will be no such auctions. It wouldn't matter if every user disagreed with the policy. Their only recourse would be to re-create what eBay had done, that is, to themselves implement eBay's secret sauce.
By contrast, Ripple has no secret sauce. Anyone can run their own servers. If we make changes people don't like, nothing requires them to run the code with those changes. If Ripple disappeared and users of the ledger wanted it to continue, nothing would stop them from continuing it.
https://bitcoin.stackexchange.com/questions/40448/is-ripple-...
It's way more like Certificate Transparency than Ripple. Chronicle has nothing to do with payments or currency. It's just a ledger.
Writing data to the blockchain solves this problem, but the cost is large and performance is dismal.
Writing hashes to the blockchain at specified intervals, delivers proof of existence, at an acceptable cost and performance, but does not really make sure the data itself will survive its original author.
Is there another way? Can chronicle help?
I've had meetings with prospective clients that opened with, "We have $problem, can we use blockchain to solve it?" where anything that doesn't qualify as a blockchain is cast to the wayside because it doesn't scratch that buzzword itch.
(Amusingly, I've witnessed one pitch where the person called it "bitchain" and it sounded like "ba-ching!" and I was waiting for the follow-up to what I thought was onomatopoeia for a cash register sound. I've since learned to not abbreviate cryptography as "crypto" lest I attract sketchy prospects.)
A lot of the problems that you might want to solve with a blockchain probably doesn't need a blockchain. A distributed, append-only cryptographic ledger will suffice. To wit: https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...