Module - 3

Mechanics of Bitcoin

Bitcoin transactions, Bitcoin Scripts, Applications of Bitcoin scripts,

Bitcoin blocks, The Bit- coin network, Limitations and improvements.
• So far …
– Bitcoin consensus mechanism
• gives us an append-only ledger, a data structure that we can
only write to.
• Once data is written to it, it’s there forever.
– Decentralized protocol
• for establishing consensus about the value of that ledger,
and there are miners who perform that protocol and
validate transactions.
• Together they make sure that transactions are
– well formed,
– that they aren’t already spent, and
– that the ledger and network can function as a currency.

• At the same time, Remember that a currency

existed to motivate these miners.
 Bitcoin Transactions

– Transactions are the fundamental building block of

bitcoin.
– Can be maintained in
• Account-based ledger
• Transaction based ledger
• Account-based ledger
(Not used in Bitcoin)
– This is the mental model
of many people that’s
how Bitcoin works
– Create, credit and transfer
information about the
transactions will be there
in the ledger
An account-based ledger (not Bitcoin)
time

Create 25 coins and credit to AliceASSERTED BY MINERS

might need to
scan backwards
Transfer 17 coins from Alice to BobSIGNED(Alice) 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
• Transaction-based ledger
(used by Bitcoin)
– Specify a number of
inputs and a number of
outputs
– inputs as coins being
consumed (created in a
previous transaction) and
the outputs as coins being
created (newly created in
this transaction)
– Each transaction has a
unique identifier. Outputs
are indexed beginning
with 0, so we will refer to
the first output as “output
0”
 A transaction-based ledger (Bitcoin)
1
time Inputs: Ø
Outputs: 25.0→Alice we implement this
with hash pointers
change
2 address
Inputs: 1[0]
Outputs: 17.0→Bob, 8.0→Alice
SIGNED(Alice)

3 finite scan to check for

Inputs: 2[0] validity
Outputs: 8.0→Carol, 7.0→Bob (Efficient Verification)
SIGNED(Bob)

4
Inputs: 2[1] is this valid?
Outputs: 6.0→David, 2.0→Alice
SIGNED(Alice)

SIMPLIFICATION: only one transaction

per block
• Salient features about transaction-based ledger
– Change addresses
• Why does Alice have to send money to herself in this example?
– Since the bitcoins are immutable, the entirety of a transaction output must
be consumed by another transaction, or none of it
– Hence, she needs to create a new output where 8 bitcoins are sent back to
herself
– Efficient Verification
• How easy to check, a new transaction is a valid transaction?
– No need to go all the way back to the beginning of the blockchain rather scan
the blockchain between the referenced transaction and the latest block
– Consolidating funds (Merging values)
• Since transactions can have many inputs and many outputs, splitting
and merging value is easy
– Joint Payments
• Create a transaction with two inputs owned by two different people
and one output
– BUT the transaction will need two separate signatures
 Merging value
tim
e 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
tim
e 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
 Transaction syntax

The real deal: a Bitcoin transaction

 The real deal: transaction
metadata
{
"hash":"5a42590...b8b6b",
transaction
hash
"ver":1,
"vin_sz":2,
housekeeping "vout_sz":1,
"lock_time":0,
"size":404,
more on this
... later...
}
 The real deal: transaction inputs
"in":[
previous {
transactio "prev_out":{
n "hash":"3be4...80260",
"n":0
},
signature "scriptSig":"30440....3f3a4ce81"
},
(more ...
inputs) ],
 The real deal: transaction outputs
"out":[
{
"value":"10.12287097",
output
value "scriptPubKey":"OP_DUP OP_HASH160 69e...3d42e OP_EQUALV
OP_CHECKSIG"
recipient
},
address??
...
(more
outputs) ]
Actual Bitcoin Transaction
Transaction ID

Input = 2
output = 1

Transaction ID of that block

Output #ID

Signature of that block

Value

