Achieving Decentralization — (2/2)

We last left off getting into achieving consensus without identities, properties, problems and solutions. Let’s pickup where we ended.

Why Don’t Bitcoin Nodes Have Identities?

1. Identity is hard in a P2P system — Sybil Attack
2. Pseudonymity is a goal of bitcoin

Take a leap of faith with me as I explain how the weaker assumptions are actually accomplished

Weaker assumptions: Select random node

1. Analogy: Lottery or Raffle. Tracking and verifying people while giving them Identifying, and verifying those identities is pretty hard. So what we do is give them
2. When tracking & verifying identities is hard we give people tokens, tickets, etc
3. Now we can pick a random ID & elect that node
   We hope there is a smart enough algorithm for generating token IDs so that an attacker who is trying to create Sybil nodes they are only appointed 1 token ID. Therefore they cannot perform a malicious attack.

So let’s see what becomes possible if we make this assumption.

Key Idea: Implicit Consensus

1. In each round(multiple rounds), random node is picked
2. This node proposes the next block in the chain
3. Other nodes implicitly accept/reject this block: by either extending it or ignoring it and extending the chain from an earlier block
4. Every block contains hash of the block it extends

Each round with multiple rounds, corresponding to a differ block in the blockchain, a random node is somehow selected. This node gets to propose the next block in the chain. There is no consensus algorithm, there is no voting. This node simply unilaterally proposes what the next block in the blockchain is going to be.

What if that node is malicious?

Well, there is a process for this, but it is an implicit one. Other nodes will implicitly accept or reject that block.

How will they do that?

If they accept that block, they will signal that acceptance by extending the blockchain starting from that block, or if they reject that block they will extend the chain by ignoring that block and starting from whatever was the previous, latest block in the blockchain.

Technically, how is that implemented? Recall that each block contains a hash of the block that is derived from, and this is the technical mechanism that allows nodes to signal which block it is that they’re extending.

Consensus Algorithm (Simplified)

1. New transactions are broadcasted to all nodes.
2. Each node collects new transactions into a block.
3. In each round, a random node gets to broadcast its block
4. Other nodes accept the block only if all transactions in it are valid (unspent, valid signature)
5. Nodes express their acceptance of the block including its hash in the next block that they create

Application:
So when Alice wants to pay Bob she will create a transaction that is broadcasted out to all the nodes. Anyone of these nodes is constantly listening to the network and collecting a list of outstanding transactions that have not yet made It into the blockchain. At some point if these nodes will be randomly called upon to propose the next block. The block will gather up all the outstanding transactions that it’s heard about and propose that block. Now presumably that node was honest, however, it also could be a malicious node a faulty node and propose a block that contains invalid transactions. If that happens the other nodes will submit their acceptance or rejection of the block. See Technically, how is that implemented?

Invalid Transaction: A transaction without a valid signature or possible double spend.

What can a malicious node do?
Let’s say Alice is the attacker now and she is up (her node) to propose the next block.

What can she do?

She can’t attempt to steal bitcoins from other users because if you recall from Hash Pointers Article if she doesn’t have the secret key, therefore, cannot forge anyone’s signature. Another possibility would be to deny service to Bob. Assuming she knows his address she can decide to not include his transactions originating from his address into the proposed block. This is a valid attack, however, one that can be simply solved by waiting for the next honest node to propose a block with his transactions. The only other serious attack would be a possible Double Spend Attack.

How might a noble spend attack work?
Let’s assume Alice is a customer of some online merchant site that is run by Bob, who provides the online goods in exchange for payment in BTC. Now, Alice likes a product that Bob sales and she decided to purchase that with BTC. In Technical terms, she is going to create a bitcoin transaction from her address to Bob’s address. She then broadcasts it to the network.

04. As far as bobs concerned the transaction is completed and Alice has now received the product she purchased.

Now we can ask which the longest extending block and that would be easy for us. We will say the one containing Alice’s transaction to Bob’ in exchange for services. This is a “legitimate” transaction because we implement a moral perspective. Whereas, the Red block contains a Double Spend Attack. Technically speaking both transactions are identical, therefore legitimate. So how does the protocol distinguish the two?

Nodes are slight heuristic on extending the block that they first heard about on P2P network, but it’s not a solid rule because of network latency it could EASILY be that the Double Spend attack becomes Legitimate on the blockchain consensus. Small chance that the next node can extend the Red Block with the fraud transaction vs the Green one with the honest transaction.

Generally, the more confirmations the transaction received the reader probability it is “legitimate” because if you recall, honest nodes always extend the longest valid branch that they see.

