Topic: A World of Trust – eMunie Consensus Primer - page 3. (Read 7372 times)

You can prove that the average of all random numbers between 0 and 1 is exactly 0.5 without averaging every possible number. That is the definition of a 'proof'

If you started with two groups, how could they rejoin?


Generally by people with a lot to lose if it isn't.

You can't prove that without iteration through all possible alternatives. Even unknown yet.

Indeed it appears his system needs to be modeled as a complex state machine.

You can't just make a claim out-of-context that an "honest" majority of the trust reputation will decide the winner of a double-spend. You have to model the state machine holistically before you can make any claim.

Proof-of-work eliminates that requirement because each new iteration of a block solution is independent (trials, often simplistically modeled as a Poisson distribution) from the prior one (except to some small extent in selfish mining which is also easily modeled with a few equations). See the selfish-mining paper for the state machine and then imagine how complex the model for his design will be.

This is independence is what I mean when I say the entropy of PoW is open (unbounded), while it is closed for PoS.[1]

[1]	https://bitcointalksearch.org/topic/m.12242278 https://bitcointalksearch.org/topic/m.12227357

Imagine this highly technical discussion comparing PoW and PoS can't happen in the Bitcoin Technical & Discussion forum, because the overlord Gregory Maxwell moves it to the Altcoin Discussion thread.

And what happens when some edge case means that the 4 are not aware of their previous connections to the other 11?

This kind of reactionary design is very fragile because it relies on state transitions. If you start from scratch with two groups, one of 5, one of 11 which operate independently (for whatever reason), forming separate valid consensuses but are supposed to be on the same network, what happens when they rejoin?


In POW the votes are the blocks. The chain with the most votes becomes the canonical chain. The reason for this choice is that it is very robust, simple and doesn't rely on any state transition, reactionary design and is resistant to sybil attack.

It has been argued that POW is ,in fact, *the only* solution to the byzantine generals problem:

https://gist.github.com/oleganza/8cc921e48f396515c6d6

Network topology splits are handled in exactly the same way as malicious actors.  

Byzantine agreement protocols can not determine if a node is faulty, or dishonest.  Non-response may be for a number of reasons, a node may be faulty and cant not respond, it may be offline, or it may be choosing not to respond as its dishonest.

BA protocols regard all of these cases as a failure, and providing that less than (n/3)-1 failure occur at the same time, an agreement can still be met.

A fork/network partition/split-brain whatever you want to call it doesn't violate or hinder the operation of the majority providing the failure % is within bounds.  In the case of a true BA protocol, the split partition may be able to continue operating for a short period of time after the fact, but will not be able to operate indefinitely.

For example:  

Assume there is a network of 15 nodes and active traffic.  

4 of these nodes suddenly loose communication from the other 11, but can communicate between themselves. These 4 nodes will likely get "stuck" immediately.  They are not able to achieve a majority regarding any pending committals as they are not able to receive the votes from the other 11 voters.

Even in the case where there are no committals pending, or active traffic, the split of 4 will be aware that something is amiss upon one of them presenting a new transaction, as the set of nodes those 4 expects to acknowledge the next transaction, 11 will not respond.

While the original network regards the sudden non-response of these nodes as failures, it is below the maximum of (n/3)-1, and can continue operating.  The network split containing 4 nodes regards the sudden non-response of 11 nodes as a critical issue as there has been > than (n/3)-1 failures which is easily detectable.  That split network can then act accordingly, pausing operation and perhaps even informing users of the sudden critical issue until reconnection to the main network partition.

In this scenario there is no "data fork/split" because the failed group can not proceed unless they all decide to, which in most BA protocols, is not the case.  This means that this group can rejoin the main network partition at any point, be given the information they need to achieve data correctness with the majority, and continue operation as before.  No rollbacks, no re-organizing.

This IMO is a critical issue that proves block chains & POW are not truly Byzantine tolerant, because there isn't a majority agreement that can prevent changes to history.  Bitcoin's use of POW results in an asynchronous network, as there is no mechanism to vote and thus prevent historical changes, and it has been proven that asyncronous networks can not tolerate even 1 Byzantine failure.  

In Bitcoin's case the single Byzantine failure is when someone produces a Proof of Work that exceeds the one currently in place.  In essence by presenting it, they are disagreeing with the rest of the network about what the state should be, and thus it can be classed as a Byzantine failure.

The network split I was referring to was a not a malicious one, but a topological one. If one group of nodes becomes disconnected from the rest, they will form their own completely valid consensus within their own group, creating a fork. When they re-join the network, the fork will need resolving somehow?

This kind of forking will happen all the time due to network latency, the topological split is the extreme case.

Not true, while Byzantine solutions typically employ some form of elected "leader", or have a predetermined static set of trusted nodes, it is possible to achieve agreement with an ever changing set of n nodes. 

There doesn't need to be any enforced cap, as any number of "voters" can be used in the set, and the set modified at any time.  Your workable limit is simply the point where the communication channels between this set becomes saturated and overloaded.

The ledger is append only, honest nodes either all agree to commit a change, or do not, so between honest nodes there are no network splits.  

With dishonest nodes, you can not enforce that they are committing the correct data or not, or if their ledger is in the correct state. Dishonest nodes may be doing all kinds of manipulation with the ledger they hold, yet still be actively participating in the protocol.

