Bitcoin Blockchain System

Prof. J. Ujwala Rekha

Introduction
• The public permissionless blockchain is
synonymous with a public blockchain.
• In public blockchain, anyone can join the
network. They can download a copy of the
ledger and initiate, broadcast, or mine blocks.
Users are anonymous.
• In private blockchain, one has to meet certain
pre-requisite conditions to be a member of the
blockchain network.
Key Characteristics of Public blockchain
Organization Type Public
Users Anonymous, but web tracking and cookies
pose a risk to privacy
Access Open and transparent to all
Network Type Decentralized; Zero points of failure
Operation Anyone can read or initiate or receive
transactions
Verification Anyone can take part in the consensus process
to validate transactions and create a block
Immutability Secured by hashing
Consensus Mechanism PoW, PoS, etc.
Incentivization Incentivizes miners to grow the network
Key Characteristics of Public blockchain
Security Security is based on consensus
protocols and hash functions
Performance Higher the security, lower the
performance
Trust Trust-free system; trust is
enforced via cryptographic proof
Transaction Speed Takes about ten minutes for
creating a block
Energy Consumption Very high
Scalability Limited; as the network grows,
the node requirements of
bandwidth, storage, and
computational power
exponentially increases.
When to use Permission-less Blockchain
BITCOIN BLOCKCHAIN
BITCOIN BLOCKCHAIN
• Bitcoin is the first blockchain created and is
public permissionless blockchain.
• It was designed to create a decentralized digital
currency, that is, free from government regulation
and an intermediary.
• The value of bitcoin is the highest across all other
cryptocurrencies available.
• A special software is used to create a bitcoin. This
software is based on blockchain technology.
• People who create bitcoin are called as Miners.
Important Terminology
• Block Frequency – Bitcoin transactions are
registered into blockchain once in ten minutes.
• Mining Pools – Some miners group together in
mining pools to combine their mining
resources for more efficiency and savings.
• Halving Policy – The reward for solving the
puzzle is halved every four years. At present,
miners get 6.25 bitcoins as a reward.
Important Terminology
• Block Header – Block header contains meta data of
the block such as:
– Timestamp – Timestamp indicates UNIX time. It is the
seconds passed after the first of January 1970 and is a 10-
digit number.
– Previous block hash: reference to previous block
– Merkle root: hash or fingerprint of all transactions in the
block
– Difficulty target: The Proof of Work algorithm difficulty
target for this block.
– Nonce: Random number appended with other block
attributes to generate a unique hash for a block.
– Blockchain version: The version of the blockchain software
running when the block was created.
Important Terminology
• Mempool: Transactions are first added to the Mempool
(Memory pool) attached to each node.
– They are unconfirmed transactions, which are to be
included in the block once the combination becomes a valid
transaction.
– Blocks are added every 10 minutes, but transactions happen
all the time.
– Mempool is the staging area for the transactions. A
mempool can have around 10,000 transactions at a time.
– When a miner successfully mines, a set of transactions are
added from mempool to the block, and into the blockchain.
– Once the transactions are added to the blockchain, the same
set of transactions is removed from the mempool.
Important Terminology
• SegWit: The size of the signature and public key
is so large within the transaction that it occupies
more than 60 % of the overall size of the
transaction.
– In the bitcoin protocol, this portion (signature and
public key) is kept out of the block and is distributed
separately.
– This segregation of the signature from the block is
called as Segregated Witness (SegWit).
– Because of SegWit, more (almost double) transactions
can be added into the block.
– SegWit will be sent separately in the network.
Bitcoin Mining
• Miners compete to solve a complex mathematical
problem based on a cryptographic hash algorithm.
• Mining comprises of finding a nonce such that
H(nonce||other-block-attributes)<target
• Since a hash is 64 characters in SHA256, the
population of hash set = 1664=1.16×1077 because each
character is a hexadecimal number.
• If the target hash consists of one leading zero, then the
overall target population reduces by 1/16.
• The probability that random hash value is within limit =
Target Hash Set/Population Hash Set
Bitcoin Mining
• The process of solving the cryptographic puzzle is called
Proof-of-Work or consensus mechanism and it provides
integrity to the blockchain.
• In Proof-of-Work, the nodes pick up transactions with in a
block, validate them, find nonce, and propose a block.
• The mining node that first solves the puzzle, releases Proof-of-
Work to the other nodes for verification to reach consensus.
• The solution to the problem is challenging to produce but easy
for the network to verify.
• The process of mining is exceptionally computation-intensive.
Therefore, the first miner to solve the puzzle will receive
rewards in the form of transaction fees or new bitcoins.
Bitcoin Mining
• To maliciously add a block (solve a puzzle), the miner’s
computer needs to be 51% more potent than other
machines.
• To counteract the high time and energy consumption in
transaction validation some miners group together the
mining pools to combine their mining resources for
more efficiency and savings.
• Mining pools go against the basic principle of
distributed ledgers as a person or group gaining control
of over 50% of the computing power of the network,
usually referred to as a 51% attack, can control the
validation process.
Bitcoin Mining
• Bitcoin mining is of two types – Software
mining and hardware mining
• Software mining can be of two types – Pool
mining or Cloud mining
• There are four types of hardware mining –
CPU, GPU, FPGA and ASIC
Hash Function
• A hash function can be considered equivalent of a fingerprint of a data
(which is of any format), similar to a fingerprint of a person.
• A hash function converts the data of arbitrary size to data of a fixed
size.
• Characteristics of the hash function:
 Collision-resistance – Two distinct data should not produce same