Output Script
● Metadata
○ Information about that block
■ Size of the transaction
■ Number of inputs,
■ Number of outputs
■ Hash of the entire transaction which serves as a unique ID for the
transaction which is used to reference transactions.
■ lock_time
● Inputs
○ The transaction inputs form an array, and each input has the same form.
○ 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.
○ Signature which is used to sign to show that we actually have the ability to
claim those previous transaction outputs.
● Outputs
○ The outputs are again an array. Each output has just two fields. They each
have a value, and the sum of all the 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
• Remember the following:
– Every coin that is going to be spending is known as Input or consumed
coin.
– Every input or consumed coin is created as output in earlier transactions
– Hence, it is possible to establish a relationship between the input or
consumed coin of a current transaction and output coin produced in the
earlier transactions.
– Why we need to relate it?
• To verify the ownership of the coin
– How will you verify the ownership of coins in a transaction?
• Get the public key hash (address) from the recipient of coin as a output in earlier
transaction and get the signature and public key in the current transaction. Then
check
– Hash(pub key)==public key hash
– Verify(Signature, transaction, Pubkey)
– Do we need to check the whole transactions back to genesis block to
verify the coin is not spend before(Double spend)?
• NO! Check the transactions between referenced output transaction and current
transaction to ensure that coin is not spend before the current transaction.
You can think of the blockchain as being a storage facility
for safe deposit boxes, which we call outputs. These
outputs are just containers that hold various amounts of
bitcoin.
When you make a bitcoin transaction, you select some
outputs and unlock them, then create new outputs and
put new locks on them.

So when you “send” someone bitcoins, you are actually

placing an amount of bitcoins in to a new safe deposit
box, and putting a lock on it that only the person you are
“sending” the bitcoins to can unlock.
For example, if I wanted to send you some bitcoins, I
would select some outputs from the blockchain that I can
unlock, and create a new output from them that
only you can unlock. Also, if I didn’t want to send you all
of the bitcoins that I had unlocked, I would create an
extra output as my “change” and lock it to myself.
if you want to send your bitcoins to someone else, you
would repeat the process of selecting existing outputs
(that you can unlock) and creating new outputs from
them. As a result, bitcoin transactions form a graph-like
structure, where the movement of bitcoins is connected
by a series of transactions.
Lastly, when a transaction gets mined on to the
blockchain, the outputs that were used up (spent) in the
transaction cannot be used in another transaction, and
the newly created outputs will be available to be moved
on in a future transaction.
Bitcoin scripts
Output “addresses” are really
scripts

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

scriptSi
30440220...
g 0467d2c9...

OP_DUP
scriptPubKe OP_HASH160
y 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

image via Jessie St. Amand

 Bitcoin scripts
• Script is simple, stack-based instructions, and processed from
left to right without any loops
• Special-purpose instructions to compute hash functions and
to compute and verify signatures
• Every instruction is linearly executed exactly once with an
upper bound on time and memory
• The main properties of this language are:
– stack-based
– non Turing complete
– Two types of instructions: data instructions and OP_CODE
 Bitcoin scripts properties…
• Stack
– Specifically designed for bitcoin but similar to Forth
– There are no variables
– All the operations are always executed exactly once in linear manner.
• Non Turing complete:
– It is not possible to compute arbitrarily powerful functions.
– There are no loops.
– By just looking at a script, it is possible to understand how long it might take
based on the number of instructions.
– Because the miners have to run the scripts submitted by users directly in the
transactions. So they must not have the ability to submit scripts that might
have an infinite loop and might run forever.
– The Bitcoin script will always run in a finite numbers of steps corresponding to
the number of instructions that it contains.
 Bitcoin scripts properties…
• Instructions: data instructions and OP_CODE.
– Data instruction are simply containing some value and are
surrounded by angular brackets (i.e. <data>).
– OP_CODE are specific operations belonging to Bitcoin
Scripting language that acts on the value on the top of the
stack and put their result also on the top of the stack.
 Script Properties
• Main properties of Bitcoin language and scripts are the
following:
– Every Bitcoin script can only produce two outcomes. It can either
execute successfully or return an error. In the Transaction validation, if
there's any error while the script is executing, the whole transaction
will be invalid and shouldn't be accepted into the blockchain
– Bitcoin scripting language is very small, 256 instructions. 15 of them
are currently disabled and 75 are reserved.
– Bitcoin scripting language includes instructions to manage basic
arithmetic, basic logic, throwing errors and cryptography management
such as hash functions, signature verification.
• If the execution of script returns true then the Tx is valid and
added to blockchain else not.
• some of the most common instructions in the
Bitcoin scripting language.
Executing a script
• Executing a script
– Needs a stack data structure for storing the data. The
data instructions gives the data and pushed on top of
the stack whereas the opcodes performs some
functions
Bitcoin scripts in practice (as of
2014)
● Most nodes whitelist known scripts
● 99.9% are simple signature checks
● ~0.01% are Pay-to-Script-Hash
● Remainder are errors, proof-of-burn
 Proof-of-burn