SOLUTION:
Double-spend attacks probability decreases exponentially with # of confirmations. Most common heuristic: 6 confirmations. There’s no particular special property with the value 6, it’s just a good trade off on time spent waiting for valid transactions and your guarantee that the transaction that you’re interested in ends up on the consensus blockchain.

RECAP:

1. Protect against invalid transaction (malicious node) is cryptographic, but enforced by consensus.
2. Protection against double -spending is purely consensus
3. You’re never 100% sure a transaction it is in the consensus branch. The guarantee is probabilistic.

2.4 Incentives and Proof of Work.

Bitcoin and decentralized based ledgers are a combination of both technical mechanisms and clever incentive engineering. So, far we have mostly talked about the technical mechanism but let’s dive into the inventive component.

Assumption of Honesty is Problematic
Can we give nodes incentives for behaving honestly? If we looked at the previous figure above you can see the blockchain with the Red Block proposing a double-spend attack. It would be problematic to try and penalize the node for proposing a malicious attack because there are no identities tied to the address (pk). Therefore, we cannot go after them. Now, instead, can we reward nodes that created the 1-N confirmations (honest nodes created “Legitimate” blocks)?

We run into a similar problem. The honest nodes do not have an identity attached to them, therefore, we cannot pay them with cash to their home address. However, with e-cash, we can incentives the nodes by paying them in units of that currency (for this example we will continue to use BTC).

INCENTIVE ONE: Block Reward
Creator of block get

1. Include a special coin-creation transaction in the block
2. Choose recipient of the transaction

Value is fixed: correctly 25 BTC, halves every 4 years.

What this means is that Nodes get rewarded for creating a block. In the rules of BTC, they also get to include a special coin-creation transaction and also chooses an address to receive the created coin, typically their own address. Thereby, paying itself for creating the block. Basically, a payment exchange for the service of creating that block to go on the consensus chain. There a special property to the creation. Now with the statement above, the node gets rewarded for creating blocks with both valid transactions OR malicious transaction.

How can we actually provide any incentives for honest behavior?
The block creator only gets to “collect” the reward ONLY if the block ends up on the long-term consensus branch! The coin creation isn’t a special transaction. It also only valid if it ends up on the consensus chain. This is a subtle but clever way to incentivize nodes to act honestly, or at the very minimum, in a way, other nodes will agree with when created the next block.

So does this mean that the system will not work post-2040 as nodes have no incentive to act honestly once the generation runs out?
No, because this is only ONE of the two incentive mechanisms.

INCENTIVE TWO: Transaction Fees

1. Creators of transactions can choose to make output values less than input values.
2. The remainder is a transaction fee and goes to the block creator.
3. Purely voluntary, like a tip.

If you’re a node creating a block that contains 200 transactions then sums of all those transaction fees accrue to you and the address that you put on that block. We can assume as the block reward system runs out that the transaction fee will become more and more important, if not mandatory. How the system fully evolves is based on a lot of game theory which hasn’t been fully worked out yet, so that’s an interesting area of open research in BTC.

We pretty much have a solid foundation for achieving decentralization. There are only a few more problems that we need to address before we can have an effective and secure system.

Remaining Problems:

