Topic: Satoshi didn't solve the Byzantine generals problem - page 8. (Read 13675 times)

I should have written 'fault' instead of failure. Nonetheless, byzantine faults can arise due to latency, or a malicious node - I wasn't describing an attack scenario specifically, just defining how the byzantine consensus applies to bitcoin.

We can't count the components because identities can be Sybil attacked.

But more saliently since I know your retort would be that hashrate is the count, you seem to be going in circles because you ignore what I already wrote:


You guys are like a dog chasing its tail.

Only correctly functioning nodes do that.


Not really, those are just evidence of latency. If a majority of the CPU power is conspiring to attack the system and all non-cospirator blocks are orphaned then no one will mine outside the conspiracy and there will be no such orphans (there may still be forks within the conspiracy if they still have latency).

The system will have failed, but it will have failed because it exceeded stated limits.

 

Bitcoin employs an amortized byzantine consensus. Nodes vote with their hash-power on the branch of the chain which they consider to be truth. Evidence of byzantine failures is the existence of multiple branches; we call these orphans. Each branch presents a different version of truth to observers of the system.

"Correctly functioning components of a Byzantine fault tolerant system will be able to provide the system's service, assuming there are not too many faulty components."

In Bitcoin "too many faulty components" = majority of the CPU power.

monsterer and smooth, I repeat again, how do you prove if a 51% attack is censoring transactions? In other words, how do you even detect it in an objective and provable manner?

A system which doesn't objectively (from the perspective of all observers) know when it is failing is not Byzantine fault tolerant.

Refer again to the Wikipedia definitions:


This circular logic of yours is getting redundant. I have made my point and you have not refuted it.

This only works because Chinese miners have a majority of the CPU power. Otherwise you call them up all you want, but would accomplish nothing. You might as well call someone with an old USB miner stick.

There are no censored transactions unless a majority of the CPU power* is conspiring to attack the system.

Bitcoin has a threshold of hostile CPU power that it can tolerate. Below that threshold, it works, above that threshold, it fails.

* selfish mining, etc.

Only a 51% attack can censor transactions 100%, any less will just delay them as the honest majority of miners will include transactions which the dishonest minority has censored. Again, this all is within the bounds of the tolerance of the protocol.

This is an immensely valuable topic to understand as deeply and completely as possible.  It would be good to refrain from using any offensive language -- it is possible and often common to misunderstand other points of view.  Let's get the papers written and distributed for the community to evaluate.  If the ideas are sound then hopefully they will be embraced.  If they are not then hopefully they can made be made sound or abandoned accordingly.

Membership: I stood up a full node (non-mining) without any registration with a central authority.  I trusted the software (weak on my part personally but do have at least one person I do personally know very well (my son) building from sources) and the technique it uses to find the "real" Bitcoin network.  I do compare my full node state from time to time with the "public" state as reported at Blockchain.info et al -- although I have become complacent over time.  I feel confident so far but understand that this might bite me in the future.

An ASCI-resistant PoW does seem valuable to me.  Is memory latency the right barrier to stand upon for the ages?  For example, is http://community.hpe.com/t5/Behind-the-scenes-Labs/The-Machine-HP-Labs-launches-a-bold-new-research-initiative-to/ba-p/6793690#.VreSn2b2aUk relevant?  Doesn't cache size eventually eliminate the memory latency issue?  Perhaps the problem size (not just difficulty) can be increased as blocks come in faster and faster?

Go ahead. Find a way to put me down. I dare you all!

Fuck I am tired of this forum.

So if the LCR is creating censored transactions is that not a fault/failure? What the hell use of Byzantine fault tolerance if it doesn't guarantee a system that can be used by the participants?


Loss of Access is a failure. CAP theorem applies.

In bitcoin, faulty nodes = sybil nodes.

A byzantine fault in bitcoin is a fork.


A poor conclusion. LCR provides the objectivity; branches which get orphaned were objectively selected against as being byzantine faulty.

Because as I explained to monsterer in the prior post, Satoshi's design is ambiguous about Byzantine faults such as censoring transactions and thus it does not solve the BGP.

And because I assert there are other ways to organize a PoW block chain design so that some of those faults can be objectively identified and reacted to (e.g. the fault of censoring transactions). The fact that in Satoshi's design these faults can't even be objectively identified (and the Sybil attack on pools is another one that destroys any objectivity), then there is no recourse other than for the system to centralize and fail. Pool centralization is increasing despite the move away from pools that had too much hashrate (and the linked data doesn't even account for the Sybil attack we can't see).

Satoshi's PoW does not distinguish between faulty and non-faulty nodes.


