Unit 5 – The

Blockchain
Text Book
Grokking Bitcoin
Authors
Kalle
Rosenbaum
Chapters 6
and 4
 Introduction
• Considering the Cookie Token (CT) system, what if Lisa can alter or remove the
transaction record from the spreadsheet.
• This issue is discussed with the help of blockchain.
• Blockchain will provide cryptographic proof of fraud if Lisa deletes or replaces
transaction.
• It also introduces a lightweight wallet, or simplified payment verification (SPV)
wallet
 Building the
Blockchain
• The idea is what if we could change the system to make it provable that Lisa has
fiddled with history?
• The solution is to replace the spreadsheet with the blockchain
2

1 ( 3
)

4
 Zoomed View of
1. Previous Blockchain
1. Also called 5. Digital Signing 4. Merkle Root Hash
Block hash as block ID

2. Timestamp

3. First Transaction
 Lisa Builds A
Block
• When Lisa is about to create a new block. She’ll do the following:
1. Create a block template
2. Sign the block template to make it complete
3. Publish the block

Step 1:
Creating a
block
template
for block
number 20
 Lisa Builds A
Step 2 - Signing the block Block
• Lisa uses her private block-signing key to sign the block header. This digital
signature commits to
• The previous block ID, which means Lisa’s 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
1
Step 2:
Signing of 2
block
 Lisa Builds A
Block
Step 3 – Publishing the block

Step 3:
Publishing
the block
number 20
 Lisa Builds A
• Transaction Selection Block
• She can select anything from zero transactions to all unconfirmed transactions
• Transactions must be ordered in spending order. Otherwise, there are no restrictions.

These are valid transactions as they are in spending order. Meaning every
transaction in this block spends transactions which are already in blockchain.

These are invalid

transactions as a transaction
Tx1 spends a transaction Tx3
1 3
which is appearing after Tx1
 How does this process protect you from deletes?
• Suppose Lisa wants to eat a cookie without paying for it. She creates a transaction and
puts it in the block she’s currently working on.
• She creates the block header, signs it, and writes the block to a new file (block_21.dat)
in the shared folder.
 How does this process protect you from deletes?
• The cafe watches the shared folder for incoming blocks.
• Verifying a block involves verifying the following:
• The block-header signature is valid. The signature is verified using Lisa’s public key obtained from the bulletin
board or intranet.
• The previous block ID which is block 20 in this case.
• All transactions in the block are valid. This uses the same verification approach using a private unspent
transaction output (UTXO) set.
• The combined hash of all transactions matches the Merkle root in the block header.
• The timestamp is within reasonable limits.
 Can Lisa undo this payment without getting
• noticed?
Her only option is that Lisa makes another, changed version of block 21 that doesn’t
include her transaction and
• She writes this new block to the shared folder as block_21b.dat.
 Can Lisa undo this payment without getting noticed? -
No
• When Lisa adds the new block-21 file, the cafe will discover that there’s another
version of the block in the shared folder
• Thus, cafe knows that Lisa created two different signed versions of the block 21 and
the signature proves that it is Lisa who did that (and no one else)
What if – while Lisa creates new version of block 21, block 22
and 23 are already there?
• Now Lisa needs to make three alternative blocks: 21, 22, and 23.
• These modified blocks must existing valid blocks
 Why use a blockchain?
OR
Why use a complicated structure and singing?

14
 Why
Blockchain?
• Blockchain used a complicated way to sign a bunch of transactions.
• Will not it be much simpler if Lisa just signed all transactions ever made in one
big chunk every 10 minutes?
• Will not this accomplish the same goal?
• But this approach has several problems:
• As the number of transactions grows, the time it takes for Lisa to sign the entire set will
increase.
• The same goes for verifiers—the time it takes to verify a signature increases with the total
number of transactions.
• It is hard for verifiers to know what’s new since the last signature. This information is
valuable when maintaining the UTXO set.
 Why
