Skip to main content


To understand what Blockchain is, we need to go a little bit low level and understand what is Transactionand Block.
Transaction is also called record. It maps to a real-life event, such as Rob pay Lucy $100.
By contrast, Block and Blockchain are abstract entities that are used to making sure all the Transaction happened will be recorded permanently and once it is recorded it is trustworthy and unmutable, but without a centralized authority says so. Blockchain is, well, a chain of Blocks.

The decentralized trust is the beauty and value of blockchain. And it’s power and usefulness is manifested by the success of the application out of which it is invented - BitCoin.
With the power be decentralized, you don’t need to hand over your power and privacy to others in exchange for a service. If there is a distributed social network platform, probably you want to give it a try if you are concerned about your privacy with Facebook? Or people, out of various reasons, don’t want to go through a bank, Paypal, WeChat for their financial transactions, that’s one of the primary reasons that drive the rise of BitCoin.

Distributed Consensus

For such as a system to work, the center of the problems is: How peers in a distributed system can agree on something?
“They can vote!” I hear you screaming. Yes…but if I can control 51% of the machines, I can control the whole system, for my benefit. It is a lot easier than controlling 51% people, all you need is money. If the economic incentive to do so out-weights the cost, people will do it! Mind you that currently BitCoin worth $100Bn.
BitCoin didn’t solve the general problem of distributed consensus, but it provides a solution that works extremely well in practice, using things called proof-of-work, and confirmation. It is not only about technology, but also some genius social innovation to ensure the whole system works.

Other Problems

In the context of Bitcoin, where it’s all about money. Other than making sure there will be a consensus regarding what are the valid transactions, following things are also very important design goals. If you can’t get them working, the whole system won’t work.
  1. A can’t spend B’s coins.
  2. A can’t spend more than she had.
  3. A can’t double-spend her coins.


Goal #1 is guaranteed by the cryptography.
A will need to sign the transaction using her private key. As long as A doesn’t have B’s private key, he won’t be able to spend B’s money.
A big shout here: take good care of your private key! Otherwise, you will lose all your money!
Goal #2 is guaranteed by having immutable transaction history, thus it is easy to verify if A is over-spend her coins: just look up the unique global blockchain find out how much she remains.
The immutability of blockchain is achieved by having the newer blocks including the digest of old blocks, so to modify a block you will also require modifying all the blocks that come after it. The computation power requires to make such modification is so huge (we’ll discuss this in detail in proof-of-work, and mining) that outweighs the benefits you might get so in practices make nobody will do it. Therefore, we consider the blockchain used by BitCoin is safe and can be trusted.
For Goal #3, we need a little bit explanation of what double-spendis since that’s one of the core problems for any digital currency to be useful. When using paper money, there won’t be any issue of double-spending. You hand out your money and you get the good. You can use that same money again. In case of Bitcoin, due to its distributed nature, it will take a while (say 1 hour) for the transaction to be made to the final blockchain, or to be confirmed. During that period, if A start another transaction, using the same coin he has just spent but is now in a to-be-confirmed status, he is double-spending the coin. Due to the distributed nature of the system, there is no easy way to arbitrate which transaction comes first, since there is not a global timing used by each transaction. This is called Race Attack, one of the ways to double-spend. Bitcoin solves the problem by something called confirmation. Newly created transaction has zero confirmation; It gets one confirmation when it is included in a Block and be chained; another confirmation when a new block appended; the more confirmations you get, the more confidence you get that transaction will make into the blockchain and won’t be reversed (thus double-spend). Currently, 6 confirmations are what most people will require.

Journey of a Transaction in BitCoin system

In previous sections, we go through some problems a distributed ledge system have to solve and touch gently how BitCoin solve the problems from a high level. Here we go a little bit low level, walking you through a journey the life cycle of a transaction in BitCoin system.
  1. BitCoin runs in a distributed peer-to-peer network. Everyone equals. We will call each peer aNode.
  2. A Node will create a Transaction and propagate it to the network.
  3. That transaction will be picked up by a few other nodes, be validated by them, and it is considered to be a valid one, it will be put into a Block. Note that there might be more than one Block being created that contains that transaction.
  4. At a certain time, a random node get picked up and asked to propose a candidate as next Block to be added to the global blockchain.
  5. The proposed block will be validated by other nodes, and it can be accepted or rejected by other Node. When being accepted, the Node accepts it will add it to its current longest blockchain; When being rejected, it just gets ignored.
  6. If enough nodes agree the proposed block is a valid one, it will be added to the global unique the blockchain; and all the nodes need to sync up their local blockchain with the global one.
  7. Now, the transaction created in 2 will be stored in the global blockchain forever and be trusted by all that it is a valid transaction. No dispute.
This is basically the protocol used by BitCoin to propagate & validate the transaction, arriving at a consensus if the transaction is valid or not, in a fully distributed peer-to-peer system.


We’ll look at in the details in next article some of the concepts we touched lightly such as proof-of-workand what is mining really. It will be more technically focused.
Stay tuned.

Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.

You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.

Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.