• Proof of burn follows the principle of “burning” or “destroying” the coins
held by the miners that grant them mining rights.
• Proof-of-burn is actually a script that can never be redeemed.
• If you have a proof-of-burn, it's provable that those coins have been
destroyed, there's no possible way for them to be spent.
• To implement a proof-of-burn it's necessary to insert an OP_RETURN
instruction, which throws as soon as it is reached, no matter what
instructions preceded it.
• The data that comes after OP_RETURN are ignored, so this is an
opportunity to specify arbitrary data in a script that will remain in the
blockchain.
 Proof-of-burn…
• One use of proof-of-burn is to bootstrap an alternative to
Bitcoin by forcing people to destroy Bitcoin in order to gain
coins in the new system.
• This kind of script has mainly two purposes:
– Insert arbitrary data into blockchain, for example timestamp a
document and prove that you knew some data at a specific time.
– In this case it is possible to create a very low value Bitcoin transaction
that's proof-of-burn. So you can destroy a very small amount of
currency, and in exchange write something into the blockchain, which
should be kept forever.
– Some alternate coins systems, can promote their new currencies
forcing people to destroy Bitcoin in order to gain coins in the new
system.
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!
Pay to script hash
I’m ready to pay for my Big Box
purchases!

Great! Here’s our address:

0x3454
 Pay-to-script-hash
• To use Bitcoin a sender must specify a script exactly.
• A common consumer, wouldn't be able to specify it, if for example he is
ordering something online and a MULTISIG script is required. As a
consumer, he just want to send the money using a simple address.
• In response to that problem, there's a feature in Bitcoin that lets the
sender specify just a hash of the script that is needed to redeem the coins.
• The script acts as follows:
– The sender specifies the hash of the script and it is put on the top of the stack
– The receiver specifies as a data value, the value of the script corresponding to
the previous hash
– The algorithm checks if the hash of this data corresponds to the one specified
by the sender
– If the two hashes match, the top data value from the stack is reinterpreted as
instructions, so it's executed a second time as a script.
• This pay-to-script-hash is an alternative to make Bitcoin payments to the
standard way, which is called pay-to-public-key.
 Pay to script hash (P2SH)
• Pay to script hash (P2SH) allow transactions to be sent to a script hash (address
starting with 3) instead of a public key hash (addresses starting with 1).
• To spend bitcoins sent via P2SH, the recipient must provide a script matching the
script hash and data which makes the script evaluate to true.
• Using P2SH, you can send bitcoins to an address that is secured in various unusual
ways without knowing anything about the details of how the security is set up.
• The recipient might need the signatures of several people to spend these bitcoins,
or a password might be required, or the requirements could be completely unique.
• Pay to script hash (P2SH) is an advanced type of transaction used in Bitcoin and
other similar cryptocurrencies.
Applications of Bitcoin Scripts
 Escrow transactions
• See the following situation:
– Alice wants to buy some things from Bob
– she wants to pay with Bitcoins and Bob has to send
physical goods to Alice
– Alice doesn't want to pay until she receives it. And Bob
doesn't want to send it, until he has received the payment
 Escrow transactions
