Blockchain Technology

and
Cryptocurrency: Blockchain
Ashok Kumar Turuk

1
Building the blockchain
 Lisa can delete transactions because
no one can prove that the list of all
transactions has changed

2
Building the blockchain
 A blockchain is a chain of blocks.
 These blocks contain transactions, and
each block references its predecessor
 Each block has an implicit height that says
how far it is from the first block
 The first block is called genesis block has a
height 0
 The last block is called chain tip
 But each block also contains a block header
to protect the integrity of the contained
transactions and the blockchain before it.

3
Building the blockchain
 Each block contains one or more
transactions and a block header.
 The block header consists of
 The double SHA256 hash of the
previous block’s header
 The combined hash of the transactions
in the block, the merkle root
 A timestamp of the block’s creation
time
 Signature of the block header

Build a Block: Create a block template, Sign the block template to make it complete, and Publish the block

4
Block templates
 Create a block template, a block without a
signature
 Collects several transactions and put in the
block.
 Creates the block header.
 Creates the previous block ID by hashing the
previous block header and putting the result in the
new block header.
 The merkle root is built using the transactions in the
block template, and the time is set to the current
time.
 The first transaction in the block is a coinbase
transaction

5
Signing the block
 Sign the block header using the
private key
 This digital signature commits to
 The previous block ID, which means the
signature commits to the entire
blockchain before this new block
 The merkle root, which means the
signature commits to all transactions in
this new block
 The timestamp

6
Publishing the block
 Once the block is signed make it
available to verifiers

7
Transaction selection
 Select anything from zero transactions
to all unconfirmed transactions.
 The transaction order isn’t important
as long as all transactions spend
outputs already present in the
blockchain or in the block being built

8
Why use a blockchain?
 What will be problem signed all
transactions ever made in one big
chunk every 10 minutes?
 Problem with this approach:
 Time to sign and verify increases with
increase in number of transaction.
 It’s hard for verifiers to know what’s new
since the last signature. This information
is valuable when maintaining the UTXO
set.
 Using the blockchain, sign only the
most recent block of transactions also
signing all historic transactions
indirectly via the previous block ID
pointer 9
Lightweight wallets
 Verifier of the blockchain use  A full node knows about all
software to downloads the entire transactions since block 0, the genesis
blockchain and keeps a UTXO set up to block.
date at all times
 A full-node users don’t have to trust
 So that they are sure that they have valid
financial information someone else with providing them
with financial information: they get
 This software needs to run nearly all their information directly from the
the time to stay up to date with newly blockchain.
produced blocks.
 Wallet user down only the relevant
 This running software is called a full block of data
node.

10
Lightweight wallets
 Developers of full-node and the  Suppose John’s wallet contains two
wallet cooperate to let wallets addresses, @a and @b, and he wants
connect to full nodes over the to receive notifications from a full
internet and get relevant block data node about transactions concerning
from those nodes in a way that his wallet.
doesn’t require huge amounts of data
traffic.
 Wallets are allowed to connect to any
full node and ask for the data they
need.

11
Lightweight wallets
 John’s Wallet asks the full node for all
block headers since the wallet’s last
known block header and all
transactions concerning John’s
addresses.
 The cafe’s full node sends all
requested block headers to the wallet
and at least all transactions
concerning John’s addresses.
 A partial merkle tree that proves that one
or more transactions are included in the
block

12
Merkle trees
 Calculate the merkle root by creating
a hierarchy of cryptographic hashes, a
merkle tree
 The transactions are ordered the
same way they are in the block.
 If the number of items is odd, the last
item is duplicated and added last.

13
Merkle trees
 This merkle root is written into the
block header.
 If any transaction is added, deleted, or
changed, the merkle root must be
recalculated

14
Proving that a transaction is in a block
 How can the full node provide proof
to the wallet that Tx is included in the
block?
 It can provide a partial merkle tree that
connects Tx to the merkle root in the
block header.
 The lightweight wallet will then use
this information to verify that Tx is in
the block by calculating the
intermediary hashes toward the root,
and verify that the hash of Tx is
among the hashes provided by the full
node

15
Proving that a transaction is in a block

The bare minimum to prove Tx2 is in the The lightweight wallet verifies that Tx2 is in the
block. The full node sends this to the block by reconstructing the merkle root
wallet

16
Creating the partial merkle tree
 The partial merkle tree is a pruned
version of the full merkle tree,
containing only the parts needed to
prove Tx2 is part of the tree.
 The full node sends three things to
the wallet:
 The block header
 The partial merkle tree
 Tx
 The partial merkle tree consists of
 A number indicating the total number of
transactions in the block
 A list of flags
 A list of hashes
 The block header together with the
partial merkle tree are often referred
to as a merkle proof
17
Creating the partial merkle tree

To construct the partial merkle tree, the full node examines the hashes in the merkle tree,
starting at the merkle root and moving downward in the tree, left branch first

18
Verifying the partial merkle tree
 The wallet has received a block
header, a partial merkle tree, and the
transaction Tx from the full node.
 The wallet needs to verify that Tx is
indeed included in the block.
 The goal is to verify that there’s a way to
“connect” Tx to the merkle root in the
block header.
 It starts with verifying the partial merkle
tree
 Use the number of transactions
received from the full node to build
the merkle tree’s structure.
 The wallet knows structure of merkle
tree with the value of transactions.
 Compare the calculated merkle root
with the merkle root in the block
header—the actual merkle root—and
verify that they’re the same.
 Check the hash of Tx is among the list
of hashes received from the full node
19
Verifying the partial merkle tree

20
Verifying the partial merkle tree

21
Verifying the partial merkle tree

22
Verifying the partial merkle tree

23