The material in this presentation belongs to St. Francis Institute of Technology and is solely for educational purposes.

Distribution and modifications of the content is prohibited.

Blockchain
and DLT
(BLCH)
ITC801

Subject In-charge
Dr. Joanne Gomes
Professor Dept. of Information Technology SFIT
Room No. 316
email: [email protected]
Module 2
Lecture 8
Bitcoin
Topics: Bitcoin Network
• Bitcoin Core node and API, Peer-to-Peer Network Architecture, Node
Types and Roles,
• Incentive based Engineering, The Extended Bitcoin Network, Bitcoin Relay
Networks, Network Discovery,
• Full Nodes, Exchanging “Inventory”,
• Simplified Payment Verification (SPV) Nodes,
• SPV Nodes and Privacy,
• Transaction Pools
 Bitcoin Network
• The term “bitcoin network” refers to the collection of nodes
running the bitcoin P2P (peer-to-peer) protocol.
• The term, P2P means that the computers that participate in
the network are peers to each other, that they are all equal,
that there are no "special" nodes, and all nodes share the
burden of providing network services.
• The network nodes interconnect in a mesh network with flat
topology. There is no server, no centralized service, and no
hierarchy within the network.
• Decentralization of control is a core design principle and
that can only be achieved and maintained by a flat,
decentralized P2P consensus network.
• Other protocols such as Stratum, are also used for mining
lightweight or mobile wallets. These protocols are provided
by gateway routing servers that access the bitcoin network
using the bitcoin P2P protocol, and then extend that
network to nodes running other protocols.
 Nodes Types and Roles
• Nodes on Bitcoin P2P network may take on different
A full node with all four functions
roles depending on functionality they are supporting.
• A bitcoin node is a collection of functions:
– routing,
– the blockchain database,
– mining, and
– wallet services
• A full node is the one with all four of these functions
• All nodes include the routing function to participate in
the network and might include other functionality.
• All nodes validate and propagate transactions and
blocks, and discover and maintain connections to
peers.
 Nodes Types and Roles
A full node with all four functions
• Full node (Bitcoin Core Client):
– A full node is the one with all four of these functions
– maintains a complete and up-to-date copy of the blockchain.
– Creates new blocks by mining.
– Runs user wallet (with desktop bitcoin clients)
– can autonomously and authoritatively verify (route) any transaction
without external reference.
• Lightweight or Simplified Payment Verification (SPV) nodes: A SPV node with all four functions
– These nodes maintain only a subset of the blockchain and verify
(route) transactions using a method called SPV.
– Run user wallet (resource constraint devices such as mobiles)
– SPV nodes are drawn without the blockchain database function,.
– SPV nodes participate in pool mining and depend on a pool server.
• In Bitcoin networks, there are servers and nodes running other
protocols, such as mining pool protocols and lightweight client-
access protocols.
 The Extended Bitcoin Network
• The main bitcoin network, running the bitcoin P2P protocol, consists of 7,000 to
10,000 listening nodes running various versions of the bitcoin reference/core client
& few hundred other nodes such as BitcoinJ, Libbitcoin, and btcd.
• Few are mining nodes, competing in the mining process, validating transactions,
and creating new blocks.
• Various large companies interface with the bitcoin network by running full-node
clients with full copies of the blockchain, but without mining or wallet functions acting
as network edge routers, allowing various other services (exchanges, wallets, block
explorers, merchant payment processing) to be built on top.
• The extended bitcoin network includes the network running the bitcoin P2P protocol,
described above, as well as nodes running specialized protocols.
• Attached to the main bitcoin P2P network are a number of pool servers and protocol
gateways that connect nodes running other protocols.
• These other protocol nodes are mostly pool mining nodes and lightweight wallet
clients with stratum proocol, which do not carry a full copy of the blockchain.
The Extended Bitcoin Network
 Mining Pool
