Exploring Hyperledger Fabric v1 – Supply chain demo (Tuna fish shipments)!

Let’s begin with some fundamentals! Adopting Blockchain helps to establish a “System of Proof”, where we can verify the complete historical record of transactions right from the genesis of the blockchain – which is immutable, unbreakable meaning that it cannot be changed, moved, or deleted. The blockchain integrity is protected by Cryptographic hashing, key signature, and timestamping mechanisms.  Every change scheduled and addressed on the blockchain is only appended as a new block to the blockchain in order.

In a supply chain scenario, blockchain brings assurance of integrity while maintaining transparency throughout the process. Linux Foundation has recently introduced a short online course on Hyperledger which is available for free. To showcase this demo, I used the Hyperledger Fabric v1 supply chain example (establish legal Tuna fish shipments) provided. The demo presents how we can transparently manage and regulate tuna fish shipments right from the source and till reaching the end customer while having able to validate the legal source throughout the process and avoid illegal and unrecorded sources. This example uses three actors in the supply chain (Fisherman, Restaurant/Consumer, and Regulator) and we should able to keep track of the record using the distributed ledger to record all shipments right from the legal source of fishing from fisherman and till the restaurant where it ends up. Regulators can query the ledger to verify, and view details of all entries in real-time. Using Hyperledger establishes permissioned private blockchain, where only registered and approved personnel can join the blockchain network using MSPs.

Let’s explore the supply chain scenario using Hyperledger Fabric v1 framework components in terms of its role and relevance on the network. The core components are as follows:

  • Shared Permissioned Ledger contains the current state of all records right from the beginning of the network and the series of transaction invocations. As ledger is an append-only system of records and serves as a single source of all transactions and it is made available to all peers on the network.
  • All Peers commit blocks and maintain a copy of the ledger. Two types of peers: Endorsers and Committer peers. Endorsers simulate and endorse transactions. Committers verify endorsements and validate transaction results.
  • Channels establish transaction visibility to all the members of the network.  Each channel maintains independent chain of transaction blocks containing only transactions specific to that channel.
  • Chaincode  encapsulates the asset definitions and the business logic (or transactions) for creating and modifying (CRUD) which performs transaction invocations on those assets
  • Orderer accepts endorsed transactions, orders them into a block, and delivers the blocks to the committing peers.
  • MSP manage user IDs, and authenticate all the participants in the network.

The demo application made available is written using Hyperledger Node.js SDK.

Try it yourself:

  1.  Have your Ubuntu instance (atleast 8Gb memory and 16Gb storage) up and running. Make sure you installed the following:
    • Docker.io and Docker Compose (docker.io and docker-compose)
  2. Download and install the latest Hyperledger Docker VMs binaries – refer to the following URL:

I used the following URL (please note this changes upon new builds so make sure to download from the latest URL obtained from the link above:

$ curl -sSL https://goo.gl/Q3YRTi | bash

3.  Verify install by running ‘$docker images’ (refer output, should look like this)

4. Download the Linux Foundation (Hyperledger Fabric v1 Education sample repository) and then change the directory to ‘tuna-app‘.

$ git clone https://github.com/hyperledger/education.git
$ cd education/LFS171x/fabric-material/tuna-app

5. Start the Hyperledger Fabric network using the following command:

$ ./startFabric.sh

A typical output would look like this:

6. As the application is written using Node.js SDK, it is critical to Node.js binaries installed and available for use. The application also has dependencies to Go SDK.  So let’s install beginning with Go language and Node.js binaries.

 $ apt install golang-go
 $ go version
 $ sudo bash -c "cat >/etc/apt/sources.list.d/nodesource.list" <<EOL
 >  deb https://deb.nodesource.com/node_6.x xenial main
 >  deb-src https://deb.nodesource.com/node_6.x xenial main
 >  EOL
 $ curl -s https://deb.nodesource.com/gpgkey/nodesource.gpg.key | sudo apt-key add -
 $ apt update
 $ apt install nodejs
 $ apt install npm
 $ node --version && npm --version
 $ npm install
 $ npm rebuild

Discard warnings, not errors! If you encounter errors you may want to start from the beginning.

  1. Finally, register the Admin and User components of our network, and then start the client application using the following commands:
$ node registerAdmin.js

You should be seeing similar output:

$ node registerUser.js

You should see the following output:

8. Now, start the server (server.js) and then try accessing client at the servehost_address:8000.  Make sure port 8000 is accessible from the host. The user can interact with the Web application that enables users to query and update a ledger. Under the hood, the application using the SDK sends the endorsed proposal (automatically) to the Solo ordering service where the order is packaged into a block then broadcasted to all the peers on the network.

$ nohup node server.js &

Try accessing the Web application client using the browser (http://IPaddress:8000/:

2) Try “Query” All or “Query a Specific Tuna Catch”:

You should able to “Create a Tuna Record” and also Change Tuna Holder” and so on.


Further References:



Exploring Hyperledger Fabric v1 – Building your first network (BYFN)

It was quite easy ! Building a private blockchain using Hyperledger Fabric looked relatively simple when I tried building a couple of demos (similar to my Private Ethereum experience)! Lately, I don’t have the luxury of my big old machines at Oracle so I used my own free-tier account on AWS (Thank you AWS). I was able to quickly put up an Ubuntu instance with 2Gb RAM and 8Gb of storage. For doing the BYFN (Building your first network) demo (from Hyperledger Fabric Samples), I thought it should be good enough to run few docker VMs running Fabric peers representing two organizations using a Solo orderer (not using Kafka).

Putting altogether (Here is my recipe):

  1. Ubuntu instance details:

2.  Before you begin installing Hyperledger, make sure your Ubuntu instance is installed with ‘curl’,  ‘docker.io’ and ‘docker-compose’ binaries.  To download and install the latest Hyperledger Docker VMs binaries refer to the following URL:


I used the following URL:

$ curl -sSL https://goo.gl/Q3YRTi | bash

3. To verify install, try running ‘docker images’ :

Also, make sure your current directory and the ~/bin directory is added to $PATH environment variable.  For example, you would add. #export PATH=/home/ubuntu/hyperledger/bin:$PATH

4. Now download the Hyperledger Fabric samples from Github, by running the following commands:

$ git clone -b master https://github.com/hyperledger/fabric-samples.git 
$ cd fabric-samples

5. Now, move to the sub-directory “first-network” and run the following command:

$ cd fabric-samples/first-network
$ ./byfn -m generate

You should be seeing the following output, which will generate the Certificates for the peers, creates the Orderer genesis block, creates a single channel (mychannel) and the anchor peers representing two organization (Org1 and Org 2).

  1. Now, bring up your “first-network” and run the following commands:
$ ./byfn.sh -m up

You should see the following output (I truncated them into multiple screenshots for ease of understanding of what is going on under the hood).

a) Creating the Orgs, Solo Orderer, Peers and the channel (mychannel)

b) Adding Peers to the Channel

c) Identifying the Anchor peers for each org

d) Installation and Instantiation of Chaincode on the peers

e) Querying chaincode and Invoking transactions.

7.  To shutdown your “first-network” and to delete all the artifacts, including stopping the docker VMs,  deleting the chaincode images from the docker Registry removing the crypto material (certs) of the peers. By running the following command:

$ ./byfn.sh -m down

To summarize, we executed the “First Network” script, beginning with generating the certificate artifacts for the organization, created the default channel that connects the orderer with the peers,  created orderer genesis block and then brought up the private blockchain network using the Solo orderer that makes use of two organizations joining peers from both organization to a channel, deploying, and instantiating the chaincode, and execute query and invoke transactions against the chaincode.

This exercise only helps to understand the Hyperledge Fabric components and the simple steps to show how we can quickly spin up and bring down a Hyperledger Fabric network using sample chaincode (chaincode_example02).  You should able to modify the scripts and tweak to run other samples (like fabcar under fabric-samples directory).

Post-Quantum Cryptography (PQC) – Future proofing for quantum-safe encryption !

Everything is hackable! During the RSA Conference 2017 Crypto panel, Prof. Shamir (the letter “S” in the RSA) said, “I think there is a higher chance that RSA could be broken by a mathematical attack.” and he also wondered to note “Quantum Computers” will be a reality soon! That said, the evolution of practical quantum computers are not far away, according to a recent MIT Technology review article, which highlighted most research works on Quantum computing are closer to a solution (Google Quantum Computer!). This means quantum computations can pose some serious threats to existing public-key cryptography mechanisms in use. Are they serious or deluded? Not really, It turns out that they are right to rave.