We simply do not care if dishonest nodes have a different state of ledger or not, because assuming that bad actors do not exceed (n/3)-1, we can be sure that we can guard against it.  

All the honest nodes are in a state of correctness, and will not commit any actions presented by dishonest nodes that attempt to subvert that correctness, because they will all arrive at the same result when presented with that data.  Should some data from a dishonest node be accepted, then all honest nodes will retain the state of correctness, because they will all have committed the change from the bad actor.

The dishonest node can present changes to historical data all it likes, all of the honest nodes will refuse to make the change because it violates the append only rule, even if greater than (n/3)-1 are telling it do so and honest nodes are in the minority.

Which is why I said he will probably have to cap nodes at a specific number like Bitshares and Darkcoin did.

So, how does this deal with a network split? I have yet to see any consensus proposal which is truly forkless without the ledger producing nodes being set in concrete, like they are in ripple.

I put it to you that forks are inevitable unless the nodes producing the ledger are a fixed set.

Me?? BCNext? lol  In that case I could be Satoshi too as I write block chain with a space and frequently mix American and British spelling of words!  I am everyone and no one, the many faced man!


Correct, once final a transaction can not be undone.  Transactions sit in a pending state until they are final, and that state duration is dependent on a number of variables.  Transaction that are in this state for too long are rejected.


As Ive said the purpose of the document is to give a high level overview of a Byzantine tolerant consensus, for which if you read it as it is intended, explains exactly that.  There is only confusion because of the application of block chain thought processes, and that we are delving into topics regarding ledgers, economics and other things.  

If you read the document as an entity in its own right, then it reads just like a Byzantine tolerant solution for which you do not need to know any other details of the system.  It could be applied in any system, and the prevention of Sybil attacks is possible via the simple substitution of fees for simple Proof of Work (not necessarily of the hashing type, there are many forms of POW used for many things before Satoshi) before each node is allowed to present a change to build its trust as a form of cost, with the trust "reward" being something relevant to the system being protected.

Also, no Byzantine solutions are infallible and have a fault tolerance limit of (n-1)/3, most fall short of this maximum or have to apply further restrictions to move closer to it.  Bitcoin itself does not even meet all the requirements needed for a Byzantine tolerant stamp of approval, but achieves "good enough" security though the utilization of its POW mechanism.

Heh, I can assure you I'm not winging this project by the seat of my pants  But I do like to take the time and effort to ensure that everything is covered, which I believe it is in regard to the trust consensus.  I'm also not so egoistic to think I'm right 100% of the time, and I actively spend lots of time reviewing everything after comments from others or possible concerns which they have.  

The past couple of days I have reviewed some of the concerns posted here and investigated them once more to be sure they are not serious and nor have I missed something.  The consensus presented holds up, and doesn't allow an attacker any more of an advantage than any other accepted solution for consensus.  All of the attacks presented have a cost attached which are greater than any reward in almost all cases, and in the others, they are easily thwarted by simply waiting.  Only irrational adversaries would would employ these attacks, and none of them take advantage of an attack surface area that is not also present in other consensus solutions.

That said, after reviewing concerns posted here, and investigating them in detail, I do have a few small improvements that I may make to the algorithm to further make these attacks more difficult to achieve.  I'll update the document (and others if published by then) with any changes made moving forward if and when I make them.   So, thanks to all for kicking my ass, it'll probably lead to improvements

more importantly, is the damn thing still written in java dan?

and you mean this closet of pi's ive been hoarding all these years cant attack emunie? fuck.

*sorry, this was border line toooo serious.*

Why? - like BTC, work is rewarded. The more transactions, the more profitable it is to run a client. If its not profittable, people will shut theirs down and the revenue for the remaining nodes are increased accordingly. Its will be self regulating by the incentives already put on the table 

You do not need some centralized shit to regulate incentives. People will figure out themselves if it makes sense to donate ressources or not.

Yea, nobody can figure out how this thing is supposed to work from the information provided so far.  Maybe he's making the coin on the fly as the thread progresses.  As a side issue, even though he's running a different system, I really think Dan is going to be forced to cap nodes at a certain number just like Bitshares and Darkcoin before this is out the door.  For monetary incentives and security-wise.

Maybe we should all just wait for the ledger discription.

There are no blocks but there has to be someway for reorgnaizations right? The primer itself says that all nodes are not always in the exact same state (for legitimate reasons). So there has to be a way for them to agree on states (which afaik is the transaction consensus value) and to change their own state in case it turns out someone else has a "better" state.

This is true. However, the only way to have no forks is to know in advance (and forever) who the nodes building the ledger are - in that case, if, say a network split occurs, the nodes who split off will lose connection to the ledger production nodes and simply stop with a 'no consensus' result.

But if your list is arbitrary and constantly changing, then forks are inevitable.

There are no blocks as Fuserleer said, so I assumed there was no blockchain reorgs. A ledger can't accept a double-spending transaction without doing a reorg.

I'm sorry, this is just rubbish. In the best case you can mine, lets say 95% of it, but you can never mine the last 5% because the difficulty will end up being contemporary and then you are back to outpacing the entire network again, which you just won't do by yourself, unless you have the majority of mining power, which is the classic 51% attack.

I really don't follow you. I'm not talking about producing a fake ledger, I'm talking about abusing the system into accepting a double spend into the genuine ledger.