• A cryptocurrency enthusiast willing to gain profits through the standard mining
process either goes solo using their own mining devices or joins a mining pool
where a person's mining resources are clubbed with those of other pool miners to
improve the mining output with enhanced processing.
• In bitcoin mining process, if more miners are working, the difficulty level goes up,
while a decline in the number of miners eases the difficulty level.
• Pool, is a collection/group of miners working together to increase their chances of
finding a block at the group level, compared to that at the individual level.
• A mining pool essentially works as a coordinator for the pool members. Its functions
involve managing the pool members’ hashes, assigning reward shares to each pool
member in proportion to the work performed after suitable verification using pool
shares mechanism, etc. BTC.com is an example of mining pool.
• The Stratum protocol and other pool mining protocols provide a standardized way
for mining pools to communicate with their miners. Protocols also help buffer and
improve data transfer between mining pools, other miners.
 Network Discovery
• When a new node boots up, it must discover other bitcoin nodes on the network in order to
participate. To start this process, a new node must discover at least one existing node on the
network and connect to it.
• To connect to a known peer, nodes establish a TCP connection, usually to port 8333 (Bitcoin)
• Upon establishing a connection, the node will start a “handshake” by transmitting a version
message, which contains basic identifying information
Signals Information
PROTOCOL_VERSION A constant that defines the bitcoin P2P protocol version the client “speaks” (e.g., 70002)
nLocalServices A list of local services supported by the node, currently just NODE_NETWORK
nTime The current time
addrYou The IP address of the remote node as seen from this node

addrMe The IP address of the local node, as discovered by the local node
subver A sub-version showing the type of software running on this node (e.g.,
“/Satoshi:0.9.2.1/”)+
BestHeight The block height of this node’s blockchain
 Network Discovery
• The peer node responds with verack (version-ack) message
to acknowledge and establish a connection, and optionally
sends its own version message.
• The first method to find peers is to query DNS using a
number of “DNS seeds,” which are DNS servers that provide
a list of IP addresses of bitcoin nodes.
– Some of those DNS seeds provide a static list of IP addresses
of stable bitcoin listening nodes.
– Some of the DNS seeds return a random subset from a list of IP
addresses collected by a crawler or a long-running bitcoin node.
– Bitcoin Core client contains names of five different DNS seeds.

• In second method, a bootstrapping node that knows nothing

of the network must be given the IP address of at least one
bitcoin node, after which it can establish connections through
further introductions.
 Network Discovery
• The command-line argument -seednode can be
used to connect to one node just for introductions,
using it as a seed.
• After the initial seed node is used to form
introductions, the client will disconnect from it and
use the newly discovered peers.
• Once one or more connections are established, the
new node will send an addr message containing its
own IP address to its neighbors.
• The neighbors, in turn, forward the addr message to
their neighbors, ensuring that the newly connected
node becomes well known and better connected.
• The newly connected node can send getaddr to the
neighbors, asking them to return a list of IP
addresses of other peers to connect to them and to
advertise its existence on the network.
• Nodes come and go and must continue to discover
new nodes.
 Full Node
• Full nodes are nodes that maintain a complete and up-to-date copy of the bitcoin
blockchain with all transactions, which they independently build and verify, starting
with the very first block (genesis block) and building up to the latest known block in
the network.
• The full blockchain node relies on the network to receive updates about new blocks
of transactions, which it then verifies and incorporates into its local copy of the
blockchain.
• It requires 20+ gigabytes of persistent storage (disk space) to store the full
blockchain. It takes two to three days to sync to the network.
• The most common implementation of full blockchain bitcoin client is the reference
client Bitcoin Core, also known as the Satoshi client.
• More than 90% of the nodes on the bitcoin network run various versions of Bitcoin
Core.
 Exchanging “Inventory”
• Once a full node connects to peers, it will try to construct
a complete blockchain.
• The process of syncing the blockchain starts with the
version message, that contains BestHeight, a node’s
current blockchain height.
• A node will be able to compare to how many blocks it has
in its own blockchain, compared to other nodes.
• Peered nodes will exchange a getblocks message that
contains hash of the top block on their local blockchain.
• One of the peers will be able to identify the received hash
as belonging to a block that is not at the top, but rather
belongs to an older block, thus deducing that its own
local blockchain is longer than its peer’s.
• The peer that has the longer blockchain and can identify
which blocks the other node needs in order to “catch up.”
It will identify first 500 blocks to share and transmit their
hashes using an inv (inventory) message. On getdata
request it will send the blocks.
 Simplified Payment Verification (SPV) Nodes