Even NIST believes on those expert predictions that within the next 20 or so years, the emergence of quantum computers will easily break all public key cryptography and digital signature schemes (ex. RSA, ECDH, ECDSA) currently being used. The impact on symmetric key mechanisms is not that much as it can be handled through larger key sizes (verified by using Grover’s algorithm and Shor’s algorithm — Both are commonly used for breaking Cryptography).

Impact of Quantum Computing on Common Cryptographic Algorithms (Source: NISTIR 8105)

Not surprising, last year (Dec 2016), NIST launched a Post-Quantum Cryptography project initiative to develop quantum-resistant public-key cryptographic algorithms that are secure against both quantum and modern computers currently being used and can also interoperate with existing communications protocols and networks. Currently. there are about 5 algorithm proposals for public-key post-quantum cryptography considered to be quantum-safe are being evaluated.

  • Lattice-based Cryptography: Based on the construction of cryptographic primitives using computational lattice problems. They are known to be secure assuming the worst-case hardness of certain lattice problems as it has proven to be difficult to estimate of the security of lattice schemes. In 2009, Craig Gentry introduced the first fully homomorphic encryption scheme, which was based on a lattice problem. Other known lattice-based cryptographic functions are Indistinguishability Obfuscation, cryptographic maps, attribute-based functional encryption. NTRU encryption and NTRU signatures have been researched for many years without anyone finding a successful attack.
  • Multivariate Cryptography: Based on solving multivariate equations. The Rainbow scheme is based on multivariate cryptography, which could be a potential signature scheme to provide the basis for a quantum secure digital signature.
  • Code-based Cryptography: Based on error-correcting codes, such as the McEliece and Niederreiter encryption algorithms and related signature scheme. EU Commission recommended McEliece public key encryption as a candidate for long-term protection against attacks by quantum computation.
  • Hash-based Cryptography: Based on Hash-based signature schemes like Lamport signature scheme (one-time signature and Merkel signature scheme based on Hash trees (also called Merkel trees — used in Bitcoin Blockchain).They are known to be secure as long as hashes are not invertible and it certainly depends on large hash sizes.
  • Supersingular Elliptic Curve Isogeny Cryptography: Based on the Supersingular elliptic curve and it works like Diffie-Hellman Key exchange methods and its implementation, it can be an alternative to Diffie-Hellman with forward secrecy that can resist and provide protection against quantum computations.

All are quite promising developments, with NIST investing on PQC initiatives newer algorithms and their prototype implementations are evolving faster. Lately, Google Research has evolved an implementation of Lattice-based Cryptography using Ring Learning-with-Errors (RLWE) algorithm has integrated into OpenSSL, which can be potentially leveraged as a potential alternative to current public-key encryption schemes for providing post-quantum security for TLS and IPSec/IKE.

Quantum-safe Blockchain ?

Looking into the Public-key infrastructure risks with the impact of quantum computing, As we think, Blockchain is potentially vulnerable because of its reliance on PKI based digital signatures and hashing algorithms. The heavy use of Hashing algorithms will have a lesser impact as the chain can be easily enhanced by upgrading it from SHA-256 to SHA-384 to SHA-512 and so on. (For example, Bitcoin address is just an SHA-256 hash of your public key).  The interesting aspect, in the proof-of-work miners world, there will be an unfair advantage to the miner who uses the quantum computer will get the biggest miner reward 🙂

Update (Oct 16):

How Google’s Quantum Computer Could Change the World (Wallstreet Journal, Oct 16)



NIST IR-8105 – http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8105.pdf

NIST PQC Project initiative – https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/



Bye Bye Oracle !

      No Comments on Bye Bye Oracle !

Thanks for everything, indeed I feel it as an amicable separation. From Sun JavaSoft (1999)  to Oracle Cloud Engineered Systems (Sep 2017), it has truly been my privilege and honor to work with many of the great tech leaders at Oracle/Sun.

Will certainly miss you all..will do connect over the net with my new experiences… I probably will be doing something more connected to Blockchain and FinTech! Ofcourse, I will be also doing more blogging now on… It’ll be easier now as I can assume that my views will not be taken as Oracle’s anymore 🙂


Application Container Security Guidance from NIST (Docker Containers)

NIST released an Application Container Security publication (SP 800-190), which delves into the major security risks and concerns related to Container images, registries, OS, orchestration, network isolation. It also presents a long-list of proactive countermeasures and mitigation recommendations for the known risks and example scenarios on how to address container security threats with the recommended countermeasures.  Although it is a quite high-level document, it details well enough for evolving security architecture using container technologies particularly securing Docker containers and Kubernetes orchestrator.

Here is the publication:


Unpacking HyperLedger Fabric 1.0 – Under the hood of a Permissioned Blockchain

It’s been a while I had been following the “HyperLedger” project initiatives under Linux foundation –  it is growing faster than I thought (Not sure, when Oracle will join HyperLedger..probably they are annoyed by HyperLedger use of RockDB, CouchDB)! I attempted to test drive HyperLedger 0.6 before — it didn’t get me anywhere with too many dependencies.  That said, a couple of months ago Linux Foundation released HyperLedger Fabric 1.0,  quite promising as it claims to be a  blockchain platform for deploying private Permissioned Blockchain.

Unlike Bitcoin and Ethereum based blockchain network which allows unknown and anonymous entities collaborate and trust each other on transactions using a “Proof-of-work” based consensus protocol,  whereas HyperLedger Fabric 1.0 allows to establish and deploy a “Trusted Members only” blockchain which means everyone knows each other and their identities. This makes it so compelling to be used within a group of legal entities or consortium of organizations using a well-established Identity management or Federated Identities over trusted networks. More importantly, HyperLedger does not support a CryptoCurrency. Certainly, it makes a great case for HyperLeger Fabric 1.0 deploying Private and Permissioned Blockchain which significantly reduces the risks of privacy and confidentiality breaches in sharing information and trusted business process collaboration without intermediaries.

HyperLedger Fabric 1.0

If we unpack and deploy HyperLedger Fabric 1,0 and it’s components, we will find the following core components :

  1.  Membership Service Provider (MSP) –  It provides the Identity management service (for establishing a member-only permissioned blockchain) that allows enrollment of members and establishes rules and access control lists (authorization of access rights and privileges). It makes use of its own PKI provider (Certificate Authority – CA) to issuing Public/Private keypairs (ECDSA) and associated X.509 certificates that can be used to identify peer nodes, Orderer (Ordering services), and for all enrolled members. It provides all required cryptographic mechanisms and CA services intended for issuing, validating, managing and till revoking certificates and validating digital signatures (cryptogen). Each participating organization peers or member can have its own MSP on a HyperLedger fabric network.
  2. Chaincode (Smart Contracts) – It holds state and ledger data by managing the lifecycle of transactions representing the business logic, rules, and policies executed within a transaction as agreed to by the participating members of a HyperLedger Fabric network. Chaincode defines endorsement policy and instantiates them and assign which peers need to endorse the transactions.  It also initializes and manages the Shared Ledgers through transactions. In HyperLedger Fabric 1.0, the Chaincode submitted by applications runs in a separate Docker container. The Chaincode can be created using APIs like Go, Node.js and Java (in the future — according to spec).           
  3. Peers – They are nodes that maintain the state and copy of a shared ledger.  Peers are authenticated by certificates issued by MSP. In HyperLedger Fabric, there are three types of peer nodes depending upon the assigned roles:
    • Endorsing Peers (Endorsers) – The endorsing peers take up the role of endorsing transactions before it is ordered and committed as per the policy defined in Chaincode. The client application creating the transaction and sends it to endorsing peers as per the policy in chaincode.  The endorsement policy is instantiated at the chaincode of the client application and forwarded to the endorsing peers. The endorsing peer evaluates and validates the transaction and produces an endorsement signature and then returns it to the application. There may be one or more pre-specified set of endorsing peers involved as per the endorsement policy. The transaction is evaluated and declared valid only if it has been endorsed by the endorsing peers as per policy.
    • Ordering Service Nodes (Orderers) – All transactions from the network are received by the orderer and it orders and groups them and then packages the transactions and creates blocks. The orderer service delivers blocks to the committing peers allowed to be part of a Channel. The orderer services do not review transaction information. The orderer makes guaranteed atomic delivery of blocks to committing peers on the channel. The orderer supports multiple channels using a publish/subscribe messaging system (based on Apache Kafka and Zookeeper). The ordered provides a practical Byzantine Fault tolerance for failures without a single-point of failure.
    • Committing Peers (Committers) – They receive blocks from Orderer service, which already endorsed by the endorsing peers. The Committing peers ultimately commit the transactional state by adding the blocks to the ledger. Before commital, the peers validate or invalidate the transaction by verifying if the endorsement policies are met, authenticate the signatures and also verify the version info (if there is any double spending).
  4. Channels – To ensure private and confidential communication between privileged member nodes, HyperLedger Fabric uses the notion of “Channel” specific to members and their shared ledger. In simpler terms, each channel corresponds to a shared ledger and intended executing a transaction on the network between peers using that ledger. Channels help to partition the fabric exchange confidential private transactions with the isolation of traffic between members and establish data privacy by separation of ledgers per channel.  The separation of the ledger by defining the specific channel for each ledger and peer node memberships are defined in Chaincode configuration (configtx). It is stored in the Genesis block of the ledger, which also stores the members, policies, and anchor peers.  The Genesis block defines the read/write access on a channel. Realistically, this is accomplished by Kafka as each channel maps to Kafka topic.
  5. Shared Ledger  –  The ledger maintains an append-only, tamper-proof sequential system of record and log of all transactions and successful/unsuccessful state changes from the beginning as “cryptographic hash-linked blocks” submitted by all peer nodes in the Hyperledger fabric network. All transaction results are committed to the ledger as a set of Key/Value pairs. The ledger stores all key/values included in the transactions specific to the channel – It is also referred to as World State Database.  HyperLedger fabric by default configures a LevelDB in all peers as Key/Value pair database, however, users can use CouchDB.
  6. Gossip Network Protocol –  The Gossip protocol is being used for “data dissemination” and to manage discovery and identification of peers, relaying new block information and synchronizing the state of ledger information to all participating peers.  As the data being sent are signed and verified at the receipt, there is no chance for spreading messages from unauthorized members.

HyperLedger Transaction Flow:

Assuming the HyperLedger Fabric 1.0 up and running, in a typical transaction flow of asset exchange:

  1. All application users and peer node members are registered in the MSP and issued with Keys/certificates from the CA for authenticating the network.  The Chaincode representing the initial state is installed on the peers and the channels are active.
  2. The application client initiates a transaction (Client A makes a request to Client B to transfer an asset). The endorsement policy states that the request must be endorsed by Peer A and Peer B.
  3. The application submits a transaction proposal to the endorsing peers A and B.
  4. The endorsing peers receive and verify the transaction proposal and its signature, then executes the transaction and return a signed proposal response back to the application client.
  5. The application client verifies the responses from the endorsing peers. It assembles the response into a transaction and sends it to the Orderer service.
  6. The Orderer services order the transactions chronologically and package those transactions as blocks specific to a channel.
  7. The Orderer service delivers the blocks of the transactions to all the peers on the channel.
  8. The peers perform the validation of the blocks for endorsement policy, signatures verification and version info,  and finally appends the block to the chain and commit the state database – Notifies the application client.

Data Protection & Crypto Key security?

Just wanted to share a known risk:

  • HyperLedger Fabric certainly assures data privacy by providing support for segregation of channels between nodes based chaincode and ledgers and data confidentiality/integrity during transit using TLS 1.2 protocol.  However, there is no assurance for data protection at rest and security of cryptographic material, particularly private keys.  Users may choose to use File system encryption options like dm-crypt (Linux) or Bitlocker (Windows) and using PKCS#11 integrating Hardware security modules (HSMs) in each peer for securing private keys.

I will post the cheatsheet of detailed steps for putting together a HyperLedger Fabric 1.0 setup for testing purposes…  Stay tuned.  Indeed,  HyperLedger Fabric 1.0 is promising.  I also noticed, HyperLedger Fabric 1.0 has an optional HyperLedger Fabric CA — Which I am yet to review, that potentially give an option for integrating HSMs.



Deciphering Blockchain – Role of Cryptographic Hashes and Digital signatures

In a Blockchain infrastructure, trust is built using cryptographic hash functions and Public-key cryptography using digital signature mechanisms.  If we unpack the building blocks of a typical blockchain infrastructure – It relies on a multi-party peer-to-peer transactional network backbone without relying on a central authority. On the blockchain network, the peers create transactions, collaborate on transactions, validate and verify the transaction for correctness and may choose to endorse or reject them using a consensus protocol. Each peer node on the network collects those series of transactions, once endorsed and committed by their peers they are grouped and stored as blocks in a single system of record keeping called Ledger. The copies of the blocks are distributed to the peers by replication and then the blocks are synchronized into each of their ledgers. To ensure “Proof-of-Work” and assuring the authenticity and data integrity of the ledgers in all peers with indelible record keeping, non-repudiation, and tamper-proof immutability, the stack of transactions are validated and endorsed by a multi-party consensus protocol that applies one-way hash functions and digital signatures in each block before it is stored in the distributed ledger. As a result, every committed blockchain transaction results including valid cryptographic material in the block.

Relevance of Hash and Signatures in Blockchain

Before we delve into blockchain representation of hash and digital signatures,  for those who needed some background on the usage and the relevance:

  • Creating a Hash is a mathematical/cryptographic function which takes an input message (alphanumeric string) and converts it to a fixed-length alphanumeric string. As each hash produced for a message is unique, it acts like a signature for the provided message and the hashing process is irreversible.  With hashes, the blockchain creates a linked list of data and a hash pointers which point to its previous block and its next block, hence it results in creating the blockchain. Use of hashes in the blockchain helps to demonstrate “Proof-of-Work”, assures maintaining data integrity and keeping the ledger tamper-resistant. In Blockchain, the cryptographic hash algorithms for creating hashes are SHA-256 and RIPMD-160.
  • Creating digital signature is a mathematical/cryptographic function based on public-key cryptographic mechanisms. Using public-key crypto algorithm, we can generate a Public/Private key pair both are mathematically linked. The private key will be kept secret by the owner and the public key can be distributed publicly. To create a digital signature, the owner/signer creates a one-way hash of the message (alphanumeric string) to be signed. Then the owner uses the private key to encrypt the hash. The encrypted hash is referred to as a digital signature. Creating a hash to fixed length value and encrypting the hash makes a smaller size which is easier to verify. To verify the digital signature, the receiver uses the public key to decrypt the hash and recomputes the hash for the message and checks to match the value of the hash sent to verify if the document is modified.  In blockchain infrastructure, a Wallet software program is used to generate the public/private key pair and store the private key of the owner. Each blockchain node owner owns Public/Private key pair, where the public key is used to create the hash addresses and the corresponding private key is used for signing (encrypting the hash).  The verification of the signature using the public key can be done by decrypting the hash and verify the hash value.  In a Blockchain, the public-key cryptographic algorithm used for creating the digital signature is Elliptic Curve Digital Signature Algorithm (ECDSA).

How is it being used in BitCoin?

In the bitcoin world, typically a bitcoin address is a 160-bit hash of the public key portion of a public/private key pair of a node owner. The bitcoin address represents a destination of a payment. “Pay to Public Key Hash (P2PKH)” is the standard format for representing Bitcoin address, it refers to Pay to a hash of a public key (P2PKH)of the owner – P2PKH addresses start with “1”.  Bitcoin also supports another format which refers to P2SH (Pay to Script Hash) address – which starts with 3.  In a typical bitcoin user scenario, the bitcoin wallet collects entropy (random numbers) and then uses it to create an ECDSA private key and then derives a public key related to the private key. Using public key (as P2PKH) the owner can send and collect bitcoin payments. To create a bitcoin address, the wallet hashes the public key with SHA 256 and the result with RIPEMD-160. The waller adds the bytes 00 as a prefix which is called the version byte (as a result P2PKH addresses starts with a base58 prefix 1) and four checksum-bytes (as error checking code) added at the end of the resulting hash string. In case of P2SH address, the sender pays to the hash of a script. In case of P2SH, the wallet uses the prefix 05 (as a result P2SH addresses starts with a base58 prefix “3”).  Thus the Private Key is used to generate a signature for each blockchain transaction (cryptocurrency) the owner sends out, which confirms that the transaction is initiated by the owner’s private key and it cannot be tampered by anyone. To receive a blockchain transaction (cryptocurrency) from a sender, the sender uses the hash of the owner’s public key which corresponds to the owner’s private key.

Creating a Blockchain address using Hash and Digital Signature (ex. Bitcoin Address)

Starting with the public key K, we created the SHA256 hash and then created the RIPEMD160 hash. As a result, it will produce a 160-bit (20-byte) number., where K is the public key and BA is the bitcoin address.

Bitcoin address BA =  RIPEMD160(SHA256(K))

In addition, we will add the Version Prefix and Checksum.  The resulting Bitcoin address is delivered to the users in “Base58Check” encoding.

An example P2PKH address would look like this:


How about Ethereum?

Like Bitcoin, Ethereum also uses ECDSA algorithm for creating digital signature but for creating hashes Ethereum uses Keccak-256 as its hashing algorithm. Both Bitcoin and Ethereum use Cryptocurrency wallets programs to store public and private keys and interface with the blockchain network to enable users to send and receive cryptocurrencies.

How simple is a CryptoCurrency Wallet?

Blockchain is the most popular wallet that supports both Bitcoin and Ethereum networks.

Here is an example:

Example – BitCoin Wallet

Anatomy of the Blockchain and understanding “Proof-of-Work”

We keep hearing the hype about Blockchain particularly its guarantee for securely providing tamper-resistant immutable record keeping. What it basically means that Blockchain records every transaction on the network, whether it is a single transaction of a payment or multi-step transaction of a workflow — Each transaction is represented as a block. Typically, the resulting blockchain ledger will be represented as a series of blocks connected together, where each block is made up of a header block that contains its metadata information, which includes its previous “parent” block HASH, Merkel root HASH and a NONCE, then followed a list of transactions. The blockchain in the ledger is established by referencing the “parent” block HASH.  The first block in the chain is referred to as “Genesis Block”, which is identified as “0”.  Any invalid block off of the chain, are referred as “Orphaned blocks”, which will be removed by the consensus protocol.

Genesis Block “0” of BTC (Source: www.blockchain.info)

For better understanding, you may visit www.Blockchain.info and take look at the “Block 0” (just type 0 in the search box), you should able to see the genesis block – the number of the transaction occurred was just ONE, you should see the HASH for this block, previous block HASH as “0000000000000000000000000” and you should see the HASH of Merkel root and the next HASH of the next block. Now, if you look at the “Block No. 150000” — You should see the number of transactions as 10, and see the HASHes of this block, previous block, next block and the hash of the Merkel root.

Block #150000 of BTC. (Source: www.blockchain.info)

So what is “Proof-of-Work”?

Based on my review, in a Bitcoin chain usually, it takes about 10 – 15 minutes for creating a block. In the Ethereum (TestNet), it takes about 5 seconds to create a block. If we look at the underlying process, in the blockchain network there are peer-to-peer nodes on the network who are intended to perform mining, who process by collecting the transactions relayed on the network and add them into a block – This process is referred to as proof of work.

Building the blockchain

Typically a block will represent one or more transactions. There is a Block reward attached to each block.  When the miner finishes building the block, the miner must solve a HASH puzzle applied on the transactions.  Only when a miner successfully solved the puzzle will be allowed to broadcast the block relayed on the network.  The block will include the solution to the puzzle in the block header, which is called a NONCE. Once the block is relayed on the network, the other peer miners on the network will receive the block and validate the block and append to their blockchain ledger. This assures only valid blocks are added to the chain and all other blocks are left as “Orphaned blocks”. To avoid orphan blocks, miners should always work on the longest chain as shorter chains usually have the stale blocks called “Orphaned blocks”.  The process of mining ultimately validates, finalizes and endorses the new transactions as a new block and append them to the blockchain ledger.

How can I test-drive Bitcoin or Ethereum?

To test drive Bitcoin or Ethereum blockchain, I would recommend using TESTNET of Bitcoin or Ethereum networks. The cryptocurrencies mined on the test networks (TESTNET coins) has no real value. The TESTNET is intended for testing purposes and it provides a sandbox environment for testing Bitcoin or Ethereum frameworks. You can try mining your own test BitCoins or Ethereum TESTNET coins by setting up a BitCoin or Ethereum nodes. Usually, the HASH complexity is low and it is easy to solve the puzzle and obtaining a reward on the TESTNET.

https://en.bitcoin.it/wiki/Running_Bitcoin  (Follow the instructions for downloading bitcoind and make sure to use -testnet runtime option)

https://testnet.etherscan.io  (Follow the instruction for downloading Ethereum and using testnet)

For reviewing your mined blocks on the TESTNET, check out the following URLs (based on your choice):

https://testnet.blockexplorer.com  (For BitCoin TESTNET)


https://kovan.etherscan.io (Ethereum TESTNET Kovan)

https://ropsten.etherscan.io (Ethereum TESTNET Ropsten)



The Internet of Money – Getting excited about Bitcoin and Blockchain


“Money is as old as our civilization” !  How technology has transformed the concept of money from exchanging rocks, metals, paper, plastic, and plastic to Bitoin..Andreas M. Antonopoulos breaks down everything to layman terms even I can understand!  How people and network-centric and protocol form of cryptocurrencies will dominate the next centuries allowing a new financial integration that the world has never seen before..

If are curious to know more, this book is a collection of talks by Andreas and aims at getting people excited by the possibilities of Bitcoin, the platform, the blockchain and decentralized, network-based currencies.

Read this book.

Blockchain – Cutting through the hype !

      No Comments on Blockchain – Cutting through the hype !

First, I am not a BitCoin investor or miner (perhaps in the future)…but it’s been a while I had been following BitCoin’s underlying technology called “Blockchain”!  In fact, Bitcoins value hangs on the trust provided by Blockchain technology! Quite fascinating – Blockchain facilitates a way where multiple parties who remain anonymous can trust and collaborate each other using a consensus-based protocol and without using a central authority. Certainly, it introduces us to a brave new IT world relying on programmable transactions on a network using distributed ledgers built using PKI based cryptographic mechanisms!  The distributed ledger fabric assures a shared system of trusted record keeping for a business process where multiple business stakeholders can participate and the ledger is shared between the members and each maintains their own copy of the ledger.  As it is a distributed ledger over the network, there are no intermediaries or central authority, and the process is very transparent, auditable, tamper-resistant and there is no risk of ledger tampering and fraud.

In a typical scenario, when a transaction occurs, each transaction is added to a block. Each block is connected to one before and after in the ledger as a chain. This means groups of transactions blocked together and fingerprinted using hashing mechanisms and appended to the ledger as part of the chain.  The blocks are irreversible. More importantly, no transactions can be added to the chain without the participating members’ consensus. The consensus is built using a set of policy checks that provide full-circle validation including identity verification, versioning and endorsement for the correctness of the transaction flow since the beginning of the transaction and till its commitment. Once committed to the ledgers, blockchain provides a single system of record for the business.

Not just Cryptocurrencies…Blockchain can have other deployment Models!

Blockchain is usually deployed in one of the following three different deployment models —

  • Permissionless Public Blockchain – Deployed over Internet accessible by anonymous entities (ex. Bitcoin world)
  • Permissioned Private Blockchain – Members trusted based on Identity management process within or a group of organizations or a consortium of legal entities using their Federated Identities over Trusted networks.
  • Private Blockchain – Typically deployed within an organization’s Intranet

Just not because I am passionate about its cryptographic underpinnings, by design the data exchanged and stored in Blockchain network remains trusted and tamper-resistant by distributing them with a shared set of business processes and rules using smart contracts and a consensus protocol that builds on endorsement policies and correctness of committed transactions, assuring they are authenticated, authorized and cryptographically signed and verified using hashing and multi-signatures.

We may think now that Blockchain may not solve all the problems for all IT business models…however, it is NOT a hype as there are many viable use cases for this technology, where trust of business transactions and data are deemed critical. Indeed, sooner in the blockchain we all trust!

Before I get started, I found the BBC story on “Bitcoin and Blockchain” very helpful:

BBC Story: Bitcoin and Blockchain