There is no way to distinguish a 51% attack from a non-attack, e.g. for example censoring transactions, in a way that is provable with block chain data (i.e. to an offline node that comes online). One of the key innovations in my design, is it is possible for a payer to send his PoW share away from a "pool" (not example the same as pool in Bitcoin) that is provably (from that payer's individual perspective) responsible for censoring the transaction.

Since nothing about faults is provable from the block chain, then there is no provable Consistency (w.r.t. to what loyal nodes would consider a fault, e.g. censoring txns) and thus the BGP has not been solved.

We use community monitoring to estimate that we have Consistency, but this can't be proven objectively just from the block chain. We must correlate user experiences and other data points such as pool concentration.

A Sybil attack against the means by which loyal participants determine whether 51% control has been perhaps ceded to pools removes one of the key data points.

So we can conclude Bitcoin didn't solve BGP because there is no block chain objectivity about faults. And then we can say that Sybil attacks on pools destroy one of our subjective metrics for community appraisal of Consistency.

In bitcoin, BGP is solved to within the stated tolerance of 51% byzantine faulty nodes.

Incorrect again.

BGP is not solved if there is Sybil attack vulnerability. The following is not "other attack" but rather it is a Byzantine fault (because the loyal participants can't be certain of Consistency by keeping the control of the hashrate below 51%). Since you have no way to know which pools are controlled by the same entity and thus which pools have the lowest VERIFICATION costs per block reward (which is very important once you scale Bitcoin to Visa scale), then you have no way to know where to send your PoW shares so as to prevent that Sybil attacker from leeching off of the other pools and driving them bankrupt thus centralizing all pools under one control but hidden by a Sybil attack. In other words, the system is GUARANTEED to become 51% attacked due to the economics and the fact that control can be hidden behind a Sybil attack.

I wrote that already upthread and you just don't read apparently.

You do not understand basic issues.

A 51% attacker can put any time he wants in the block chain.

Honest nodes can sync to a global clock, but this is not guaranteed to be accurate unless an offline node can later prove that the chain was not generated by a 51% attack on the clock records. And of course there is no objective way to prove this, other than trusting the community. And so then you lose the objective, trustless quality.

This is fundamental and if you don't understand this, then you are not qualified as a block chain expert. Block chains are only objective relative to blocks. Period.

Sorry you lose again. And I know damn well the underhanded methods you are employing to try to discredit me and sorry you will lose.

TPTB, your style is not productive. I'm putting you on ignore, since you seem to have no intention in engaging in meaningful dialogue.

To answer this:

"Incorrect. It only proves some information existed at a certain block. There is no way to put a clock time in the block chain."

Blocks are of course timestamped with actual UTC timestamp from the node that generates it, and then validated by other nodes. Below is the code in the 0.0.1 version. The timestamp mechanism is the entire point of adjusting difficulty through time. Otherwise the PoW would be worthless. For more accuracy atomic clocks via NTP could be used. Without the timestamp nothing in Bitcoin works (that's the double-spend problem).

See also: http://szabo.best.vwh.net/distributed.html#Secure Time-stamping,
http://szabo.best.vwh.net/distributed.html#The Byzantine Generals Problem
http://web.archive.org/web/20090309175840/http://www.bitcoin.org/byzantine.html

where all this is explained in relation to BGP (more accurate would be the term logical broadcast).

---

https://github.com/benjyz/bitcoinArchive/blob/eabf96b83e7608bff0149dc1fbaee1dd844429c8/bitcoin0.1/src/main.cpp#L1163


https://github.com/benjyz/bitcoinArchive/blob/eabf96b83e7608bff0149dc1fbaee1dd844429c8/bitcoin0.1/src/util.cpp#L320

Incorrect. It only proves some information existed at a certain block. There is no way to put[objectively prove] a clock time in the block chain.


Incorrect. A longest-chain-rule (LCR) block chain records non-conflicting state transformations. That isn't limited to a ledger of ownership.


Incorrect. A block chain can distribute tokens. That doesn't guarantee anything about it becoming a currency and being immune to nation state armies. If not immune (i.e. not defensible against), then 'without' is incorrect. (it doesn't even guarantee the distribution won't be centralized by mining farms)


Again you are pigeon-holing what a block chain does. Again a longest-chain-rule (LCR) block chain records non-conflicting state transformations.


Thanks for ignoring my progress and thereby insinuating my sharing/progress has been noise.


I appear to be reasonably skilled at distilling to the generative essence and I will assert that there isn't a large space of possible designs that will work to eliminate the centralization issue. Mine seems to be the only possible one.


Now that is noise or at least veering very far from a solution to the problem this thread raises.