<blockquote>
<p>A node gets randomly selected to add a block to the blockchain with a chance of 1/n.</p>
</blockquote>
<p>This step is the key problem. How is the node randomly selected? What source of randomness would you use? If a node is chosen to add a block to the blockchain but goes offline what happens then? Perhaps a replacement node is &quot;randomly&quot; chosen? But then half the network finds out that previous node did actually provide a block and half the network continues to add blocks on top of the block the replacement node provided. What then? With (perhaps rare) edge cases it needs an ultimate authority to clean up uncertainty and confusion. Bitcoin's proof of work is decentralized, incredibly robust to edge cases, does not need a network agreement on a source of randomness and does not need network agreement on time measurement (e.g. we'll wait 30 seconds for a node to provide a block). It can only do this because it only provides eventual finality and eventual network consistency. Although increasingly unlikely any length re-org (2 block, 3 block, 4 block etc) is theoretically possible.</p>

CC BY-SA 4.0
2022-08-06T09:30:16.023Z
2022-08-06T09:30:16.023Z
Michael Folkson
<p>Given n nodes(miners/validators),</p>
<ol>
<li>Every unspent transaction output is broadcasted to all n nodes.</li>
<li>Each node will select a batch of transactions and add it to their
block. The specific mechanism of how they select transactions will
be dependent on each node’s source code.</li>
<li>A node gets randomly selected to add a block to the blockchain with a chance of 1/n.</li>
<li>The node broadcasts its block to all other nodes before adding the
block to the chain. If the block contains illegitimate transactions
or tampered data, other nodes will reject the block. A block gets
added only if majority of the nodes in the blockchain agree that the
block is valid.</li>
<li>Before the block gets added, it is hashed along with the hash of the previous block.</li>
<li>In order to incentivize people to set up their own nodes, a small
portion of the actual transaction gets rewarded to the node that
added a block. This is different from Ethereum’s additional GAS
fees. It is more analogous to taxes, where 100% of the burden is on
the seller(recipient of the cryptocurrency).</li>
</ol>
<p>This algorithm also guards against many common security issues:</p>
<ol>
<li>Corrupting data of previously added nodes: Resolved, since even if a malicious actor tampers with data of previously added blocks, the protocol can always compare the hashes of the tampered chain with that of every other node(nodes constantly communicate), and update its chain to the ‘correct’ chain(once again accepting majority’s chain as correct data, assuming that the 51% rule is always observed).</li>
<li>Adding a faulty block in the first place: Resolved, since it is
impossible to add a block without getting approval of majority of
nodes. Even if a malicious actor adds the block to its own chain,
other nodes wouldn’t add it to theirs, causing the malicious node to
eventually update an obsolete chain.</li>
<li>Data retrieval is also based on proof of majority, so every time a transaction occurs, it checks with all n nodes to find a valid historical precedence of the transaction(e.g. A can only send 100 crypto to B if he or she owned it in the first place) and accepts the majority’s historical record(once again proving why it is meaningless for malicious nodes to update their own chain)</li>
</ol>
<p>This algorithm doesn’t cost huge amounts of computing power and money to purchase equipment(unlike PoW) and doesn’t cost anything to set up nodes aside from basic equipment cost(unlike PoS).</p>
<p>It should work as a potential consensus algorithm, but I want critiques on potential flaws of the consensus algorithm. Furthermore, blockchain technology is becoming more and more mainstream, but it is rather difficult to research about different consensus algorithms without taking graduate level math. What's the easiest way for newly acquainted scholars of blockchain technology to study it and stay up to date with latest developments?</p>

CC BY-SA 4.0
2022-08-06T09:23:37.370Z
How does the node in step 3 get selected? How is majority decided in step 4? I have the feeling you want to initiate a discussion rather than get an answer to a specific problem you face. This Q&A website is probably the wrong place for a discussion - it just wasn't designed for that.
RedGrittyBrick
CC BY-SA 4.0
2022-08-06T11:36:00.037Z
In step 3 I can just spin up a million nodes and I get to pick all the blocks?
Mike D
CC BY-SA 4.0
2022-08-06T13:52:05.923Z
Also in step 4, how do nodes know that a majority agrees?
Murch
<proof-of-work><consensus><proof-of-stake><trust>
Would a consensus algorithm like the one I describe work?
rasputin
# Would a consensus algorithm like the one I describe work?

