Satoshi didn't solve the Byzantine generals problem

[TPTB_need_war]

I am saying that in a decentralized, trustless, Sybil-attackable scenario, there is also no conditional solution to BGP, because the participants have no way to conjecture the probabilities of 51% attack

We'll have to agree to disagree. As long as I can write down a solution, and write down the condition under which it applies, then I consider that a conditional solution. I do not need to state a probability that such a condition will be satisfied.

What use is a condition if it can't be measured?

The Lamport paper was aimed at hardware MTBF rates which can indeed be measured and verified.

I am into engineering. I guess you prefer black magic and voodoo (and I am from New Orleans, lol).

(nor does any solution to BGP provide all participants a consistent, provable observation when the system state is attacked).

I agree with this part.

Thanks. It is unarguable fact.

The condition of count of traitors has only utility in applications where the probabilistic rate of traitors can be conjectured.

Utility is necessarily subjective. Also, ability to conjecture a probability is subjective.

Incorrect. MTBF rates for hardware are objective engineering measurements. Seems you are referring to "feelings", "speculation" or something other than engineering.

I have also I think argued convincingly that Satoshi's PoW design (and every decentralized consensus design) must trend towards and rely on centralization. Thus the asymptotic probability of 51% attack is ~1.

See there, you just conjectured one!

Others likely conjecture a different one.

No I provided an overview of what can be put into a mathematical proof. That is objective engineering, not conjecture.

The asymptotic probability can be described quantitatively because of the inviolable economics (which derive from CAP theorem but we can prove just from the economic realities).

Though Bitcoin does have a somewhat nice recovery property in that the failure only persists as long as 50% of the CPU power is conspiring to attack it. Unlike, an airplane for example. If too many components "temporarily" fail, then it may be catastrophically disassembled before they recover.

I can think of scenarios where that isn't necessarily true. For example, such an attack convinces speculators that the attack can be repeated at-will and so they flee the coin. Crash and burn.

The system can still recover. There is no catastrophic disassembly.

Non-sequitor.

You will never convince all the speculators to leave either. It is a bit like infinite divisibility. You have infinite reducibility of speculative value. Altcoin at #1000 in market cap still has a (tiny) value, there is still a (tiny) incentive to mine, and its blockchain still functions.

For all intent & purposes, shitcoins that have $10 floats are dead and will fully die eventually.

[TPTB_need_war]

Just because you cannot quantify the number of traitors does not mean the system will produce invalid results within the bounds. This is true of any BGP consensus and has absolutely nothing to do with trustless, decentralised solutions.

For Christ's sake, you cause me to repeat all the points I made upthread over and over again.

I already explained to you invalid results where the observers can't know whether the state was attacked or not, which is a Byzantine fault! There is no way to compute this risk and in fact the asymptotic risk is 100% (probability = ~1) because all decentralized consensus systems must centralize (which I explained in detail upthread).

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.

Your points are irrelevant, you don't understand the problem as stated. You are desperately clinging to wikipedia definitions in an attempt to save face, when the honest thing would be to admit your mistake; no one will judge you for it.

You are delusional. Well beyond delusional to blinded by your anger and desire for me to be wrong. Sorry you are wrong monsterer, just as you were wrong in the other thread (and peskered me endlessly).

[smooth]

I am saying that in a decentralized, trustless, Sybil-attackable scenario, there is also no conditional solution to BGP, because the participants have no way to conjecture the probabilities of 51% attack

We'll have to agree to disagree. As long as I can write down a solution, and write down the condition under which it applies, then I consider that a conditional solution. I do not need to state a probability that such a condition will be satisfied.

What use is a condition if it can't be measured?

The entire construction is an exercise in theoretical computer science, i.e. mathematics. You state a problem and you solve it. In this case (as in many others), the solution has necessary conditions.

It also happens to have some practical applications. Some of those involve measuring or estimating probabilities, some may not. An example of the latter would be comparing two available solutions to the same problem, where the input probability is unknown, but one solution or the other must be chosen. In that case you would very likely choose the solution with the weaker necessary condition (or at least you would consider that against cost).

I'm not going to respond to the rest of your message because I think it basically comes down to you being convinced that economics will certainly cause a permanent centralization of Bitcoin (which is effectively >1/3 or 50% collusion), and it will therefore fail. That's a fair belief, and I consider it a very significant probability, but I don't share your belief in the certainty of it.

[TPTB_need_war]

Just because you cannot quantify the number of traitors does not mean the system will produce invalid results within the bounds. This is true of any BGP consensus and has absolutely nothing to do with trustless, decentralised solutions.

For Christ's sake, you cause me to repeat all the points I made upthread over and over again.

I already explained to you invalid results where the observers can't know whether the state was attacked or not, which is a Byzantine fault! There is no way to compute this risk and in fact the asymptotic risk is 100% (probability = ~1) because all decentralized consensus systems must centralize (which I explained in detail upthread).

You keep linking that page, and you keep ignoring the statement on that page that says "assuming there are not too many faulty components"

