Blockchain Technology 

And Applications
Sandeep K. Shukla
IIT Kanpur

C3I Center
Acknowledgement
• The material of this lecture is mostly due to Prof. 
Arvind Narayanan’s Lecture at Princeton and his book 
on Bitcoin (Chapter 3)   
Mechanics of Bitcoin
 Recap: Bitcoin consensus
Bitcoin consensus enables us to have: 
●An Append‐only ledger of transactions 
●Decentralized consensus with probabilistic 
guarantee 
●Miners incentivized to validate transactions

To incentivize miners within the blockchain we

need the blockchain to have a currency –
blockchains that do not generate currency
cannot have miners
Bitcoin transactions
 An account‐based ledger (not Bitcoin)

time might need to 
Create 25 coins and credit to AliceASSERTED BY MINERS
scan 
Transfer 17 coins from Alice to BobSIGNED(Alice) backwards 
until genesis!
Transfer 8 coins from Bob to CarolSIGNED(Bob)
Transfer 5 coins from Carol to AliceSIGNED(Carol)
Transfer 15 coins from Alice to DavidSIGNED(Alice) is this valid?

SIMPLIFICATION: only one transaction

per block
 A transaction‐based ledger (Bitcoin)
1 Inputs: Ø
time we implement this 
Outputs: 25.0→Alice
change  with hash pointers
2 Inputs: 1[0] address
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)

3 Inputs: 2[0] finite scan to 

check for 
Outputs: 8.0→Carol, 7.0→Bob validity
SIGNED(Bob)

4 Inputs: 2[1] is this valid?

Outputs: 6.0→David, 2.0→Alice
SIGNED(Alice)

SIMPLIFICATION: only one transaction

per block
 Merging value

time
1 Inputs: ...
Outputs: 17.0→Bob, 8.0→Alice
.. SIGNED(Alice)

.
2 Inputs: 1[1]
Outputs: 6.0→Carol, 2.0→Bob
SIGNED(Carol)
..
.
3 Inputs: 1[0], 2[1]
Outputs: 19.0→Bob
SIGNED(Bob)

SIMPLIFICATION: only one transaction

per block
 Joint payments
time
1 Inputs: ...
Outputs: 17.0→Bob, 8.0→Alice
.. SIGNED(Alice)

.
2 Inputs: 1[1]
Outputs: 6.0→Carol, 2.0→Bob
SIGNED(Carol)
..
.
3 Inputs: 2[0], 2[1]
two signatures!
Outputs: 8.0→David
SIGNED(Carol), SIGNED(Bob)

SIMPLIFICATION: only one transaction

per block
The real deal: a Bitcoin transaction
{
"hash":"5a42590fbe0a90ee8e8747244d6c84f0db1a3a24e8f1b95b10c9e050990b8b6b",
"ver":1,
"vin_sz":2,
"vout_sz":1,
metadata "lock_time":0,
"size":404,
"in":[
{
"prev_out":{
"hash":"3be4ac9728a0823cf5e2deb2e86fc0bd2aa503a91d307b42ba76117d79280260",
"n":0
}, 
"scriptSig":"30440..."
},
input(s) {
"prev_out":{
"hash":"7508e6ab259b4df0fd5147bab0c949d81473db4518f81afc5c3f52f91ff6b34e",
"n":0
},
"scriptSig":"3f3a4ce81...."
}
],
"out":[
{
output(s) "value":"10.12287097",
"scriptPubKey":"OP_DUP OP_HASH160 69e02e18b5705a05dd6b28ed517716c894b3d42e OP_EQUALVERIFY 
OP_CHECKSIG"
}
]
}
 The real deal: transaction metadata
{
transaction hash "hash":"5a42590...b8b6b",
"ver":1,
housekeeping "vin_sz":2,
"vout_sz":1,
“not valid before” "lock_time":0,
housekeeping "size":404,
...
}
 The real deal: transaction inputs

