I'll put up a compressed and detailed blurb once I have time, currently work has more priority than talking.
However, allow me to post a real simple and clear example...forget Sybil, forget Byzantine, network partitions and everything else. No doubt someone will comment about those issues as no one here seems to read very often. This example is ONLY to highlight the very basics of append only mechanics and there is nothing new here, it was all included in the consensus primer, which by now has been reviewed by a number of reputable people.
None have found a legitimate flaw that could be exploited easily, and seeing as everyone is happy to accept that LCR + POW can be exploited with enough resources, yet can live with it, Im happy enough too.
You must remember that eMunie tracks balances ONLY and doesn't not reference outputs as inputs or anything similar! Failure to do this will result in a misunderstanding of even basic concepts.
Assume there is a network of 4 nodes, A, B, C and D, where one of them is malicious, any, it doesn't matter.
A is making transactions, B, C and D are vying for endorsements and all have a connection to A.
Periodically B, C and D are presented with a challenge from A, if they provide the correct solution, they are honest. You can classify this as a POW, and it makes up the 1st part of resource expenditure.
Assume B, C and D present correct solutions.
A makes a transaction, and upon doing so endorses one of the connected nodes B, C and D. Lets say that A endorses B.
A also pays a fee for making the transaction which is the 2nd part of resource expenditure.
A makes another transaction, this time endorsing C.
This continues for a period of time with A endorsing one of the B, C, or D nodes for each transaction.
Later D wishes to attempt to change history as hes malicious, but there is no way for him to do this, he can have access to all POW and fee resources on earth and he still cannot. Why?
In an append-only ledger, an attempt to inject, modify, change or remove a transaction that is in the past results in a consensus trigger. There is a small window of time allowed for propagation and clock drift, you could assert this time period akin to a confirmation. Any node that sees such transactions after this time period has expired, regardless of if the transaction is legal or not, will have to rely on a vote result to determine if it can be included in its copy of the ledger.
It is the role of the endorsed nodes to vote on what the current state of the ledger should be, and the state with the maximum votes wins. Only a portion of the full set of endorsed nodes are eligible to vote at any time, and this is determined by the endorsements made in recent transactions.
In our case, B, C, and D will be eligible to vote as they have been present throughout the duration of A's transaction making marathon.
Assume there is a transaction that propagated slowly, but providing that the majority of the endorsed nodes have seen it, then it will be included in the state that is voted in. If D is included in that vote, and wants the transaction to be included, he can present his vote and that is all. He cannot spend any amount of resource to force such a transaction to be accepted if the majority state that is shouldnt.
Even if he created 1M fake transactions right now and presented them with forged timestamps and what not, all they would do would be to trigger a vote, which is already happening. If he created 1M transactions with the correct time stamp and other data, they would only get included in the next vote, by a different set of voters.
Once the vote is in, and the ledger state is decided upon, the ONLY state that endorsed nodes can now vote on is the next. There is nothing D could do to force a re-vote, and even if he could, all the other endorsed nodes would vote exactly the same as they did before.
Now this bit is important.....the set of endorsed nodes that may vote is deterministic and the vote result for each node is deterministic from the data they have. The determinism is seeded by the transactions for which some resource has been expended to create (fee & challenges).
Such is the nature that a transaction sent 1 second earlier or later can change the vote in some circumstances, but the result of that vote will always be the same after the fact. If transactions that are older than a certain period of time are not included in the ledger until the outcome of that vote is known, then that transaction cannot possibly influence the determinism of the vote, thus the vote result is the same.
One edge case I will touch upon is the instance where a node accidentally accepts a transaction that is outside of the expiration time, in this event that nodes ledger state will start to deviate from everyone else so he will have to call upon other nodes to find out the real state and the result of past votes. Assuming that his ledger is not too far out of sync with everyone else, he will have enough true data available to verify the results of these past votes and resolve the deviation automatically.
There you have it, a brief example into a ledger that is final, trustless, expends resource and decentralized. If you can't understand that, well, I can't help you anymore.
This as mentioned only touches on the question in hand and there is a lot of other stuff that exists alongside these principles.
Some surely will argue this is a propagation based method, which is incorrect, propagation only plays a small part to invoke a trigger to decide whether it should be included. If the decision is NO, then that transaction will fail a short time later, and the user will be prompted it has happened (within 30s) and can represent it.
