TL/DR: "If Byzantine Fault Tolerance [0] does not create a huge advantage for your use-case, it is unlikely blockchain makes sense to consider over a traditional database."
Though many new "blockchain" systems do achieve BFT (perhaps most notably Tendermint, which seems to be passing aphyr's Jepsen tests with flying colors), it's important to keep in mind Bitcoin falls short of achieving it:
"Regarding BA, we observe that Nakamoto’s suggestion falls short of solving it, and present a simple alternative which works assuming that the adversary’s hashing power is
bounded by 1/3."
One important difference between how a truly BFT system behaves versus Bitcoin is how Bitcoin handles network partitions, or rather, how it doesn't handle them.
Specifically, when Bitcoin goes split-brain, i.e. in the event of a network partition, Bitcoin will "reorg" into two new chains, both of which will happily accept writes from both sides. When the partition is healed, one chain will win, and the writes to the other chain will be clobbered. Ideally these transactions will wind up in the mempool again and be accepted into the new chain, but that isn't a guarantee, more of a band-aid, and doesn't change the fact the system ostensibly acknowledged a write it then lost.
There are ways to turn Bitcoin into a truly BFT system. The main one I like is decoupling proof-of-work from transaction processing, turning it into a leader election system for a more traditional BFT algorithm, such as ByzCoin:
With ByzCoin, if you can't reach quorum, you can't make progress, so in the event of a network partition the system will simply stop accepting writes if it can't reach quorum, as opposed to accepting writes which will go on to be clobbered by a future reorg.
> With ByzCoin, if you can't reach quorum, you can't make progress [...]
This may be a stupid questions, but how does such a system prevent me from adding new nodes, only to remove them all at once if I want to prevent the system from progressing?
The participants in the consensus group are selected via PoW. You would need to control > 1/3rd of them (i.e. 1/3rd of the nodes that have recently won the PoW leader election race/lottery) to cause Byzantine faults.
Not a bandaid at all. Unconfirmed transactions in the "lost" chain are bringing fees with them, so it is the exact same incentive of every other transaction.
Besides , how many times in history a continental network partition of the internet has happened?
And it would only take a single node connected to both sides (land and satellite?), to undo all the work of the would be attacker.
> how many times in history a continental network partition of the internet has happened?
Continental? No. Country-wide? Many, many times.
Imagine being in Egypt during the Arab Spring revolution when the government shut off Internet access. Imagine selling product to people for Bitcoin, seeing your client software accept the transaction because "enough time has passed", and then a few days/weeks later, when Internet access is restored, seeing your wallet balance get clobbered by the much-longer global chain.
And that is wrong AFAICT. PoW is what achieves Byzantine fault tolerance, not the blockchain.
What blockchain achieves is proof of history given only the latest block's hash. This might or might not have a PoW on top of it to achieve BFT.
Practical example:
An authoritative server which responds only with the latest block's hash (this is cheap, think microcontroller cheap) is another way to make a blockchain useful with no BFT. This way blockchain distribution can be offloaded to untrusted peers while the actual agreement is not distributed (and thus no DFT is involved).
EDIT:
Off the top of my head I can see a few applications of such an scheme: imagine a very low-power device taking mission-critical measurements. This device would periodically distribute a message consisting of (current block of measurements + previous message's hash) to untrusted high-power-large-storage clients. In case of any client desynchronizing it can request from its peers the measurement chain, and only has to receive the latest message from the low-power device to ensure the chain he got has not been tampered with.
That is not BFT because the source of truth is just an authoritative server. There is no distributed consensus even if there is distributed storage.
This is just semantics. "Blockchain" in the sense it's usually used means proof-of-work; hashing that incorporates the history tree predates blockchain and exists in things we wouldn't usually consider "blockchain", e.g. git.
It's unsurprising that discussig what a term means is just semantics ;)
Git is not a blockchain (it's a DAG) but that misses the point: I think the term could perfectly be retrofitted if it was the case. Things predating a term don't invalidate the new term convering them.
Either way I disagree with your opinion and there's nothing to argue further that would change either of our minds.
It really depends on the use case. In general, in the commercial world, we want to be able to have transactions/contracts that can't just be voided without consequence because one of the parties thought it was a good deal at the time but it turned out not to be. On the other hand, most legal systems aren't going to enforce contracts that have ruinous effects on someone because of a simple mistake or event that no one could have foreseen.
[0] https://en.wikipedia.org/wiki/Byzantine_fault_tolerance