Quote from: TPTB_need_war on January 12, 2016, 12:22:13 AM

One last farting shot so the ignoramuses here can start to think a little about respecting those who are smarter than they are.

Decentralized Proof-of-Work Ordering

Some decentralized databases such as cryptocurrencies or smart contracts require consensus on the ordering of events.

Bitcoin provides consensus on ordering with a Bzyantine fault tolerance of up to 50% of the network proof-of-work hashrate, or as low as 33% due to the economic advantage of selfishly mining the block chain rewards. Bitcoin employs proof-of-work puzzles to identify whom is authorized to produce the next block of events and consensus is the longest chain of blocks which contains the greatest cumulative proof-of-work difficulty.

Consuming a resource such as proof-of-work to produce a chain of event blocks is necessary to disambiguate conflicting events in competing chains by choosing the longest chain. Otherwise there would be unresolveable conflict over which of the conflicting events is valid.

Given a longest chain rule consensus, block periods of events are required because otherwise for example in a DAG there is a divergent proliferation of unmergeable chains induced by double-spends. One need only graph some complex scenarios to visualize this effect. In any other attempt to consume a resource to prove a consensus on ordering of events that does not use a longest chain rule, irreconcilable ambiguities will profilerate due to lack of a globally consistent rule for disambiguating double-spends. Globally in this context refers to the fact that nodes of a decentralized network will disagree about the order in which events arrived because propagation can not be made consistent.

This paper analyzes the flaws in Bitcoin's algorithm which:

* effectively make it centralized over time
* limit scalability and transaction rate
* cause an irresolvable tension over the ideal block data size
* deny instant confirmations

I propose a new design to resolve all these issues that retains the core principle of a proof-of-work block chain.

Initially I wasn't going to bother even replying due to the tone of your opening statement.

But, consider this ( I don't expect a constructive reply, this is more for everyone else)

The voted ledger states in eMunie are akin to blocks to some degree, though with your intellect I'm dumbfounded how you haven't already seen the parallels.

A block in Bitcoin defines what has happened since the last one, a ledger state in eMunie does the same.

It doesn't matter what order the transactions come in during an inter-block period with Bitcoin, transactions can be validated just the same. This is also true for eMunie.

Until a transaction is included in a Bitcoin block, it is not final. Until a transaction is referenced in an eMunie voted ledger state, it is not final.

eMunie just does things in a different way, using more "exotic" data structures and decouples a lot of stuff for speed, efficiency and finality.

This finality in Bitcoin is generally regarded as 6 confirms (though with the level of hash rate etc, I'd argue that 1 or 2 are plenty), or 60 minutes. In eMunie this finality is 30 seconds, and can not be changed.