Consensus algorithm proposal

As I find voting system complex (more than 5 pages to explain), I've been considering a new, simpler consensus protocol below.

Definitions: Let h the height of the account-chain for X, let t the blocks in the account-chain. t[h] is the last block of the account-chain, t[1] the first one.

Protocol: When a node receives a transaction t for account X:
if t.previous = hash(t[h-1]) && t ≠ t[h] -> keep in the chain the transaction with lower PoW field (t or t[h])
if t.previous = hash(t[h]) -> add t to account-chain
in all other cases: nop

In this algorithm, the head block of a chain is never confirmed while all other blocks are. But if confirmation of a head block is required, the user can easily send a dummy change transaction to confirm it. As this algorithm is extremely simple, the queue of waiting transactions can rapidly be eliminated, which protects us against DoS attacks.

A necessary condition is to program nodes to maintain a 1-second gap between two transactions by the same user. It is because Nano transactions and UDP packets don't have a sequence number. It allows to be sure that a transaction is distributed to nodes before the next one arrives. If an UDP packet gets lost, the node will see that its confirmation_height is lower than his neighbors and ask for a synchronisation for account-chain X.

Pros:

  • extremely simple
  • only a few lines to code
  • no network overhead for consensus (in current protocol, votes transmission is an overhead)

Waiting guys for your comments!

*replace "lower PoW field" by "lower signature field". It is because Pow is calculated only on previous_block_hash, so it is useless here.

Just a note that UDP is deprecated, its now TCP only.

I'm not sure I quite understand the proposal. It sounds like you're saying that a double-spend attempt should be resolved by the node accepting whichever of the two transactions has the lower PoW attached? That's strange because all I would have to do to double-spend funds is submit a second spend with a lower PoW. I could even submit my first tx with a deliberately higher-than-necessary PoW to make this easy.

But I'm guessing I'm just misunderstanding the idea?

No you can't because in this algo blocks which are not at the head are cemented. It means it cannot be modified. You can only modify the head block before it is not the head any more. If the network is split in two subnetworks during a long period of time, voting can still appear to elect the subnetwork with more votes as the new network. But it shoud be rather rare.