• By using the blockchain, Lisa hasBlockchain?
to sign only the most recent block of transactions
• By doing so, Lisa still, indirectly via the previous block ID pointer, signing all historic
transactions.
Lightweight Wallets

17
 Lightweight
• Some of the coworkers inWallets
the Lisa’s company wants to keep with them the valid
and up-to-date financial information
• They use software that downloads the entire blockchain and keeps a UTXO set
up-to-date at all times
• This software needs to run nearly all the time to stay up to date with newly
produced blocks. We call this running software (on a device) a full node
• A full node knows about all transactions since block 0 -- the genesis block
• The company and the cafe are typical full-node users
• Anyone is free to run this software as they please
 Lightweight
Wallets
• Usually, the users make use of mobile app (wallet) to manage their private keys
and send or receive money.
• Most wallet users are on a mobile data plan so they do not want to waste
bandwidth on downloading all block data (i.e., blockchain database)
• Downloading all that data would only make their phones run out of data traffic
without providing useful information
• This is because only few blocks will have the transactions related to them
• Any wallet-based user is allowed to connect to any full node and request for
exclusively the data blocks related to that user
• For instance, consider a use John  His wallet contains two addresses @a
and
@b
• Now, John’s wallet want to receive notifications from full node about the
transactions concerning his wallet (i.e., related to two addresses)
 Information Exchanged Between Lightweight Wallet and Full
•Node
When the John’s wallet connects to the full node, following two steps are performed as a
synchronization phase:
• Step 1: John’s wallet send a request to the full node for sending following:
1. All the block headers which the wallet does not know since the last connection
• Example current block is 556 but wallet just knows 501 blocks  pending updates are from 502 to 556
2. All the transactions which are related to the addresses belonging to John’s wallet
• Step 2: The full node responds by sending all the pending block headers plus (at least) all the
transactions related to the John’s addresses

Step 1

Full Node Step 2 Lightweight

Wallet
 Information Exchanged Between Lightweight Wallet and Full
•Node
In the step 1 while sending the request to full node, John’s wallet does not want to reveal all
the addresses (@a and @b) which belong to John  This is to protect the privacy of John
• To hide the addresses the John’s wallet sends a filter called as Bloom filter
• This bloom filter informs the full node which transactions to send to John’s wallet
• To obfuscate the full node from the addresses that belong to John, the bloom filter will tell full
node to send
1. Transactions which belong to John’s wallet
2. In addition, some extra transactions which doe not belong to John
• This way full node does not know which are the addresses that are of John
Step 1
Lightweight
Full Node
Wallet
 Information Exchanged Between Lightweight Wallet and Full
•Node
In the step 2, the full node sends the following to the John’s wallet:
• Block headers which the John’s wallet had missed (so it does not know them)
• Transactions which are indicated by bloom filter sent by John’s wallet
• In addition to the above two things, the full node send partial Merkle tree for the blocks that
contains the transaction indicated by Bloom filter

Step 1
Lightweight
Full Node Step 2 Wallet
 Creation of Bloom
Step 1
public key for address @ and @
a
Filter • three
• Take the Public Key Hashes (PKH) of
b
Step 2
Pass the PKH of address @ from the
hash different functions
a
Step 3
• Now, repeat step 2 with PKH
for address @b
• Take three different hash functions • According to the output hash values • According to the output hash
(produces 3-bit output) set the corresponding index bit of values set the corresponding
• Initialize 8-bit bloom filter with all zeros bloom filter to 1 index bit of bloom filter to 1
 How Full Node Determine which Transactions to Send Using Bloom
Filter?
Block Under Examination
by Full Node
1. There are three transactions
present in block

2. Running the addresses in the

transactions from the same
three hash functions used by
wallet
3. Comparing the results with
the bloom filter sent by
the wallet
• If does not match then
do not sent the
transaction
• If even partially match
then do send the
transaction to wallet
Merkle Tree & Partial Merkle Tree

25
Merkle Tree (Recap From Unit
2)
 Partial Merkle Tree – Proving a Transaction is in a
