A World of Trust – eMunie Consensus Primer

[TPTB_need_war]

Well remember you have bandwidth to worry about

You see the devil is in the holistic details. I said in my first post that the bandwidth optimization would work to open more opportunities to attack.

So decrease bandwidth, that must equate with reduced # of P2P connections per node, no matter how you formulate it.

Thus increasing the probability of being able to isolate it.

[Fuserleer]

Well remember you have bandwidth to worry about

You see the devil is in the holistic details. I said in my first post that the bandwidth optimization would work to open more opportunities to attack.

So decrease bandwidth, that must equate will reduce # of P2P connection, no matter how you formulate it.

I know the devil is in the detail, Ive optimized bandwidth and usage a lot, its very efficient.

[TPTB_need_war]

BTC is dead in that scenario

Network fragmentation and Bitcoin is dead because you can spend your coins in every fragment. Not just a double spend rather an N spend. Where N is number of fragments.


I'm very sleepy so will sign off.

[lovely89]

Assume that is also has a list of preferred outgoing connections to nodes it knows are of similar importance to it.  If you can isolate it then it improves your chances of success slightly.

How do you isolate it so that it can not receive or relay information to anyone without being physically near it?

Oh boy...   it's happening again...   two spaces after periods & cannot with a space...   BCNext is that you?  


Edit: 

If Fuserleer is BCNext, he has a serious Dissociative identity disorder.

https://bitcointalk.org/index.php?topic=303898.msg3390794#msg3390794

[jabo38]

This optional feature is also important for companies that want to comply with tax and regulatory laws as they can expose in public these transactions and earnings to everyone and the tax man.  Individuals can also do this too of course.

Parties who chose this configuration can easily prove that they are in control of the balance(s) associated with that transaction, so then you can have a full representation of the transactions they have performed and achieve a similar level of trust in the manner that you speak of.

I think this is a fine balance for a system.  A consumer should have the right to protect their privacy and even be completely anon if they want.  A business doesn't need to know anything about that consumer except that they sent the money.  Can a deposit be seen on the blockchain?  If so, good.  That is all they need to know.

This doesn't apply for business though.

A consumer and governments to some extent need to know about the dealings of a business so that the consumers can protect themselves, and at the same time the government can protect those consumers that are too young, too old, or too foolish to protect themselves.  Businesses having an option to show their histories openly and transparently is a nice step in this direction.

Bitcoin and other blockchains have been stricken by a series of scammers as it is such a great platform for them.  They get them money and can easily disappear.  It would be nice for those businesses not interested in scamming to have a proper outlet to do so in a system that helps to support their claims of legitimacy setting a bar for how legit players look and how they act. 

[monsterer]

All your sybil attacks are abstract and don't take into account factors of the real world. The attacks may succeed in a spherical vacuum, but what about attacking eMunie if it's used by, say, Starbucks? You walk into a cafe and scan a special QR-code (displayed on an interactive screen) with your smartphone. This code is the root of Merkle tree of the ledger essential part. If your version of eMunie ledger is "hacked" then you will see the difference right away. Whom will you trust, the Starbucks system or unknown random guy with 2 million fake nodes?

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.

[monsterer]

You dont need anything like $4T, you could re-mine the entire blockchain from the genesis again in secret in about 2 years and $200M.  As a bonus you'd end up back at today with about 65% of current mining power.  Then just present that chain as it'll have more work than the current one, and BAM.  All BTC transactions gone on all nodes that are active at that time, you can easily outpace everyone else too so they cant present a stronger chain.

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.

[Come-from-Beyond]

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.

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.

[monsterer]

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.

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.

[patmast3r]

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.

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.

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.

[r0ach]

Maybe we should all just wait for the ledger discription.

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.

[Anima]

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.

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.

[billotronic]

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

[Fuserleer]

Assume that is also has a list of preferred outgoing connections to nodes it knows are of similar importance to it.  If you can isolate it then it improves your chances of success slightly.

How do you isolate it so that it can not receive or relay information to anyone without being physically near it?

Oh boy...   it's happening again...   two spaces after periods & cannot with a space...   BCNext is that you?  


Edit:  

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!

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.

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.

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.

Maybe we should all just wait for the ledger discription.

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.

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

[monsterer]

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.

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.

[r0ach]

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.

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

[Fuserleer]

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.

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.

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.

[Fuserleer]

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.

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

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.

[monsterer]

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

[Fuserleer]

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

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.