hash
 Hiding – Reverse engineering should not be possible. In other
words, if we’re given the output of the hash function y=H(x), it
should not be possible to figure out what the input, x, was.
 Fast computation – Computation of hash should be fast.
 Avalanche Effect – A small change in the input must produce a
huge change in the hash output. The change in output should not be
proportional to the change in input.
 Deterministic – For the same data, the hash produced must be same
at any time.
 Merkle Tree and Merkle Root
• A Merkle tree is a binary tree with hash pointers named after its
inventor Ralph Merkle.
– The blocks containing the data comprise the leaves of the tree.
– The blocks are grouped into pairs of two, and then for each pair,
a node is created in the next higher level that has two hash
pointers one for each of the blocks.
– These nodes are grouped into two and for each pair a node is
created in a level above them that contain two hash pointers one
for each of these nodes.
– This is continued and until a single block, the root of the tree is
constructed.
The Structure of a Blockchain
Nodes in the Bitcoin Blockchain
• Nodes in the network do the following:
a) Submit transaction to other nodes
b) Validate transaction from other nodes
c) Maintain the full block of the bitcoin network
d) Come up with a nonce for the block of
transaction
e) Publish your block to the network
f) Hope other miners accept your block
• Steps b, c and d are collectively called mining.
Nodes in the Bitcoin Blockchain
There are three types of nodes:
• Full node: These are the nodes that do all the activities (a to
f).
• Mining nodes: Mining nodes are the set of nodes with
mining capability, but they do not hold the entire
blockchain.
• Simplified Payment Verification node (SPV): SPV nodes
do not involve in mining; however, they are bound to
validate the block using block scripts; this feature can be
easily achieved even via handheld devices.
– SPV works by allowing clients to download only the block
headers and verify the transaction’s inclusion in a block using
Merkle proofs.
Block Propagation and Transaction Confirmation

• When a miner announces a block, the block needs to