"in":[
{
Previous  "prev_out":{
transaction "hash":"3be4...80260",
"n":0
}, 
signature "scriptSig":"30440....3f3a4ce81"
},
(more 
... 
inputs)
],
The real deal: transaction outputs

"out":[
{
output value "value":"10.12287097",
"scriptPubKey":"OP_DUP OP_HASH160 69e...3d42e OP_EQUALVERIFY OP_CHECKSIG"
recipient  },
address?? ...
]
(more 
outputs)
Bitcoin scripts
Output “addresses” are really scripts

OP_DUP
OP_HASH160
69e02e18...
OP_EQUALVERIFY OP_CHECKSIG
 Input “addresses” are also scripts

30440220...
scriptSig
0467d2c9...

OP_DUP
OP_HASH160
scriptPubKey
69e02e18...
OP_EQUALVERIFY OP_CHECKSIG

TO VERIFY: Concatenated script must execute completely

with no errors
 Bitcoin scripting language (“Script”)
Design goals
●Built for Bitcoin (inspired by Forth)
●Simple, compact
●Support for cryptography
●Stack‐based
●Limits on time/memory
●No looping I am not impressed

image via Jessie St. Amand
 Bitcoin script execution example

✓
<pubKeyHash?>
<pubKey>
<pubKeyHash>
<pubKey>
<sig>
true

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash?> OP_EQUALVERIFY OP_CHECKSIG

Bitcoin script instructions
256 opcodes total (15 disabled, 75 reserved)
●Arithmetic
●If/then
●Logic/data handling
●Crypto!
○ Hashes
○ Signature verification
○ Multi‐signature verification
OP_CHECKMULTISIG
● Built‐in support for joint signatures
● Specify n public keys
● Specify t
● Verification requires t signatures

BUG ALERT: Extra data value

popped from the stack and ignored
Bitcoin scripts in practice (as of 2014)
● Most nodes whitelist known scripts
● 99.9% are simple signature checks
● ~0.01% are MULTISIG
● ~0.01% are Pay‐to‐Script‐Hash
● Remainder are errors, proof‐of‐burn
Proof‐of‐burn

nothing’s going to redeem that ☹

OP_RETURN
<arbitrary data>
Should senders specify scripts?

?
I’m ready to pay for my  Big Box
purchases!

Cool! Well we’re using MULTISIG 
now, so include a script requiring 
2 of our 3 account managers to 
approve. Don’t get any of those 
details wrong. Thanks for 
shopping at Big Box!
Idea: use the hash of redemption script

<signature>
<signature>
<<pubkey> OP_CHECKSIG>

OP_HASH160
<pubkey>
<hash of redemption script>
OP_CHECKSIG
OP_EQUAL

“Pay to Script Hash”

Pay to script hash

I’m ready to pay for my  Big Box
purchases!

Great! Here’s our address: 
0x3454
Applications of Bitcoin scripts
Example 1: Escrow transactions