(Asked by: username_0 on 2022-08-06)

Given n nodes(miners/validators),

1. Every unspent transaction output is broadcasted to all n nodes.
2. Each node will select a batch of transactions and add it to their
   block. The specific mechanism of how they select transactions will
   be dependent on each node’s source code.
3. A node gets randomly selected to add a block to the blockchain with a chance of 1/n.
4. The node broadcasts its block to all other nodes before adding the
   block to the chain. If the block contains illegitimate transactions
   or tampered data, other nodes will reject the block. A block gets
   added only if majority of the nodes in the blockchain agree that the
   block is valid.
5. Before the block gets added, it is hashed along with the hash of the previous block.
6. In order to incentivize people to set up their own nodes, a small
   portion of the actual transaction gets rewarded to the node that
   added a block. This is different from Ethereum’s additional GAS
   fees. It is more analogous to taxes, where 100% of the burden is on
   the seller(recipient of the cryptocurrency).

This algorithm also guards against many common security issues:

1. Corrupting data of previously added nodes: Resolved, since even if a malicious actor tampers with data of previously added blocks, the protocol can always compare the hashes of the tampered chain with that of every other node(nodes constantly communicate), and update its chain to the ‘correct’ chain(once again accepting majority’s chain as correct data, assuming that the 51% rule is always observed).
2. Adding a faulty block in the first place: Resolved, since it is
   impossible to add a block without getting approval of majority of
   nodes. Even if a malicious actor adds the block to its own chain,
   other nodes wouldn’t add it to theirs, causing the malicious node to
   eventually update an obsolete chain.
3. Data retrieval is also based on proof of majority, so every time a transaction occurs, it checks with all n nodes to find a valid historical precedence of the transaction(e.g. A can only send 100 crypto to B if he or she owned it in the first place) and accepts the majority’s historical record(once again proving why it is meaningless for malicious nodes to update their own chain)

This algorithm doesn’t cost huge amounts of computing power and money to purchase equipment(unlike PoW) and doesn’t cost anything to set up nodes aside from basic equipment cost(unlike PoS).

It should work as a potential consensus algorithm, but I want critiques on potential flaws of the consensus algorithm. Furthermore, blockchain technology is becoming more and more mainstream, but it is rather difficult to research about different consensus algorithms without taking graduate level math. What's the easiest way for newly acquainted scholars of blockchain technology to study it and stay up to date with latest developments?

**Tags:** proof-of-work, consensus, proof-of-stake, trust

> **Comments:**
> **username_1**: How does the node in step 3 get selected? How is majority decided in step 4? I have the feeling you want to initiate a discussion rather than get an answer to a specific problem you face. This Q&A website is probably the wrong place for a discussion - it just wasn't designed for that.  
> **username_2**: In step 3 I can just spin up a million nodes and I get to pick all the blocks?  
> **username_3**: Also in step 4, how do nodes know that a majority agrees?  

---

## 1 answers

### Answer by username_4 on 2022-08-06. Score: 3

> A node gets randomly selected to add a block to the blockchain with a chance of 1/n.

This step is the key problem. How is the node randomly selected? What source of randomness would you use? If a node is chosen to add a block to the blockchain but goes offline what happens then? Perhaps a replacement node is "randomly" chosen? But then half the network finds out that previous node did actually provide a block and half the network continues to add blocks on top of the block the replacement node provided. What then? With (perhaps rare) edge cases it needs an ultimate authority to clean up uncertainty and confusion. Bitcoin's proof of work is decentralized, incredibly robust to edge cases, does not need a network agreement on a source of randomness and does not need network agreement on time measurement (e.g. we'll wait 30 seconds for a node to provide a block). It can only do this because it only provides eventual finality and eventual network consistency. Although increasingly unlikely any length re-org (2 block, 3 block, 4 block etc) is theoretically possible.


---