propagate to all the nodes in the network.
• Let us look into a simple transaction: Panos decides to
sent one bitcoin to Murray as commission for some
material. Murray is notified about the transaction by
Panos. Should Murray send the material the moment he
is notified? Murray could be subjected to double
spending attack. Therefore, Murray should wait for the
transaction to be validated.
• Transaction Validation – Transaction validation means
the transaction must be listed in a block, and all other
nodes need to add the block in the blockchain.
Transaction Confirmation
• Zero confirmation transaction – A transaction that
has not yet been confirmed by the network's
miners. This means that it is not yet part of the
blockchain but the receiver accepts the transaction.
• One confirmation transaction – The receiver waits
until at least one node has confirmed the transaction is
valid.
• Six confirmation transaction – The receiver waits
until at least six nodes have confirmed the transaction
as valid. This assures high degree of certainty that the
transaction would be part of the block.
Orphaned Block
• An orphaned block is a valid block that is mined but
not included in the main blockchain.
• How it happens? When two miners find blocks at the
same time (not identical), they claim the same block
number.
• The blockchain splits and the two chains continue to
grow. Whoever, builds the next block first will take
over the chain. The network will eventually adopt the
longer chain as the valid one.
• The orphaned block and the shorter chain are discarded.
• The transactions from the orphaned block are returned
to the pool and may be included in future blocks.
Bitcoin Script
• A programming language called “Forth” is used for writing bitcoin
scripts. It is very easy to write and supports cryptographic operations.
• This language supports stack-based programming.
• The bitcoin scripting language has a limited set of instructions: there
are only 256 instructions, and each one is represented by one byte.
• Out of those 256 instructions, fifteen are currently not in use on the
bitcoin script and 75 others are reserved for a particular purpose, which
means that they have not yet been assigned any significance.
• The scripting language directly executes instructions.
• This language supports conditional statements; however, no looping is
allowed.
• The famous conditional statements: if statements and if else statements
are supported.
• Another necessary instruction is MULTISIG; this instruction is
accessible on platforms where validation by multiple nodes are
mandated.
Common Characteristics of Bitcoin Script

a. Simple to execute
b. Lightweight (does not rely on other software
packages).
c. Less computing energy.
d. Built for bitcoin
e. Uses cryptography (hashes, signature verification)
f. Stack-based
g. No loops. Conditional statements supported (If
statements)
h. Validation of multiple nodes supported (MULTISIG
instruction)
Bitcoin Script – Stack-based Architecture

• Bitcoin Script employs a stack-based architecture,

where data is organized and processed using a
Last-In-First-Out (LIFO) structure.
• The stack serves as a temporary storage
mechanism for operands and results of operations,
allowing the script to manipulate and operate on
these values efficiently.
• As transactions unfold, the stack dynamically
changes, reflecting the state of the script's
execution.
 Sample Bitcoin Script

• Step 1: The first two instructions of the script, namely, <Sig> and
<Pubkey> represent the signature and the corresponding public key
used to verify the signature.
• Step 2: OP_DUP duplicates the item on top of the stack.
• Step 3: OP_HASH160 pops the top value from the stack, computes
the hash and then pushes the result back. <PubKeyHash> also
pushes the hash of the public key to the top of the stack.
• Step 4: OP_EQULVERIFY matches the hash generated with the
given hash.
• Step 5: OP_CHECKSIG pushes the value true onto the top of the
stack when the signature (Sig) matches the “public key”.
Sample Bitcoin Script
Sample Bitcoin Script
Sample Flow-Control Related Instructions
WORD OP_CODE Meaning
OP_NOP 97 Does Nothing
OP_IF 99 If the value of the top of the stack is not false, the
statements are executed. The value of the top of the stack
is removed

OP_NOTIF 100 If the value of the top of the stack is false, the statements
are executed. The value of the top of the stack is removed

OP_ELSE 103 If the preceding OP_IF or OP_NOTIF or OP_ELSE was

not executed then these statements are executed and if the
preceding OP_IF or OP_NOTIF or OP_ELSE was
executed then these statements are not executed.

OP_ENDIF 104 Ends an if/else block. All blocks must end, or the
transaction is invalid. An OP_ENDIF without OP_IF
earlier is also invalid.
OP_VERIFY 105 Marks transaction as invalid if top stack value is not
true. The top stack value is removed.
Common Opcodes in Bitcoin Script

• OP_ADD: Pops two items off the stack, adds them together,
and pushes the result back onto the stack.
• OP_EQUAL: Pops two items from the stack and compares
them to check if they are equal. if they are equal, then it
pushes the result TRUE back onto the stack.
• OP_RETURN: Can be used to store up to 80 bytes of
arbitrary data on the Bitcoin blockchain and also to mark a
transaction output as invalid.
– OP_RETURN transaction outputs are provably unspendable,
making this opcode an efficient way to burn BTC.
– It also makes Komodo's delayed Proof of Work (dPoW) security
mechanism possible.
Common Opcodes in Bitcoin Script