• Many bitcoin clients are designed to run on space and power-constrained devices, such as
smartphones, tablets, or embedded systems and can not store full blockchain.
• For such devices, a simplified payment verification (SPV) method is used to allow them to
operate without storing the full blockchain.
• SPV nodes
– download only the block headers and do not download the transactions included in each block. The
resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain.
– cannot construct a full picture of all the UTXOs that are available for spending because they do not
know about all the transactions on the network.
– verify transactions using a methodology that relies on peers to provide partial views of relevant
parts of the blockchain on demand.
• SPV verifies transactions by reference to their depth in the blockchain instead of their height.
• It will verify the chain of all blocks (but not all transactions) and link that chain to the
transaction of interest.
 Simplified Payment Verification (SPV) Nodes
Block 300006
• For example, when examining a transaction in block 300,000,
a full node links all 300,000 blocks down to the genesis block Block 300005
and builds a full database of UTXO, establishing the validity of Block 300004
the transaction by confirming that the UTXO remains unspent.
Block 300003
• An SPV node cannot validate whether the UTXO is unspent.
Instead, the SPV node will establish a link between the Block 300002
transaction and the block that contains it, using a merkle path.
Block 300001
• Then, the SPV node waits until it sees the six blocks 300,001
through 300,006 piled on top of the block containing the Block 300000
transaction and verifies it by establishing its depth under
blocks 300,006 to 300,001.
• The fact that other nodes on the network accepted block
300,000 and then did the necessary work to produce six more
blocks on top of it is proof, by proxy, that the transaction was
not a double-spend.
• The SPV node establishes the existence of a transaction in a
block by requesting a merkle path proof and by validating the
proof of work in the chain of blocks.
 Simplified Payment Verification (SPV) Nodes
• To get the block headers, SPV nodes use a
getheaders message instead of getblocks.
• The responding peer will send up to 2,000 block
headers using a single headers message.
• SPV nodes also set a filter on the connection to peers,
to filter the stream of future blocks and transactions
sent by the peers.
• Any transactions of interest are retrieved using a
getdata request. The peer generates a tx message
containing the transactions, in response.
• Figure shows the synchronization of block headers.
• To avoid denial-of-service attack or a double-spending
attack against SPV nodes, an SPV node needs to
connect randomly to several nodes, to increase the
probability that it is in contact with at least one honest
node (and not fake nodes).
 SPV Nodes and Privacy
• The SPV node’s requests for retrieving specific transactions, can reveal the
addresses in their wallet.
• A third party monitoring a network could keep track of all the transactions requested
by a wallet on an SPV node and use those to associate bitcoin addresses with the
user of that wallet, destroying the user’s privacy.
• SPV nodes use bloom filters to address their privacy risks.

• Bloom filters allow SPV nodes to receive a subset of the transactions without
revealing precisely which addresses they are interested in, through a filtering
mechanism that uses probabilities rather than fixed patterns.

• A more specific bloom filter will produce accurate results, but at the expense of revealing
what addresses are used in the user’s wallet.
• A less specific bloom filter will produce more data about transactions, may be irrelevant, but
will allow the node to maintain better privacy.
 Bloom Filters - BIP0037
• A bloom filter is a probabilistic search filter which describes a desired pattern without
specifying it exactly. It is an efficient way to express a search pattern while protecting privacy.
• They are used by SPV nodes to ask their peers for transactions matching a specific pattern,
without revealing exactly which addresses they are searching for.
• SPV node will initialize a bloom filter as “empty”, will make a list of all addresses in its wallet &
create a search pattern matching the transaction output that corresponds to each address.
– The search pattern is a P2PKH script that is the expected locking script that will be present in any
transaction paying to the public-key-hash. Or If the SPV node is tracking the balance of a P2SH
address, the search pattern will be a pay-to-script-hash script.
– The SPV node then adds search patterns to the bloom filter, so that filter can recognize the search
pattern if it is present in a transaction. Then bloom filter is sent to the peer and the peer uses it to
match transactions for transmission to the SPV node.
• Bloom filter pattern consists of
– Hashes of wallet addresses (or public keys).
– Hashes of scripts if using multi-sig or P2SH.
– Transaction IDs related to its previous transactions.
 Bloom Filters - BIP0037
