Quote from: TPTB_need_war on February 09, 2016, 01:39:54 PM

Quote from: smooth on February 09, 2016, 12:22:07 PM

Quote from: TPTB_need_war on February 09, 2016, 12:11:21 PM

Quote from: smooth on February 09, 2016, 11:38:12 AM

Quote from: TPTB_need_war on February 09, 2016, 11:31:46 AM

Whereas, with a quantified probability of traitors (e.g. hardware MTBF), the risk of Byzantine fault is computed. Which was the intent of Lamport et al's paper.

That's not really the case. Read the paper more carefully. Simple probabilistic hardware failure is easy to cope with using redundancy and majority voting. The hard problem is failures that are more subtle and complex, which can mimic deception and collusion.

The algorithm becomes a tool in a toolbox which is used to improve robustness against certain types of failures, but the robustness is still never absolute, and in real systems the actual probability of failure is still not known.

I suggest you also read the paper more carefully. Specifically Section "6. Reliable Systems" which we are referring to.

What it says is that as the hardware fails the outputs can become like traitor inputs to other hardware components causing the cascade to lie, which is precisely the BGP problem and what the solution is modeling by a count of traitors (passing along a traitor's lie doesn't create a new traitor). Even in the case where the derivative computation is corrupted due to the corrupted input, this is still a quantified probability of cascade of traitors obtainable from engineering and math/models applied from hardware MTBF rates. It is more exact science or estimation than not knowing. There is no decentralization, Sybil attacked introduced which otherwise makes the estimation highly unknowable and unmeasurable (science requires measurement to validate that models are predictive).

The examples in the paper are toy examples. Now consider a real system with many interconnected computers each running million or billions of lines of code. Passing along a lie does not create a new traitor, but responding incorrectly to an unexpected input does create new traitors. So it is very difficult to ever know how many Manchurian Candidate traitors exist, ready to be triggered.

Of course you are not omniscient to know this can't be modeled in any applications of the solution. I am quite confident models apply in real world use cases.

I'm of course not claiming there are no devices that are simple enough to analyze in that manner, but it is a small subset of consensus systems today.

And what we are seeing in the real world more and more is that even safety-critical systems are relying on increasingly-intractable mountains of code, with testing, process certification, redundancy and fault tolerance used to reduce failures to an "acceptable" level.

Anyway, I think we agree for the most part, largely disagreeing on matters of terminology and (in the case of Bitcoin) probability of future failure.

And the discussion has become repetitive.

So, I'll bow out of this thread for now, especially if you are ignoring monsterer who is largely correct (though also may have a slightly different perspective)