• OP_CHECKSIG: Verifies that the signature

for a transaction input is valid.
• OP_CHECKMULTISIG: Commonly used
in Pay To Script Hash (P2SH) transactions.
– OP_CHECKMULTISIG looks at 3 public keys
and 2 signatures in the stack and compares them
one-by-one.
– Funds become spendable only when the order of
the signatures matches the order in which the
public keys were provided.
Transactions in the Bitcoin Network

• Bitcoin network is an open network; any node

within the network can submit a transaction to
the network.
• Like all transactions, a bitcoin transaction
needs to be recorded in a ledger.
• Let’s suppose individual transactions are added
to the ledger one at a time.
Account-Based Ledger

• In an account-based ledger, you can add some transactions that

create new coins and credit them to somebody. And then later
you can transfer them.
• A transaction would say something like 17 coins are moved
from Alice to Bob and signed by Alice.
Account-Based Ledger
• In Fig. 3.1, after Alice receives 25 coins in the first transaction,
and then transfers 17 coins to Bob in the second, she’d have 8
Bitcoins left in her account.
• The downside to this way of doing things is that anyone who
wants to determine if a transaction is valid will have to keep
track of these account balances.
• Does Alice have the 15 coins that she’s trying to transfer to
David? To figure this out, you’d have to look backwards in
time to see every transaction affecting Alice, and whether or
not her net balance at the time that she tries to transfer 15 coins
to David is greater than 15 coins.
Account-Based Ledger
• We can make this a little bit more efficient with some
data structures that track Alice’s balance after each
transaction. But that’s going to require a lot of extra
housekeeping besides the ledger itself.
• When a user initiates a transaction, they specify the
recipient’s address, the amount of cryptocurrency to
transfer, and any additional data required by the
transaction. The sender’s account balance is debited by
the specified amount, while the recipient’s account
balance is credited accordingly.
Account-Based Ledger
UTXO Model
• Bitcoin uses Unspent Transaction Output (UTXO) model
rather account-based model for ledger keeping.
• A UTXO is the amount of digital currency that remains after
a cryptocurrency transaction. You can think of it as the
change you receive after buying an item.
• When you initiate a transaction through your wallet,
UTXOs with your information are located and unlocked.
The new owner's information is associated with the UTXO
you transferred to them. They are locked once again, and
the user can use them in transactions via the same process.
• As transactions continue, the DB becomes populated with
records of ownership changes.
UTXO Model
 UTXO Model
• Transactions specify a number of inputs and a number of outputs.
• Inputs are the coins being consumed and the outputs are coins
being created.
• For transactions in which new currency is being minted, there are
no coins being consumed.
• Each transaction has a unique identifier. Outputs are indexed
beginning with 0.
• Transaction 1 has no inputs because this transaction is creation of
new coins, and it has an output of 25 coins going to Alice.
• In Transaction 2, Alice sends 17 coins to Bob. The input is the
previous transaction where these coins are coming from i.e. 1[0].
Two outputs are specified in the transaction 17 coins to Bob and
8 coins to Alice.
 UTXO Model
Change address:
• Alice only wants to pay 17 bitcoins to Bob, but
the output that she owns is worth 25 bitcoins.
• So she needs to create a new output where 8
bitcoins are sent back to herself.
• It could be a different address from the one
that owned the 25 bitcoins, but it would have
to be owned by her. This is called a change
address.
 UTXO Model
Efficient verification:
• When a new transaction is added to the ledger, it
should be ensured that the transaction is valid.
• In Transaction 4, Alice sends 6 coins to David.
• To verify whether Alice has sufficient funds, we
need to scan the blockchain between the
referenced transaction and the latest block.
• We don’t need to go all the way back to the
beginning of the blockchain.
 UTXO Model