(disputed case)
(normal case)
Pay x to Alice
Bob
Judy SIGNED(ALICE,JUDY)
BOB)
SIGNED(ALICE,

To: Alice
From: 
Bob

Alice PROBLEM:
Pay Alice
x to 2-of-3 ofwants
Alice,to buyJudy
Bob, online from Bob.
(MULTISIG) Bob
Alice doesn’t want to pay until after Bob ships.
SIGNED(ALICE)

Bob doesn’t want to ship until after Alice pays.

 Example 2: Green addresses

004 days since last double 
spend!

It’s me, Alice! Could you 
make out  a green payment  Faraday cage
to Bob? Bank

Pay x to Bob, y to Bank No double spend

SIGNED(BANK)

Alice PROBLEM: Alice wants to pay Bob. Bob

Bob can’t wait 6 verifications to guard against
double-spends, or is offline completely.
 Example 3: Efficient micro‐payments

What if Bob never signs??
Input: x; Pay 42 to Bob, 58 to Alice
all of these  SIGNED(ALICE)
SIGNED(ALICE)___________
SIGNED(BOB)
could be  ...
double‐ Alice demands a timed refund transaction before starting
Input: x; Pay 04 to Bob, 96 to Alice
spends! Input: x; Pay 100 to Alice, LOCKSIGNED(ALICE)___________
until time t
SIGNED(ALICE) SIGNED(BOB)I’ll 
I’m  Input: x; Pay 03 to Bob, 97 to Alice
done! SIGNED(ALICE)___________publish!

Input: x; Pay 02 to Bob, 98 to Alice

SIGNED(ALICE)___________

Input: x; Pay 01 to Bob, 99 to Alice

SIGNED(ALICE)___________
PROBLEM: Alice wants to pay Bob for each
minute
Input: of phone
y; Pay 100 toservice. She(MULTISIG)
Bob/Alice doesn’t want to Bob
Alice
incur a transaction fee every minute.
SIGNED(ALICE)
lock_time
{
"hash":"5a42590...b8b6b",
"ver":1,
"vin_sz":2,
"vout_sz":1,
"lock_time":315415,
"size":404,
Block index or real‐world timestamp 
... before which this transaction can’t be 
} published
Bitcoin blocks
Bitcoin blocks

Why bundle transactions together?
●Single unit of work for miners
●Limit length of hash‐chain of blocks
○ Faster to verify history
 Bitcoin block structure
Hash chain of blocks

prev: H( ) prev: H( ) prev: H( )

trans: H( ) trans: H( ) trans: H( )

H( ) H( )

Hash tree (Merkle 
tree) of transactions in  H( ) H( ) H( ) H( )
each block

transaction transaction transaction transaction

The real deal: a Bitcoin block
{
"hash":"00000000000000001aad2...",
"ver":2,
"prev_block":"00000000000000003043...",
block  "time":1391279636,
"bits":419558700,
header "nonce":459459841,
"mrkl_root":"89776...",
"n_tx":354,
"size":181520,
"tx":[
...
],
"mrkl_tree":[
"6bd5eb25...",
...
"89776cdb..."
transaction  }
]

data
The real deal: a Bitcoin block header

{
"hash":"00000000000000001aad2...",
"ver":2,
"prev_block":"00000000000000003043...",
"time":1391279636,
mining  "bits":419558700, hashed 
puzzle  "nonce":459459841,  during 
information "mrkl_root":"89776...", mining
...
}

not hashed
The real deal: coinbase transaction
"in":[
{
"prev_out":{ Null hash pointer
"hash":"000000.....0000000",
redeeming  "n":4294967295
nothing },  First ever coinbase parameter:
"coinbase":"..." “The Times 03/Jan/2009 Chancellor
arbitrary }, on brink of second bailout for banks”
"out":[block reward
{ transaction fees

"value":"25.03371419",
"scriptPubKey":"OPDUP OPHASH160 ... ”
}
See for yourself!

blockchain.info (and many other sites)
The Bitcoin network
Bitcoin P2P network
●Ad‐hoc protocol (runs on TCP port 8333)
●Ad‐hoc network with random topology
●All nodes are equal
●New nodes can join at any time
●Forget non‐responding nodes after 3 hr
Joining the Bitcoin P2P network

Hello World! 
I’m ready to  5
1 Bitcoin!

7
getaddr() getaddr()
1, 7 getaddr()
8

3
6
2

4
Transaction propagation (flooding)
Already 
heard 
5 that!
1

7
A→B
8
A→B A→B
A→B New 
tx! 3
6 A→B
A→B A→B 2
A→B
A→B A→B
4
A→B
Should I relay a proposed transaction?

●Transaction valid with current block chain
●(default) script matches a whitelist
○ Avoid unusual scripts Sanity checks only...
●Haven’t seen before Some nodes may ignore them!
○ Avoid infinite loops
●Doesn’t conflict with others I’ve relayed
○ Avoid double‐spends
Nodes may differ on transaction pool 
New 
tx!
A→C A→C 5
1 A→C A→B
A→C
A→C 7
A→C A→B
8
A→B
A→B

3
6 A→B
A→B 2
A→B

4
A→B
Race conditions
Transactions or blocks may conflict
●Default behavior: accept what you hear first
●Network position matters
●Miners may implement other logic!
Block propagation nearly identical

Relay a new block when you hear it if:
●Block meets the hash target
●Block has all valid transactions
○ Run all scripts, even if you wouldn’t relay
●Block builds on current longest chain
○ Avoid forks Sanity check
Also may be ignored...
Block propagation Time

Source: Yonatan Sompolinsky and Aviv Zohar: “Accelerating Bitcoin’s Transaction Processing” 2014
How big is the network?

●Impossible to measure exactly
●Estimates‐up to 1M IP addresses/month
●Only about 5‐10k “full nodes”
○ Permanently connected
○ Fully‐validate
●This number may be dropping!
 Bitcoin full node distribution 

RANK COUNTRY NODES

1 United States 2466 (24.32%)
2 Germany 1936 (19.09%)
TOTAL 10140 NODES AT 5 PM ON JAN 23, 2019
3 France 674 (6.65%)
4 Netherlands 484 (4.77%)
5 China 402 (3.96%)
6 Canada 402 (3.96%)
7 United Kingdom 351 (3.46%)
8 Singapore 312 (3.08%)
9 Russian Federation 270 (2.66%)
10 Japan 248 (2.45%)
More (102)
Fully‐validating nodes
●Permanently connected
●Store entire block chain
●Hear and forward every node/transaction
Storage costs
Tracking the UTXO set
●Unspent Transaction Output 
○ Everything else can be stored on disk
●Currently ~61.7 M UTXOs
○ Out of 375 M transactions (as of Jan 2019) 
Thin/SPV clients (not fully‐validating)
Idea: don’t store everything
●Store block headers only
● Request transactions as needed
○ To verify incoming payment
●Trust fully‐validating nodes

1000x cost savings! (200 GB‐>200MB)
Software diversity
●About 90% of nodes run “Core Bitcoin” (C++)
○ Some are out of date versions
●Other implementations running successfully
○ BitcoinJ (Java)
○ Libbitcoin (C++)
○ btcd (Go)
●“Original Satoshi client”
Limitations & improvements
Hard‐coded limits in Bitcoin

●10 min. average creation time per block
●1 M bytes in a block (pre SegWit) 
●20,000 signature operations per block
These affect 
●100 M satoshis per bitcoin economic 
balance of 
●21M total bitcoins maximum power too 
much to 
●50,25,12.5... bitcoin mining reward change now
Throughput limits in Bitcoin
●1 M bytes/block (10 min)  ‐ post SegWit is slightly 
different 
●>250 bytes/transaction
●7 transactions/sec ☹

Compare to:
●VISA: 2,000‐10,000 transactions/sec
●PayPal: 50‐100 transaction/sec
Cryptographic limits in Bitcoin

●Only 1 signature algorithm (ECDSA/P256)
●Hard‐coded hash functions

Crypto primitives might break by 2040...
“Hard‐forking” changes to Bitcoin

5
1 24
Block 23
Block 23

7
That’s  24
Block 23
8 That’s 
crazy  Block 23
24
Block crazy 
talk!! 24 talk!!
I found a nifty  3
6 24 new block! Block
Block 23
24
Block 23 2
Block 23
24
24
4
24
Block 23 PROBLEM: Old nodes will never catch up
Soft forks
Observation: we can add new features which only limit
the set of valid transactions

Need majority of nodes to enforce new rules

Old nodes will approve

RISK: Old nodes might mine now-invalid blocks

Soft fork example: pay to script hash

<signature>
<<pubkey> OP_CHECKSIG>

OP_HASH160
<hash of redemption script>
OP_EQUAL

Old nodes will just approve the hash, not run the
embedded script
Soft fork possibilities

●New signature schemes
●Extra per‐block metadata
○ Shove in the coinbase parameter
○ Commit to UTXO tree in each block
Hard forks
●New op codes
● Changes to size limits
●Changes to mining rate
●Many small bug fixes