1. How to pick a random node?
2. How to avoid a free-for-all due to rewards?
3. How to prevent Sybil Attacks? (Trickier version of #2)

All these problems are related and, luckily, all these problems share the same solution, and that solution is called a Proof of Work.

Proof of Work
We approximate selecting a random node: Select nodes in proportion to a resource that no one can monopolize (we hope).
Resources:

1. In proportion to computing power: Proof-of-Work
2. In proportion to ownership: Proof-of-Stake

We are allowing nodes to compete with each other by using their computing power, and that rule results in nodes being automatically picked in that proportion.

Equivalent Views of Proof-of-Work

1. Select nodes in proportion to computing power
2. Let nodes compete for right to check
3. Make it moderately hard to crew new identities

The Solution

(WARNING gets a little hairy. Follow along and reread if needed):
The solution is called Hash puzzles (Refer back to Hash Pointers). In order to create a block node that proposes that block is required to find a number (a nonce) such that when you put together in the block: the nonce, the previous hash and a list of transactions that compromise that block; take the hash of this whole long string, then that has output should be number that is very small. A number that falls into this small target space here in relation to this very large space that is the output space of that hash function.

Just like the previous blocks, you can see that we contain a Hash Pointer leading to the previous block, transactions, but now we added a nonce to it. Let’s say that the target space is 1% of the total output space. That means for every 1 correct nonce you try you have to try 99 nonces before getting lucky to solve the block. The target space is actually much smaller than 1% and ill go over that in a second.

Fundamentally, this is the computational problem that a node is required to solve in order to produce the block. Hash puzzles in PoW completely do away with the requirement for somebody somehow to pick a random node. Instead, nodes are simply all the time independently competing to solve the hash puzzles. Once in a while, one of them will get lucky and will find a random nonce that will satisfy this property, and that node gets chosen to propose the next block.

PoW PROPERTY ONE: Difficult to Compute

1. As of Aug 2014: About 10²⁰ hashes/ block. In terms of computing power for your PC this is simply a humongous and infeasible number and as a result
2. Only some nodes bother to compete — miners. Miners are nodes that are continually competing to compute & solve these hash puzzles.

Although anyone can become a miner, it takes tremendous computational power, therefore, participation in the mining ecosystem has grown to become more centralized.

PoW PROPERTY TWO: Parameterizable Cost

1. Nodes automatically re-calculate the target every two weeks.
2. Goal: Average time between blocks in the overall BTC network = 10 minutes.

Explanation:
If you are a miner and you’ve invested a certain fixed amount of hardware into BTC mining and more mining operations are created and/or more efficient computing hardware is implemented more blocks are found and expected. So nodes will automatically adjust the target space so that the amount of work that you need to do to find a block is going to increase. If you fixed an amount of hardware to mining, the work you are expected to produce is dependent upon what other miners are doing.

Prob ( Alice wins next block) = fraction of global hash power she controls. If she contains 0.1% of total hash power, she will compute ~1 in every thousand blocks.

Why does this readjustment happen? Why do we want to maintain this 10-minute invariant?
If blocks were to come very close together, then there would be a lot of infancy and we would lose the optimization benefits of being able to put a lot of transaction (currently @ several hundred tx in a Single block)

Key Security Assumption
We can stop taking a leap of faith as I had asked of you to do earlier in the previous article. We can safely say that: Attacks are infeasible if the majority of miners weighted by hash power follow the protocol (are acting honestly). Because of competition for proposing the next block we can now that there is a 50% chance that the next block to be proposed at any point is coming from an honest node instead of a malicious one.

PoW PROPERTY THREE: Trivial to Verify

1. Nonce must be published as part of a block
2. Other miners simply verify that H(nonce || prev_hash || tx || … || tx) < target.

What does this actually mean?
Even if it takes a node on average 10²⁰ tries to find a nonce that succeeds in finding the right property of the hash function that nonce must be published as part of the block. So its trivial for any other node to look at the block contents, hash them all together and verify that the output is less than the target. This is important because it takes away centralization by independently verifying that miners are doing their job correctly. Any other miner (node) can instantly verify that the other miners satisfy this PoW property. Thereby, the can be sure that the miner put in lots of computing power to find that block.

2.5 Putting it All Together

Lets talk mining economincs.

Simple equation:

If mining reward (block reward + tx fees) > hardware + electricity = profit.

Complication:

1. Fixed vs variable costs
2. Rewards depends on global hash rate

This equations doesn’t capture all the nuances of the different strategies of the miner could employ.

RECAP:

1. There no real-world identities are required to participate in the P2P system. At any moment users can create pseudonymous key pairs, and any number of them.
2. Transactions are messages that are broadcasted to the network which are instructions to transfer a coin from one address to an other.
3. P2P network’s goal is to propagate all new transactions to all the BTC peer nodes as well as new blocks to the BTC peer nodes, but only will the best effort that it can.
4. Blockchain & consensus protocol provide the primary security principles for the BTC network. The more confirmations (blocks) your transaction received the exponentially increased probability that the transaction is valid.
5. Hash Puzzles & mining allow nodes to compete to propose blocks that will be added to the blockchain consensus for a reward for acting honestly.

Thats about it for achieving decentralization. Please follow us on Twitter to ask us any questions. We have awesome updates for you coming up soon too. Patrick released a new video on LTC/BTC chart analysis (Feb 7th 2018) don’t forget to check it out. 🙌🏼

Thanks for reading! :) If you enjoyed this article, hit that heart button below ❤ Would mean a lot to us and it helps other people see the story.

Say Hello On

Instagram | Twitter | YouTube

What’s New

Our Execs Newest Positions

Our executives Angel Mondragon (CEO) and Patrick Benske (CMO) were recently announced as Senior Advisors for a Public Company for Crypto Currency. Read Here

Whitepaper | Community

We are releasing a teaser for our whitepaper in addition to our first months results for our fund. We are releasing it on our telegram. Find the channel HERE.

Writer: Angel Mondragon. Edited: Patrick Benske.