• There's a nice solution to this problem in Bitcoin system:
– Alice creates a MULTISIG transaction that requires two or three people to sign in order
to redeem the coins. These people are Alice, Bob and Judy. Judy is a judge, who will
come into play only if there's any dispute
– Alice signs the transaction redeeming some coins that she owns. At this point these
coins are held in escrow between Alice, Bob, and Judy. And any two of them can specify
where the coin should go.
– At this point Bob can safely send the goods to Alice and sign the transaction that
releases money to him.
– If the goods arrive and corresponds to what Alice expected, she can release the money
towards Bob signing the transaction. The money will be sent to Bob without the need of
Judy's intervention.
– This happens if both are honest. Otherwise Alice could ask for her money back. And
maybe Bob doesn't agree to sign the transactions that releases the money towards Alice.
• Now it's Judy's turn to decide who's right and sign the transaction that
releases money either towards Alice or Bob.
• In both cases, since only two signatures are required, the money will be
sent towards one of them.
Escrow transactions
• Escrow Transactions
– An escrow is a financial arrangement where a third party holds and regulates payment
of the funds required for two parties involved in a given transaction.
– It helps make transactions more secure by keeping the payment in a secure escrow
account which is only released when all of the terms of an agreement are met as
overseen by the escrow company
• How does Escrow Work?
1. Escrow.com reduces the risk of fraud by acting as a trusted third-party that collects,
holds and only disburses funds when both Buyers and Sellers are satisfied.
2. Buyer and Seller agree to terms - Either the Buyer or Seller begins a transaction. After
registering at Escrow.com, all parties agree to the terms of the transaction.
3. Buyer pays Escrow.com - The Buyer submits a payment by approved payment
method to our secure Escrow Account, Escrow.com verifies the payment, the Seller is
notified that funds have been secured 'In Escrow'.
4. Seller ships merchandise to Buyer - Upon payment verification, the Seller is
authorised to send the merchandise and submit tracking information. Escrow.com
verifies that the Buyer receives the merchandise.
5. Buyer accepts merchandise - The Buyer has a set number of days to inspect the
merchandise and the option to accept or reject it. The Buyer accepts the merchandise
6. Escrow.com pays the Seller - Escrow.com releases funds to the Seller from the Escrow
Account.
 Green addresses
• Imagine that Alice wants to pay Bob, who's offline.
• Bob can't check the blockchain to see if the transaction that Alice is
sending is valid. This can happen for any reason.
• For example if Bob doesn't have time to connect and check or doesn't
have a connection.
• Normally a transaction is valid when its block is followed by other six
blocks. This can take up to an hour.
• To solve the problem of the recipient not being able to access the
blockchain, it is necessary to introduce a third party: the bank.
• Alice can ask her bank to transfer money to Bob. They will deduct some
money from Alice account and make a transaction to Bob from one of
their green addresses.
 Green addresses
• The money to Bob will come directly from a bank controlled address, with
a guarantee of no double spending.
• If Bob trusts the bank, he can accept the transaction as soon as he
receives it.
• The money will eventually be his when it's confirmed in the blockchain.
• This feature isn't based on Bitcoin system, but is a real world guarantee,
so the bank must be trustable.
• If the bank ever does double spending, its system is going to collapse
quickly.
• Already happened to 2 famous services that implemented green address:
– Instawallet
– Mt. Gox
• For this reasons, green addresses aren't used as much in Bitcoin as when
they were first proposed.
• It is necessary to put too much trust in the bank.
Green addresses
 Efficient micro-payments
• Suppose that Alice is a customer who wants to pay Bob a low
amount of money for some service.
• So maybe Bob is Alice's wireless service provider, and Alice
wants to pay a small amount of money for every minute she
uses it.
• It would be very inefficient to create a Bitcoin transaction for
every minute of conversation, there will be too many
transactions with low value and too many fees.
• A nice solution would be to combine all these small payments
into one big payment at the end.
 Efficient micro-payments
• Start with a MULTISIG transaction that pays the maximum amount Alice would
ever need to spend, that requires both Alice and Bob signatures to release the
coins
• After the first minute of conversation, Alice signs the transaction sending one coin
to Bob and returning the rest to herself.
• After another minute, Alice signs another transaction, paying two coins to Bob and
the rest to herself. At this point Bob hasn't signed anything, yet.
• Alice repeats this procedure every minutes of usage. These transactions aren't
published on the blockchain, since Bob signature is missing.
• When Bob wants to get his money, he can sign the last transaction and publish it
on the blockchain. He will receive the money he deserves, and the remaining will
be sent back to Alice. The other transactions will never be inserted into the
blockchain.
• It is impossible to redeem two different transactions generated by Alice, since they
are all technically double spends of the same beginning transaction. If both parties
are operating normally, Bob will never sign any transaction but the last one, so the
blockchain won't actually see any attempt of double-spending.
Efficient micro-payments
 Lock time