Block wallet needs a way to ensure
• The lightweight
that subset of relevant transactions sent by full
node are actually a valid part of a block
• Above validation is not possible by
just receiving block header and subset
of transactions
• One simple way is to send the full block (header
plus body) to the wallet but this will make the
job of wallet very difficult – thus not
lightweight
• The solution is that full node creates a Partial
Merkle Tree and sends this to wallet
• Partial Merkle tree contains only the parts of
the hash tree which are required to compute If we have Merkle Root (i.e., Hash1234) and we want to prove
Merkle Root and confirm that a given that Tx2 is part of this tree then we just need values which
transaction is a part of tree are encircled with red color.
• Having Hash1 and Hash2 we can compute Hash12
• Thus, partial Merkle tree is a pruned version • Then having Hash34 we can computer Hash1234
of  We do not need Hash3 and Hash4 values
 Creating Partial Merkle
Tree

At every step, below two actions are performed:

1. Follow the depth first ordering while traversing the hash values, and add the flags Partial Merkle tree contains:
to the list of the flag 1. Number of transactions in a block
2. If the flag is , or if this hash is an interesting txid, add the hash to the list of 2. A list of flags (Cross or Tick
hashes to be included in the partial tree )
Flag means that this hash branch does not contain any info related to txid, and 3. List of subset of hashes of tree
Fag means that this hash branch has information related to txid
Computation of Missing Values of Partial Merkle
Tree
Verifying The Transaction Belongs to Partial Merkle
Tree
2

1
Security of Lightweight Wallets

31
 Facts About Lightweight
Wallets
• Usually, a lightweight wallet provides an easy way to interact with blockchain because
it need light processing and low bandwidth
• As discussed in previous slides, the capabilities of a lightweight wallet are following:
• A lightweight wallet knows the entire chain of block headers.
• When the wallet receives a transaction and a Merkle proof (i.e., partial Merkle Tree), it can verify
that that transaction is contained in the block and that block is correctly signed by the miner
• However, this lightweightness of wallet comes at some cost
• Lightweight wallet can not verify a lot of other things, these are as follows:
• That the script programs in the transaction all return “OK,” which usually means verifying the
signatures of all inputs
• That the spent outputs are not already spent since the wallet does not have the entire blockchain
• That it receives all relevant transactions (may be the full node is hiding and not sending some
relevant transactions)
 Security of Lightweight
Wallets
• So we can say that full node does verification on behalf of the wallet
• Thus, the lightweight wallet has no option other than to trust the full node
• To overcome these issues wallet’s owner can implement two solutions:

First Solution Second Solution

• Keep connections • John (wallet’s
with multiple owner) can
Full full nodes maintain his own
node 1 simultaneously. full node

• This way if one • This full node

full node is becomes his
misbehaving then trusted full node
wallet can get and he connects
relevant the wallet to
Full node 2 transactions from this trusted
other full node node.
 Hierarchical Deterministic (HD)
Wallets
• Usually, a wallet maintains multiple addresses and for each address there is corresponding
private key
• In Hierarchical Wallet (HD) these private keys are organized as an inverted tree

• The key at the root is called master private key

• This master private key is used to derive the two
child keys (one used for shopping and another
used as saving account)
• The shopping and savings key have further child
keys
• Thus, total 5 keys for shopping (numbered 0 to 4)
and 3 keys for savings (0 to 2)
• These 8 (5 Shopping + 3 Savings) keys are leaves
of tree and they are used to generate
corresponding addresses
Hierarchical Deterministic (HD)
Wallets • There is number assigned to each key in the tree
• The child keys are numbered from 0 to upwards
• The master extended private key (i.e., root) is
represented by letter ‘m’
• The unique identifier of each key in the tree is
determined by the complete path from root to
that key (for example – m/1/1 see figure)
• The three processes carried out to create the tree
are as follows:
1. Generating the random seed (usually of 128
bits)
2. Deriving the master extended private key
from this random seed
3. Deriving the descendant extended private
keys
HD Wallet – Extended Private Key
(xprv) The extended private key (xprv) contains
two parts:
1. Private key which is directly generated
by random number generator
• This private key is used to derive
the public key and address
2. Chain code specifies the entropy
when generating child xprv
• Entropy denotes the strength 
Higher the entropy harder it is to
guess the private key
 Deriving a Master Extended Private