• Consolidating funds: Since transactions can have many inputs and many
outputs, splitting and merging value is easy.
– For example, say Bob received money in two different transactions –
17 coins in one and 2 coins in another and later Bob, would like to
spend all 19 coins.
– Bob can create a transaction with two inputs and one output.
• Joint payments: Similarly, joint payments are also easy to do.
– Say Carol and Bob both want to pay David. They can create a
transaction with two inputs and one output, but with the two inputs
owned by two different people.
– The difference from the previous example is that since the two outputs
from prior transactions that are being claimed here are from different
addresses, the transaction will need two separate signatures – one by
Carol and one by Bob.
UTXO Model
 UTXO Model
• There are three parts to a transaction – metadata, input, and
output
• Metadata: There’s some housekeeping information — the size
of the transaction, the number of inputs, and the number of
outputs. There’s the hash of the entire transaction which serves as
a unique ID for the transaction. Finally, there’s a “lock-time”.
• Inputs: The transaction inputs form an array. An input specifies a
previous transaction, so it contains a hash of that transaction,
which acts as a hash pointer to it. The input also contains the
index of the previous transaction’s outputs that’s being claimed.
And then there’s a signature. Remember that we have to sign to
show that we actually have the ability to claim those previous
transaction outputs.
 UTXO Model
• Outputs. The outputs are again an array. The
sum of all output values has to be less than or
equal to the sum of all the input values.
– If the sum of the output values is less than the sum
of the input values, the difference is a transaction
fee to the miner who publishes this transaction.
APPLICATIONS OF BITCOIN SCRIPTS
Escrow Transactions
• Alice and Bob want to do business – Alice wants to pay Bob in
Bitcoin for Bob to send some physical goods to Alice.
• Alice doesn’t want to pay until after she’s received the goods, but
Bob doesn’t want to send the goods until after he has been paid.
• A solution in Bitcoin is an escrow transaction.
• Alice doesn’t send the money directly to Bob, but instead creates a
MULTISIG transaction that requires two of three people to sign in
order to redeem the coins.
• The three people are Alice, Bob and some third party arbitrator.
• This transaction is included in the blockchain, and at this point,
these coins are held in escrow between Alice, Bob and Judy, such
that any two of them can specify where the coins should go.
• At this point, Bob is convinced that it’s safe to send the goods over
to Alice, so he’ll mail or deliver the goods physically.
Escrow Transactions
• In the normal case, Alice and Bob are both honest. Bob will send goods that
Alice is expecting. When Alice receives the goods, Alice and Bob both sign a
transaction redeeming the funds from escrow, and sending them to Bob. Alice’s
and Bob’s signatures met the 2-of-3 requirement of MULTISIG transaction.
• If Bob didn’t actually send the goods, or they got lost in the mail, or perhaps
the goods were different that what Alice ordered?
– Alice doesn’t want to pay Bob and wants to get her money back. So, Alice
will not sign the transaction that releases the money to Bob.
– At the same time, Bob may deny any wrongdoing and refuse to sign a
transaction that releases money back to Alice.
– This is when, the third party gets involved and decides which of these two
people deserves the money.
• If the third party decides that Bob had cheated, it will sign a transaction
along with Alice, sending money from escrow back to Alice meeting 2-
of-3 requirement of MULTISIG transaction.
• If the third party thinks Alice is at fault, it will sign a transaction along
with Bob sending the money to Bob meeting 2-of-3 requirement of
MULTISIG transaction
Micro-Payments
• Alice is a customer who wants to continually pay Bob
small amounts of money for some service that Bob
provides.
• Creating a Bitcoin transaction for every small payment
of money creates too many transactions, and the
transaction fees add up.
• A solution is to combine all these small payments into
one big payment at the end.
• We start with a MULTISIG transaction that pays the
maximum amount Alice would ever need to spend to an
output requiring both Alice and Bob to sign to release
the coins.
 Micro-Payments
• First time Alice needs to make a micropayment, she signs a
transaction spending those coins that were sent to the
MULTISIG address, sending one unit of payment to Bob
and returning the rest to Alice.
• In the next micropayment, Alice signs another transaction,
paying two units to Bob and sending the rest to herself.
• These transactions are only signed by Alice, and haven’t
been signed by Bob yet, nor are they published.
• Alice will keep signing the transactions for every
micropayment. Eventually, Alice will have finished using
the service, and tells Bob to cut off the service. At this
point, Alice stops signing additional transactions.
 Micro-Payments