• A problem of the micro-payments protocol could be that Bob will never signs any
of the transactions, so all the money that Alice first sent to the multisign address
remains blocked.
• How can Alice have her money back?
• She can use another feature called Lock Time.
• Before the micro-payment protocol starts, Alice and Bob will both sign a
transaction which refunds all of Alice's money back to her, but is locked until some
time in the future.
• So before Alice signs the first transaction for the first minute of service, she
requires this refund transaction from Bob.
• If a certain time T is reached and Bob hasn't signed any of the small transactions
that Alice sent, she can publish this transaction which refunds all of the money
directly to her.
• To do this, we will use the LOCK_TIME parameter in the metadata of Bitcoin
transactions.
• It is possible to specify a value different from 0 for the lock time, which tells the
miners not to publish the transaction until some point in time, based on the
timestamps that are put into blocks.
• With this feature Alice knows that she can get her money back if Bob never signs
the transactions.
Lock time
 Smart Contracts
• Smart contracts
– General term for contracts is smart contracts.
– These contracts have some degree of technical
enforcement in Bitcoin, whereas traditionally they
are enforced through laws or courts of arbitration.
– A cool feature of Bitcoin
• Can be used in scripts, miners, and Transaction
validation to realize the escrow protocol or the micro-
payment protocol without needing a centralized
authority.
 Bitcoin Blocks
• Why transactions are grouped together into blocks?
– If miners had to come to consensus on each transaction
individually, the rate at which new transactions could be
accepted by the system would be much lower
– a hash chain of blocks is much shorter than a hash chain of
transactions would be, since a large number of transactions
can be put into each block
• much more efficient to verify the block chain data structure
• The block chain is a clever combination of two
different hash-based data structures
– A hash chain –
– Second data structure is a per-block tree of all of the
transactions that are included in that block
• Structure of a Block

• A block consists of header data followed by a list of transactions arranged

in a tree structure
• The header mostly contains information related to the mining
puzzle.
• The header also contains a “nonce” that miners can change, a time
stamp, and “bits”, which is an indication of how difficult this block
was to find.
• The only transaction data that’s included in the header is the root of
the transaction tree — the “mrkl_root” field.
• The header is the only thing that’s hashed during mining. So to
verify a chain of blocks, all we need to do is look at the headers.
 Coinbase Transaction