Random
Key
Seed

Detailed View

Master
extended
private key

• The
rando
mly
generat
ed
seed is
hashed
 Deriving a Child Extended Private
Key

This figure shows how to

derive the m/1 child xprv key
from the parent xprv key m

• Recall that the parent extended private key is combination of private key plus chain code
• From the private key derive the public key and append the index of the child (here it is 1 since we are working for
m/1)
• The above appended number is hashed using HMAC-SHA512 and the seed value used here is the chain code
• The left 256 bits of the hash value are added to parent private key and the result is child private key
• The right 256 bits of the hash value becomes the child chain code
Extended Public Keys (xpub)

39
 Extended Public Keys
• At times it is required(xpub)
to create different addresses for every new transaction made
• Generating addresses requires public keys which can easily done if private keys are known
• However, giving away or storing private keys on the server is not secure

Not
secure!

The online sales department is thinking to put its

xprv key on the web server so that following
addresses can be generated automatically on
every sale transaction.
 Extended Public Keys
(xpub)
• Hierarchical Deterministic (HD) wallet offers another interesting feature  anyone can create
tree of public keys (and chain code) without need of private keys
• HD wallet allows generation of extended public key (xpub)

• An extended public key (xpub) consists of

following two parts:
1. Public Key
2. Chain code
• Both xprv and xpub have a common thing
which is
chain code
• Recall that public key can be derived from private
keys (but not visa versa), similarly xpub can be
derived from xprv (but not visa versa)
Tree of Extended Public Keys
(xpub)
• This is very similar to the tree of xprv keys
• There is number assigned to each key in the
tree
• The child keys are numbered from 0 to
upwards
• The master extended public key (i.e., root) is
represented by letter ‘M’
• The unique identifier of each key in the tree is
determined by the complete path from root to
that key (for example – M/1/1 see figure)
• The process of tree of xpub keys is shown next
 Extended Public Key (xpub)
Derivation

This figure shows how

to derive the M/1 child
xpub key from the
parent xpub

• The public key is appended with the index of the child (here this index is 1)
• The above appended number is hashed and the seed value used here is the chain code
• The left 256 bits of the hash value is considered as a private key and it public key is derived
• This derived public key is added with parent public key and the result is child public key
• The right 256 bits of the hash value becomes the child chain code
 Security Issue With Extended Private Key
• There(xprv)
is security issue with the normal use of xprv keys. This is explained below.
• As we know from previous discussion, the xpub is kept on web server, whereas, the xprv is kept
securely in the HD wallet
• Suppose an attacker (named Mallory) somehow manages to steal two things: (i) xprv key -
m/1/1, and
(ii) xpub key of online sales account – M/1
• Loosing private key xprv m/1/1 does not matter much as it is just one transaction and thus less
loss
• In this case, the attacker can computer the private key (xprv) of the online sales
 Security Issue With Extended Private Key
(xprv)
• The situation could be even worse if the attacker can somehow steal master xpub (public key)
• Then the attacker can computer master xprv (private key) using master xpub and m/1/1 xprv
• So the question arises that can the extended private key (xprv) made more secure?
• The answer is yes – using the hardened extended private key
Driving Hardened Extended Private Key
(xprv)

• The important difference in

hardened private key is that here
the parent private key is hashed
• The apostrophe in the term m/1’
denotes that private key is
hardened
• Thus, using hardened xprv key
now the attacker cannot do
that minus operation as it could
do before
 Driving Hardened Extended Private Key
(xprv)

• Here, the children of master are hardened i.e. m/0’ and m/1’ (but not the children in next level)
• Even if the attacker steals the master xpub key - M and child extended private key - m/1’/1, the
attacker cannot compute the private key – m/1’