• Bloom filters are implemented as a variable-size array of N binary digits (bits) and a variable
number of M hash functions. Choosing M and N can vary the level of accuracy

• The hash functions are designed to always produce an output that is between 1 and N. The
hash functions are deterministic will produce the same results for a specific input.
 Bloom Filter - BIP0037
• To add a pattern to the bloom filter, the pattern is hashed by each hash function in turn.
• Applying the first hash function to the input results in a number between 1 and N. The
corresponding bit in the array (indexed from 1 to N) is found and set to 1, thereby recording
the output of the hash function.
• Then, the next hash function is used to set another bit and so on. Once all M hash functions
have been applied, the search pattern will be “recorded” in the bloom filter as M bits that
have been changed from 0 to 1.
• For every next pattern same process is repeated M times and new set of m outputs are set to
1. More patterns record on overlapping bits, reducing accuracy of the filter.
Bloom Filter
 Bloom Filters and Inventory Updates
• Bloom filters are used to filter the transactions (and blocks containing them) that an
SPV node receives from its peers.
• SPV nodes will create a filter that matches only the addresses held in the SPV
node’s wallet. The SPV node will then send a filterload message to the peer,
containing the bloom filter to use on the connection.
• After a filter is established, the peer will then test each transaction’s outputs against
the bloom filter. Only transactions that match the filter are sent to the node.
• In response to a getdata message from the node, peers will send a merkleblock
message that contains only block headers for blocks matching the filter and a
merkle path for each matching transaction.
• The node setting the bloom filter can interactively add patterns to the filter by
sending a filteradd message.
• To clear the bloom filter, the node can send a filterclear message. Because it is not
possible to remove a pattern from a bloom filter, a node has to clear and resend a
new bloom filter if a pattern is no longer desired.
 Testing pattern
• To test if a pattern is part of a bloom filter, the pattern is hashed by each hash
function and the resulting bit pattern is tested against the bit array.
• If all the bits indexed by the hash functions are set to 1, then the pattern is probably
recorded in the bloom filter.
• Because the bits may be set because of overlap from multiple patterns, the answer
is not certain, but is rather probabilistic.

• In simple terms, a bloom filter positive match is a “Maybe, Yes.”

• But, if a pattern is tested against the bloom filter and any one of the bits is set to 0,
this proves that the pattern was not recorded in the bloom filter.

• A negative result is not a probability, it is a certainty. Hence a negative match on a

bloom filter is a “Definitely Not!”.
 Transaction Pools
• Every node on the bitcoin network maintains a temporary list of unconfirmed
transactions called the memory pool, mempool, or transaction pool.
• Nodes use this pool to keep track of transactions that are known to the network but
are not yet included in the blockchain.
• For example, a node that holds a user’s wallet will use the transaction pool to track
incoming payments to the user’s wallet that have been received on the network but
are not yet confirmed.
• As transactions are received and verified, they are added to the transaction pool
and relayed to the neighboring nodes to propagate on the network.
• Some node implementations also maintain a separate pool of orphaned
transactions. If a transaction’s inputs refer to a transaction that is not yet known,
such as a missing parent, the orphan transaction will be stored temporarily in the
orphan pool until the parent transaction arrives.
– When a new transaction is added to the transaction pool, the orphan pool is checked for
any orphans that reference this transaction’s outputs
 Transaction Pools
• Both the transaction pool and orphan pool are stored in local memory and are not
saved on persistent storage.
• When a node starts, both pools are empty and are gradually populated with new
transactions received on the network.
• Some implementations of the bitcoin client also maintain a UTXO database or
UTXO pool, which is the set of all unspent outputs on the blockchain.
• Unlike the transaction and orphan pools, the UTXO pool is not initialized empty but
instead contains millions of entries of unspent transaction outputs, including some
dating back to 2009.
• The UTXO pool may be housed in local memory or as an indexed database table on
persistent storage.
Thank You