– Coinbase transaction
• creates new coins
• Difference between coinbase and other bitcoin transactions
1. it always has a single input and a single output,
2. the input doesn’t redeem a previous output and thus contains a null
hash pointer, since it is minting new bitcoins and not spending existing
coins,
3. the value of the output is currently a little over 25 Bitcoins. The output
value is the miner’s revenue from the block. It consists of two
components: a flat mining reward, which is set by the system and which
halves every 210,000 blocks (about 4 years), and the transaction fees
collected from every transaction included in the block.
4. There is a special “coinbase” parameter, which is completely arbitrary
— miners can put whatever they want in there
Coinbase Transaction
 The real "in":[
deal: coinbase transaction
{ Null hash
"prev_out":{ pointer
"hash":"000000.....0000000",
redeeming "n":4294967295
}, First ever coinbase parameter:
nothing “The Times 03/Jan/2009
"coinbase":"..." Chancellor on brink of second
}, block reward bailout for banks”
arbitrary "out":[
{ transaction fees
"value":"25.03371419",
"scriptPubKey":"OPDUP OPHASH160 ... ”
}
See for yourself!

https://www.blockchain.com/explorer
 Bitcoin Network
• Is a peer-to-peer network and inherits many ideas from peer-to-
peer networks
• All nodes are equal; No hierarchy, No special nodes or no master
node
• Runs over TCP, each node peers with each other random node
• Nodes can join and leave at any time – Dynamic n/w
• Download bitcoin client, spin up your pc as node and will have
equal rights and capabilities as every other node on the Bitcoin
network
• No explicit way to leave the network
– If a node hasn’t been heard for 3 hours then other nodes started to forget
it.
 Join the network
• Start with a simple message to one node that you
know about i.e. seed node
• Alternative way: send a special message, saying, “Tell
me the addresses of all the other nodes in the
network that you know about” to several new nodes
and learn about as many times as you want then
decide the seed node
• Broadcasting a network
– Transaction is published to the entire network using
flooding or gossiping mechanism
Joining the Bitcoin P2P network
Hello World! 5
1 I’m ready to
Bitcoin!
7

3
6
2

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

7
A→B
8
A→B A→B

A→B New
3
6 tx!
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
 Broadcasting in Bitcoin network
• If Alice wants to pay Bob some money, her client creates and her node
sends this transaction to all the nodes it’s peered with.
• Each of those nodes executes a series of checks to determine whether or
not to accept and relay the transaction. If the checks pass, the node in
turn sends it to all of its peer nodes.
– Nodes that hear about a transaction put it in a pool of transactions
which they’ve heard about but that aren’t on the block chain yet.
– If a node hears about a transaction that’s already in its pool, it doesn’t
further broadcast it.
• This ensures that the flooding protocol terminates and
transactions don’t loop around the network forever.
• Remember that every transaction is identified uniquely by its hash,
so it’s easy to look up a transaction in the pool.
 Bitcoin Network
• How do the nodes decide whether or not they should propagate the new
transactions?
– First Check: transaction validation — the transaction must be valid
with the current block chain.
• Nodes run the script for each previous output being redeemed and ensure that the
scripts return true.
– Second Check: Ensure that the outputs being redeemed here haven’t
already been spent
– Third Check: Don’t relay an already-seen transaction
– Fourth Check: nodes will only accept and relay “standard” scripts
based on a small whitelist of scripts
• The above-mentioned checks are sanity checks
• No rule that says that nodes have to follow these specific steps
• Due to network latency, nodes will end up with a different view of the
pending transaction pool
Race Condition due to latency in the network

• Nodes will temporarily disagree on which transactions should be

put into the next block
– Alice attempts to pay the same bitcoin to both Bob and Charlie, and sends
out two transactions at roughly the same time.
– Some nodes will hear about the Alice → Bob transaction first while others
will hear about the Alice → Charlie transaction first.
– When a node hears either of these transactions, it will add it to its
transaction pool, and if it hears about the other one later it will look like a
double-spend. The node will drop the latter transaction and won’t relay it or
add it to its transaction pool
– DEFAULT BEHAVIOR is for nodes to hang onto whatever they hear first
– Whoever mines the next block will essentially break the tie and decide
which of those two pending transactions should end up being put
permanently into a block
 Race Condition
• If two conflicting transactions or blocks get announced at two different
positions in the network, they’ll both begin to flood throughout the
network and which transaction a node sees first will depend on where it is
in the network
• Nodes are free to implement any other logic they want for choosing which
transactions to keep and whether or not to forward a transaction
• In the case of conflicting transactions is to include the transaction they
received first which makes double-spending against zero-confirmation
transactions moderately hard.
 Race Condition
• Announcing new blocks, whenever miners find a new
block, is almost exactly the same as propagating a
new transaction and it is all subject to the same race
conditions.
– If two valid blocks are mined at the same time, only one of
these can be included in the long term consensus chain
whereas the other is orphaned
 Race Condition
• Validating a block is more complex than
validating transactions – Why?
– Need to validate the block header
– Need to ensure block hash is within the level
– Need to validate the transactions
– Node will forward a block only if it builds on the
longest branch
• This avoids forking
• like with transactions, nodes can implement different logic
if they want
 Bitcoin Network
• Block propagation time
– Average time for new blocks to propagate to every node in the
network
– Average time consumed by a block to reach various percentages of the
nodes in the network
– Propagation time is basically proportional to the size of the block since
network is the bottleneck
• larger blocks take over 30 seconds to propagate to most nodes in
the network – TOO HUGE
• Size of the network
– Seem to be only about 5,000 to 10,000 nodes that are permanently
connected and fully validate every transaction they hear.
• Difficult to measure how big the network is since it is dynamic
 Storage Requirements
• Fully validating nodes must stay permanently
connected so as to hear about all the data.
• The longer a node is offline, the more catching up it
will have to do when it rejoins the network.
• Such nodes also have to store the entire block chain
and need a good network connection to be able to
hear every new transaction and forward it to peers.
• The storage requirement is currently in the low tens
of gigabytes
 Fully Validating Nodes
• Fully validating nodes must store the entire block chain, which as of the
end of 2014 is over 26 gigabytes
• Must maintain the entire set of unspent transaction outputs
• Ideally this should be stored in RAM, so that upon hearing a new proposed
transaction on the network,
– the node can quickly look up the transaction outputs that it’s
attempting to claim,
– run the scripts,
– see if the signatures are valid, and
– add the transaction to the transaction pool.
• As of mid-2014, there are over 44 million transactions on the block chain
of which 12 million are unspent.
• Fortunately, that’s still small enough to fit in less than a gigabyte of RAM in
an efficient data structure.
 Lightweight nodes
• Lightweight nodes or Thin clients or Single Payment Verification(SPV) clients
– vast majority of nodes on the Bitcoin network are lightweight nodes
– don’t store the entire block chain
– only store the pieces that they need to verify specific transactions that they
care about
• downloads the block headers and transactions that represent payments to
your addresses
• Other transactions can be validated by Fully Validating Nodes
– Typically used in wallet program
– doesn’t have the security level of a fully validating node
– node has block headers, it can check that the blocks were difficult to mine,
• but it can’t check to see that every transaction included in a block is
actually valid because it doesn’t have the transaction history and doesn’t
know the set of unspent transactions outputs
– Huge Cost Savings – 1/1000 the size of the blockchain leads to few megabytes
and a smartphone can be easily converted to SPV
 Limitations
• limits on the average time per block, the size of blocks, the number of
signature operations in a block, and the divisibility of the currency, the
total number of Bitcoins, and the block reward structure
• limitations on the total number of Bitcoins in existence, as well as the
structure of the mining rewards are very likely to never be changed
• How many transactions can the Bitcoin network process per second?
– Each block is limited to a megabyte, about a million bytes.
– Each transaction is at least 250 bytes.
– Dividing 1,000,000 by 250, each block has a limit of 4,000
transactions, and given that blocks are found about every 10 minutes,
we’re left with about 7 transactions per second, which is all that the
Bitcoin network can handle.
• choices of cryptographic algorithms in Bitcoin are
fixed
– Couple of hashing algorithm and one signature
algorithm(ECDSA with secp256k1)
• Use Bitcoin scripts to support new cryptographic algorithms
• Changing the bitcoin protocol
– just release a new version of the software, and tell all
nodes to upgrade
• network would fail; new software or fail to get it in time
• nature of the changes in the software: hard fork and soft fork
 FORK
• In blockchain, a fork is defined variously as:
– "a change in protocol" or
– a situation that "occurs when two or more blocks have the
same block height"
• Related to different parties use common rules to maintain the
history of the blockchain. When parties are not in agreement,
alternative may emerge.
• Most forks are short-lived, some are permanent.
 Hard forks
• Change introduced in the new software: New version of the software
would recognize blocks as valid that the old software would reject
• What happens ?
– when most nodes have not upgraded
• They’ll consider their (shorter) branch to be the longest valid
branch
– when most nodes have upgraded
• New nodes will consider some blocks as valid blocks which are
considered as invalid by old nodes. Hence, the longest blockchain
contains these blocks also as part of their chain
• it makes the block chain split. Every node in the network will be on
one or the other side of it based on which version of the protocol
it’s running
• Example:
– changing the limits on block or transactions size, or
– various bug fixes CHECKMULTISIG
 Soft forks
• Changes introduced: adding features that make validation rules stricter
– Meaning that, restrict the set of valid transactions or the set of valid
blocks such that
• the old version would accept all of the blocks,
• whereas the new version would reject some
• What happens
– When most nodes upgraded: Effects on new nodes
– Nodes running the new software will enforce some new,
tighter, set of rules.
– Upon majority, these nodes will be able to enforce the new
rules thereby adding the blocks into chain only if they satisfy
new rules
– When most of the nodes are not upgraded
• old miners might mine invalid blocks because they include some
transactions that are invalid under the new, stricter, rules
• classic example of a change that was made via soft fork is pay-to-script-
hash was not present in the first version of the Bitcoin protocol