I am not ignoring it. You are ignoring the point that the condition on count of traitors is unknowable from any sane engineering estimation (which btw is why the point about Sybil attacked pools is relevant) and thus no state of the decentralized, trustless consensus system (Satoshi's variant when conjectured to be decentralized, trustless) can ever be distinguished from a Byzantine fault, regardless whether the condition threshold has been reached or not.

Your myopia Bill, is that (you smoked too much MJ and) when an inestimable condition for Byzantine fault tolerance is COMBINED with inability to observe faults consistently among all observers, then no state is trustworthy (which fails the goal of the solution). The "solution" collapses into a non-solution in the decentralized, trustless context.

Hopefully you will finally admit it.

[smooth]

Just because you cannot quantify the number of traitors does not mean the system will produce invalid results within the bounds. This is true of any BGP consensus and has absolutely nothing to do with trustless, decentralised solutions.

For Christ's sake, you cause me to repeat all the points I made upthread over and over again.

I already explained to you invalid results where the observers can't know whether the state was attacked or not, which is a Byzantine fault! There is no way to compute this risk and in fact the asymptotic risk is 100% (probability = ~1) because all decentralized consensus systems must centralize (which I explained in detail upthread).

You keep linking that page, and you keep ignoring the statement on that page that says "assuming there are not too many faulty components"

I am not ignoring it. You are ignoring the point that the condition on count of traitors is unknowable from any sane engineering estimation and thus no state of the decentralized, trustless consensus system (Satoshi's variant when conjectured to be decentralized, trustless) can ever be distinguished from a Byzantine fault, regardless whether the condition threshold has been reached or not.

That is true even if you can estimate probabilities. There will still be some probability of faults (which may different from your possibly-incorrect estimate, but even if not) that exceed the tolerance and those are not detectable. Generals then charge off to their deaths.

And in reality, in the case of Bitcoin, you do estimate a probability (as being close to 1) and so does everyone else (a range, not all close to 1). That is at the root of why you think it is not a solution. It has nothing to do with the solution to the BGP, which is a mathematical construction that may or may not apply to Bitcoin (I still don't know).

[monsterer]

when an inestimable condition for Byzantine fault tolerance is COMBINED with inability to observe faults consistently among all observers, then no state is trustworthy

Your first point is irrelevant because that is the natural state for any byzantine system that we are concerned with. The second point is just plain incorrect, because a byzantine fault is a fork in bitcoin, and all observers can see the fork.

[smooth]

We covered this earlier monsterer, but I don't agree that observers can necessarily see the fault. If mining is centralized and no one outside of the collusion mines (because it is not economically viable to do so), then there will be no forks.

However, it is accurate to say that if we know there are miners who aren't part of a collusion and we don't see forks that exceed those accounted for by natural propagation, then there is no attack.

I believe the bolded condition is a near certainty today, and the italic condition is very likely true.

Therefore Bitcoin is solving (something like) BGP for the moment.

Analyzing the present based on available evidence is the only objective statement anyone can make on the matter. Speculations about the future are just that.

[TPTB_need_war]

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).

[smooth]

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. Byzantine fault tolerance is used because it allows robustness against complex failures to a greater degree than simple majority voting, even when the components are not simple bits of hardware with an easily-quantifiable MTBF (which are often bullshit, BTW).

Anyway, it turns out that monsterer is actually correct, and failures are observable in Bitcoin after all. You can't censor transactions without controlling either all the miners or creating forks. As long as neither condition is observed we know it hasn't failed.

[TPTB_need_war]

when an inestimable condition for Byzantine fault tolerance is COMBINED with inability to observe faults consistently among all observers, then no state is trustworthy

Your first point is irrelevant because that is the natural state for any byzantine system that we are concerned with. The second point is just plain incorrect, because a byzantine fault is a fork in bitcoin, and all observers can see the fork.

"an inestimable condition for Byzantine fault tolerance" is not an natural state of all applications of byzantine systems as I have explained for example for modeling hardware.

"inability to observe faults consistently among all observers" is correct and is inarguable for BGP as already explained and to which even smooth agreed.

Readers must I continue to refute monsterer because this is impinging on my time? He has been wrong on ever post in this thread lately. I think it is time to put him on Ignore.

Orphaned chains (not sustained forks!) are a natural and can't be proven to be an attack. Even those longer-con chains which orphan another chain which do not fall within the expected variance due to natural orphan rate can't be distinguished from natural (non-attack) network connectivity issues. Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation. Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

Fuck man, you can't even keep all the concepts in your head from the past discussions!

We covered this earlier monsterer, but I don't agree that observers can necessarily see the fault. If mining is centralized and no one outside of the collusion mines (because it is not economically viable to do so), then there will be no forks.

However, it is accurate to say that if we know there are miners who aren't part of a collusion and we don't see forks that exceed those accounted for by natural propagation, then there is no attack.

Sorry smooth none of that shit is true per what I wrote above to monsterer.

Besides collusion is unknowable due to Sybil attacks.

You guys are chasing your tails in circles.

I believe the bolded condition is a near certainty today, and the italic condition is very likely true.

Therefore Bitcoin is solving (something like) BGP for the moment.

Analyzing the present based on available evidence is the only objective statement anyone can make on the matter.

Nonsense. There is no objective evidence in longest chain rule other than the longest chain. Period.

Anyway, it turns out that monsterer is actually correct, and failures are observable in Bitcoin after all. You can't censor transactions without controlling either all the miners or creating forks. As long as neither condition is observed we know it hasn't failed.

Nonsense all. monsterer isn't correct.

Attacker only needs 51% of hashrate to censor transactions perpetually (and less % to delay transactions).

There is no (sustained) fork in the longest chain rule.

[smooth]

Besides collusion is unknowable due to Sybil attacks.

Collusion to do what?

You can collude to attack, but that would be visible.

If you collude with a bunch of other miners to pick each other's noses, okay, maybe we can't see that, but I don't care. That isn't an attack.

Attacker only needs 51% of hashrate to censor transactions perpetually (and less % to delay transactions).

To censor, he has to orphan other miner's blocks that do include the transactions. That is visible.

[TPTB_need_war]

You can collude to attack, but that would be visible.

Nope.

Please re-read my prior post.

[smooth]

You can collude to attack, but that would be visible.

Nope.

Please re-read my prior post.

Attacker only needs 51% of hashrate to censor transactions perpetually (and less % to delay transactions).

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible. Delaying is possible without creating forks. Censorship is not.

[Come-from-Beyond]

You can collude to attack, but that would be visible.

It depends on number of colluding entities.

[TPTB_need_war]

You can collude to attack, but that would be visible.

Nope.

Please re-read my prior post.

Attacker only needs 51% of hashrate to censor transactions perpetually (and less % to delay transactions).

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible. Delaying is possible without creating forks. Censorship is not.

I had to teach monsterer that your assumption is incorrect. Why don't you ask him about our prior discussion in the Decentralization thread on this topic:

Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation. Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

[Come-from-Beyond]

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible.

This requires to assume that we all see and believe this. Right now chinese speculators can bribe a small pool to generate 10 consecutive orphaned blocks and start spreading FUD that someone tried to attack Bitcoin. With intention to buy cheap coins.

EDIT: Forgot the obvious resume. https://en.wikipedia.org/wiki/Plausible_deniability guarantees that a real attack will likely be not noticed, people will just spread the idea that it's a fake attack.

[smooth]

You can collude to attack, but that would be visible.

It depends on number of colluding entities.

I didn't read that but the point is that you can't engage in an attack without creating forks, as monsterer said. The forks are visible. They would exceed those explainable by propagation delays, and would be selective against miners who include the banned transactions.

Collusion, in fact, doesn't even matter. It could be one large miner or a collusion. Either way it will be visible unless the collusion is total (maybe that is what your link states).

You would also, even in the case of total collusion, see transactions staying in the mempool forever despite having higher fees than transactions being mined. We don't see that either. There is no attack taking place. For the moment.

[TPTB_need_war]

You can collude to attack, but that would be visible.

It depends on number of colluding entities.

I didn't read that but the point is that you can't engage in an attack without creating forks, as monsterer said. The forks are visible. They would exceed those explainable by propagation delays, and would be selective against miners who include the banned transactions.

Are you blind?

Orphaned chains (not sustained forks!) are a natural and can't be proven to be an attack. Even those longer-con chains which orphan another chain which do not fall within the expected variance due to natural orphan rate can't be distinguished from natural (non-attack) network connectivity issues. Also I already explained upthread that an emphemeral fork (which orphans another chain) can't be blamed for a double-spend or censored transaction, because there is no provable correlation. Seems you've forgotten where I had to teach you in my Decentralized thread why it is impossible for a minority chain to prove anything (because the state of the chain is never absolute w.r.t. to any external chain/clock and is always moving forward). Which is the same analogous mistake enet made upthread.

[smooth]

To censor, he has to orphan other miners' blocks that do include the transactions. That is visible.

This requires to assume that we all see and believe this. Right now chinese speculators can bribe a small pool to generate 10 consecutive orphaned blocks and start spreading FUD that someone tried to attack Bitcoin. With intention to buy cheap coins.

Wow, such horrible logic.

You can not know an attack did take place, because the forks could be a ruse, yes.

But you can know that an attack did not take place because there is no such fork anywhere in existence.

Unless you believe that all miners are colluding. I don't believe that. Even then, censorship would leave the censored transactions in the mempool.

@TPTB you are falling into the same logic trap as CfB. Proving an attack is not the same as proving the lack of an attack.

But...we certainly can't know there won't be an attack tomorrow, or the day after, or any other time. That is not only true, but clearly implied by the wording of the white paper.

People need to decide whether they can live with that risk or not.

[Come-from-Beyond]

Wow, such horrible logic.

You can not know an attack did take place, because the forks could be a ruse, yes.

But you can know that an attack did not take place because there is no such fork anywhere in existence.

You are right, sorry, I'm coding at this moment and my brain resources are not enough for taking part in your discussion at the same time. See you some other day.