• Since each transaction was paying Bob a little bit more,
and Alice a little bit less, the final transaction that Bob
redeems pays him in full for the service that he
provided and returns the rest of the money to Alice.
• All the transactions other than the last won’t make it to
the block chain and are discarded.
• If Bob never signs any transaction and lets the coin sit
there in escrow forever, Alice will lose the full value
that she paid at the beginning.
• There’s a clever way to avoid this problem using
lock_time parameter in the metadata in Bitcoin
transactions.
 Micro-Payments
• Before, the micropayment protocol can even start, Alice and Bob
will both sign a transaction which refunds all of Alice’s money back
to her, but the refund is “locked” until some time in the future.
• So after Alice signs, but before she broadcasts, the first MULTISIG
transaction that puts her funds into escrow, she’ll want to get this
refund transaction from Bob and hold on to it.
• That guarantees that if she makes it to time t and Bob hasn’t signed
any of the small transactions that Alice has sent, Alice can publish
this transaction which refunds all of the money directly to her.
• Formally, the lock_time parameter tells miners not to publish the
transaction until the specified lock time.
• It works quite nicely in the micropayment protocol as a safety valve
for Alice to know that if Bob never signs, eventually she’ll be able
to get her money back.
Smart Contracts
• The general term for escrow or micropayment protocol
is smart contracts.
• These contracts are enforced technically in Bitcoin
unlike traditional enforcement through laws or courts.
• We can use scripts, miners and transaction validation to
realize escrow protocol or the micropayment protocol
without needing a central authority.
• Research into smart contracts goes far beyond escrow
or micropayment protocols.
• There are many types of smart contracts which people
would like to enforce but aren’t supported by the
Bitcoin scripting language today.
Important Limitations of Bitcoin Scripts
• Lack of Turing-completeness – While there is a
large subset of computation that the Bitcoin
scripting language supports, it does not support
everything.
• Loops are absent in the Bitcoin scripts. This is
done to avoid infinite loops during transaction
verification.
• Implementing elliptic curve signature algorithm
that requires 256 repeated multiplication rounds
is difficult to implement in Bitcoin script because
of the absence of loops.
Important Limitations of Bitcoin Scripts
• Value – blindness: There is no way for a UTXO script to provide fine-grained
control over the amount that can be withdrawn.
• For example, A and B put $1000 worth of BTC as a hedging contract and after
30 days the script sends $1000 worth of BTC to A and the rest to B. This
requires determining the value of 1 BTC in USD.
– Furthermore, UTXO are all-or-nothing: Lets say you have 10 BTC
which you received from 3 separate transactions; 2, 3 and 5 respectively.
• Now you want to send 1 BTC to someone. To create a transaction, you
have 3 transaction records that you can reference as input with 2, 3 and
5 BTC.
• The problem is that in bitcoin scripting you can not say take 1 BTC
from any of my transactions and send it as it is value-blind. You will
have to say, for instance, take 2 BTC from first transaction. Then 1
BTC will be sent to your friend and 1 BTC will be sent back to
yourself. This produces additional complexity in the bitcoin
blockchain.
Important Limitations of Bitcoin Scripts

• Lack of State: UTXO can either be spent or

unspent; there is no opportunity for multi-stage
contracts.
– For example, withdrawal limits is impossible.
• Blockchain – blindness: - UTXO are blind to
blockchain data such as the nonce and previous
hash.
– This severely limits applications in gambling, and
several other categories, by depriving the scripting
language of a potentially valuable source of
randomness.
Three Approaches to Building Advanced
Applications on Top of Cryptocurrency
• Building a new blockchain: Building a new
blockchain allows for unlimited freedom in building a
feature set, but at the cost of development time and
bootstrapping effort.
• Using scripting on top of Bitcoin: Using scripting is
easy to implement and standardize, but is very limited
in its capabilities.
• Building a meta-protocol on top of Bitcoin: Meta-
protocols, while easy, suffer from faults in scalability.
• Ethereum, is a generalized framework that provides the
advantages of all three paradigms at the same time.