Blockchain & Bitcoin

Basic Notions

Lionel Brunie1, Youakim Badr1,2, Omar Hasan1

(1) Institut National des Sciences Appliquées de Lyon

(2) Pennsylvania State University (PennState University), Philadelphia, USA

Lionel.Brunie@insa-lyon.fr
 Blockchain: an Overview (1/2)
• A blockchain is… a chain of blocks of data

• A blockchain is a distributed data structure (=> dist. ledger)

• The concept of blockchain is application agnostic

• Blockchain <> cryptocurrency/Bitcoin

• By its design and using cryptography, blockchains enforce some properties: integrity,
traceability, non-repudiability, availability, reliability, security: wahouuuuu!

• Some blockchains store and execute codes (“smart contracts”) (with same enforced properties)

• A blockchain is often decentralized i.e., there is no trusted node (no trusted third party) =>
network of autonomous “peers” + “code is law”
 Blockchain: an Overview (2/3)
• No trusted coordinator/network of autonomous peers + consistency => need for (distributed) consensus

• Peers maintain the blockchain consistency and decide on updates (“mining”)

• Actually, only some of the peers do this job, the miners; others maintain the network topology and
distributed the messages; others are only pure end-users

• Some mining+consensus protocols waste computing resources, some don’t; some are scalable, some
are not; some are fully decentralized, some are not

• Some blockchains are public (i.e., open), some are private (i.e., permissioned)

• Some blockchains e.g., Bitcoin, are used to operate cryptocurrencies => data = financial transactions
(“ledger”)

• There are hundreds models of blockchain, Bitcoin (launched in 2008/2009) is just like a dinosaur in this
ecosystem; some distributed ledgers are not blockchains (i.e., not chains of blocks)
 Blockchain: an Overview (3/3)

• Blockchains by design were “closed worlds” but they can now interoperate (see cede-labs
funded by former 5IF students) and can integrate “classical” digital ecosystems (well, it still
needs some effort!)

• Due to the properties they enforce, blockchains are widely considered as a prominent
emerging technology for IT (but it is so disruptive that… it still need some effort)

• A lot of false- or mis-information is spread about blockchains, much of it by people who do

not know anything about them. Diversify your sources of information (do not (fully) trust me (I
may be wrong!)) and use your critical mind

• Many applications can benefit from blockchain properties and design, some not
Let’s start by basic cryptographic notions
and recalls
 Basic Tools - Recalls (1/4)
• Cryptographic Hash Function
– Associates a variable-size digital object with a fixed-size character string (called hash, hash value,
hash code, digest, fingerprint…)

– One-way
• Fast hash calculation (repetitions of additions, shifts, rotation, XOR, ^, etc.)
• Extremely difficult inverse calculation
• Very low probability of getting the same hash with two different input data (collision)
• Small modification of the input data => random modification of the hash
• Different hashes => different input data almost certain

– Usage
• Integrity: unmodified hash => unmodified data with near certainty
• Masking of information, ownership and authenticity (log): storing the hash of data makes it possible to hide its content
and minimize storage space; however, the owner of the input data may, by revealing this data, restore its content, the
authenticity of which being guaranteed by the hash
 Basic Tools - Recalls (2/4)
• Asymmetric Cryptography
– Two associated keys: public key / private key
– Public key... public (openly displayed/known to all)!
– Private key... private/secret (kept in your possession and never
transmitted to no one)
– Almost impossible to deduce one of the keys from the other
– Encryption with one key, decryption with the other key
– Usage
• Confidentiality: encrypt with the public key of the recipient
• Authentication: encrypt with the sender's private key
 Basic Tools - Recalls (3/4)
M : message
+ -
KB , KB : B’s public/private key
• Digital Signature (+ data encryption) KA+, KA- : A’s public/private key
H : hash function

K +B K-B

Decryption
Hash
Encryption

Hash

Decryption
Encryption
H H = H2 ?

Node A Node B
This is the signature!
Alternative: sign the encrypted document itself Adapted from Lucas Bouillot, IF student
 Basic Tools - Recalls (4/4)
• Digital Signature (cf. previous slide)

– Issuer side
• Hash the document (SHA, MD*, Whirlpool…) → hash
• Encrypted the hash using your private key → signature
• Send the document along with the signature ("signed document") to the recipient

– Recipient side
• Hash the received document
• Compare this hash with the hash signed by the sender
• Equality of the hashes => document received = initial document
• Inequality of the hashes => document received ≠ initial document
 Hash pointer

A hash pointer is a pointer to where data is stored together with a cryptographic hash
of the value of that data.

A hash pointer gives you a way to verify that the information has not changed.

Pointer to the data block + Hash of the data

Or simply: Hash of the data (the hash serves also as

pointer to/identifier of the data)


One can use hash pointers to build various kinds of data structures, such as a linked
list or a binary search tree.
An Example of Public Blockchain :
Bitcoin
 What is Bitcoin?
• Seminal paper: “Bitcoin: A Peer-to-Peer Electronic Cash System”, by Satoshi Nakamoto, Oct. 2008

• “Bitcoin is a decentralized digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin
uses peer-to-peer technology to operate with no central authority: transaction management and money issuance are
carried out collectively by the network” (Bitcoin Wiki)

• “The [Bitcoin] blockchain is a shared public ledger on which the entire Bitcoin network relies. All confirmed
transactions are included in the blockchain. This way, Bitcoin wallets can calculate their spendable balance and new
transactions can be verified to be spending bitcoins that are actually owned by the spender. The integrity and the
chronological order of the block chain are enforced with cryptography” (bitcoin.org)

• “A transaction is a transfer of value between Bitcoin wallets that gets included in the block chain. Bitcoin wallets
keep a secret piece of data called a private key or seed, which is used to sign transactions, providing a mathematical
proof that they have come from the owner of the wallet. The signature also prevents the transaction from being
altered by anybody once it has been issued. All transactions are broadcast between users and usually begin to be
confirmed by the network in the following 10 minutes, through a process called mining” (bitcoin.org)

• See also: https://en.bitcoin.it/wiki/Myths

Let’s go and discover Bitcoin !!!
Part I: Basic Concepts
 Bitcoin Address
• Bitcoin manages transactions (i.e., flows) of « coins »

• A coin « belongs » to an address (~identity)

• Analogy: an address is like a purse: in a transaction, a coin “flows” from a purse to another one. To use a
coin, one must open the purse in which it is stored; to open the purse, one must have the key that do it

• An address is the 160-bit hash of the SHA256 hash of the public key of a public/private ECDSA keypair
(RIPEMD160(SHA256(ECDSA_publicKey)))

• No central authority => Bitcoin allows one to create as many addresses (cf. analogy: as many purses)
as one wants, and use a new one for every transaction => notion of wallet

• A pure P2P decentralized (and so, autonomous) approach

– No trust => peers and suppose non-trustworthy (= potentially malicious) !
– If you lose your keys, no way to get your bitcoins (=> keep them safe!)
– No “central”/reference/authority truth, only consensus
Conversion of a Public Key into a Bitcoin Address (1/2)

From A. M. Antonopoulous, Mastering Bitcoin

Conversion of a Public Key into a Bitcoin Address

A candidate (recently, a preferred)

Format (segwit format): Bech32
(BIP-0173*)

*BIP: Bitcoin Improvement Proposal

From A. M. Antonopoulous, Mastering Bitcoin

 Wallet
• Wallet = collection of private keys; actually, wallet = client software used to
manage those keys and to make transactions on the Bitcoin network
• Ex:

deterministic (seeded) wallet Type-2 HD wallet: a tree of keys generated

From: https://github.com/cypherpunks-core from a single seed
 Wallet
• Wallet = collection of private keys; actually, wallet = client software
used to manage those keys and to make transactions on the
Bitcoin network
• Ex:

deterministic (seeded) wallet ype-2 HD wallet: a tree of keys generated

from a single seed
 Bitcoin Transaction (1/4): Basics
• A transaction transforms inputs (coins) into output (coins)
• Once used, input coins cannot be anymore used as inputs

• Inputs/Outputs can represent any amount of satoshis (some miners impose a minimum) ((1 satoshi = 1/10^8 bitcoins))

• Inputs (input coins) must have been produced as outputs of a previous transaction i.e., an input = reference to
an output from a previous transaction

• The total value of the inputs must be >= total value of the outputs

• Surplus = fees for the miner

• Note: an important dataset: the Unspent Transaction Outputs (UTXO) set

• Note : transaction fees are quite volatile

– March 2nd, 2024 :average transaction fees: $7.67 (Feb. 23 rd: $3.884, Feb. 29th: $11.47) – 1 year ago: $1.699
– Jan. 2018 (max median): median transaction fees: $34
– Apr. 2021 (max average): average transaction fees: $62 (only $24 4 days later)
Bitcoin Transaction (2/4): Examples of Transactions

Transaction A creates a 100 coin and gives it to Alice

Transaction B creates a 50 coin and gives it to Alice

These 2 coins are used by Alice as inputs for transaction C

Þ Total input value = 100+50=150

Transaction C creates 2 new coins from this 150 input: one 49 coin and one 101 coin

The 101 coin is used by Alice in Transaction D to pay some service (e.g., buy something)
The 49 coin goes to Alice’s wallet (~change)

From en.bitcoin.it
 Bitcoin Transaction (3/4): (Initial) Format
• Version number (currently, 1)

• Flag (optional; if present, always 1 to indicate the usage of witnesses)

• Nb of inputs (= nb of input coins)

• List of inputs (= input coins)

• Nb of outputs (= nb of output coins)

• List of outputs (= output coins)

• Lock time (block height or timestamp when the transaction can be included into a block)
(i.e., time at/first block in which a transaction can
be added to the blockchain)
 Bitcoin Transaction (4/4): (Initial) Format (Cont’d)
• Input format
– id of the previous transaction (“txid” i.e., double SHA256 of
the content of the transaction) from which the input was produced Reference to the input coin
– index number referencing the specific output of this transaction
– script length
– script (redeem/unlocking script: used notably to check the ownership of the input, i.e. check the
“true owner” of the coin agrees to spend it; actually, ask for a signature + the public key matching
the address of the coin to be used)
– sequence number (allows modifying the transaction before LockTime expires (not implemented))

• Output format
– value : number of satoshis (1 satoshi = 1/10^8 bitcoins)
– script length
– script (locking script e.g., (P2PKH) includes the Bitcoin address of the recipient of the output
(hash of her public key))
 Example of Transaction

https://www.blockchain.com/explorer?view=btc_transactions

https://btc.com/
 Bitcoin Transaction: Sending to the Network
• Create the transaction data, i.e., fill the transaction fields (add fees to the
transaction amount, select input coins, check the total value of the input coins is
sufficient, check the fees are sufficient, compute the change)

• In the transaction data, add for each input coin (cf. scriptSig unlock script below)
• The public key Pk, that was used to create the address to the coin
• The signature of the transaction, using the dual of Pk private key

• See https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp
 Scripts and Verification (1/2)
• Stack-based language (Forth-like)

• Submission of a transaction: send the transaction to the network + the public key of the coin + the proof of
ownership of the coin (see below)

• Pay-to-PubKey-Hash (P2PKH) Transaction

– script on the inputs (scriptSig): <sig> <pubKey>: “unlocks” the coin (“redeem script”)
– script on the outputs (scriptPubKey): OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG:
“locks” the coin
– in order to use a coin (i.e., input of a transaction), the “owner” of this coin provides her public key (<pubKey>) + her
signature (<sig>) of the transaction
– the combination of the 2 scripts (redeem/lock script + unlock coin script) allows verifying that the hash of the public key
matches the address attached to the “coin” (<pubKeyHash>) (i.e. the address of the recipient of the output corresponding
to the “coin”) and that the signature is correctly decrypted by this public key
– i.e., miners enforce a double verification: that the emitter of the transaction knows the public key which
corresponds to the address attached to the coin; and, that she knows the private key which matches this public
key (for this purpose, one uses a “challenge”: “sign the transaction with your private key”)
– analogy: when using a bank cheque, you must present your id (=> verification that the name on the cheque = the name
on the id) (which can be stolen) and show your face (to be matched against the picture on id: second verification)
 Example of Script Execution

pubKey: key provided by the owner of the coin in order to use/redeem it (scriptSig): hashed as pubKeyHash
From Judmayer and al.
pubKeyHash: address of the recipient of the coin (former/referenced transaction) (scriptPubKey)
 Scripts and Verification (2/2)

• Pay-to-Script-Hash (P2SH) Transaction

– Allows sending coins to a script hash instead of a public key hash
– In order to spend these coins, the recipient must provide a script that matches the script hash and data which makes
the script evaluate to true
– Used to implement “(smart) contracts”
– Execution of the script: see e.g., https://learnmeabitcoin.com/guide/p2sh

• See https://en.bitcoin.it/wiki/Script
 Bitcoin Transaction: Signature Types (1/3)
• Actually, Bitcoin proposes various options for the content to sign i.e., what part of
the transaction is actually signed

• Note: unlocking scripts (see SigScript above) i.e., the signature and the public key
are never signed as (i) signing a signature would do not make sense and (ii) their
role is only to satisfy the redeem conditions (as stated by the locking scripts
specified in the transactions which created the inputs) and not sensitive
transaction data (output coins (value et addresses)). If, for any reason, the
signature or public key is tampered/modified/damaged during the broadcast, the
transaction verification failed without any consequence but the need for the
transaction issuer to resubmit the transaction
 Bitcoin Transaction: Signature Types (2/3)
• Signature options are called signature hash types. A specific flag, SIGHASH, defines the type
actually used in the transaction

• There are 6 different flags. Most used flags are

– SIGHASH_ALL, the default type: sign all inputs and outputs, thus protecting all the transaction data except
the signature scripts (aka unlocking scripts) against modification

– SIGHASH_NONE: sign all of the inputs but none of the outputs, allowing anyone to change where the
satoshis are going before the transaction is submitted to the network (“blank check”). Such a transaction is
clearly unsecure unless it is “covered” by another signature (i.e., other input coin owned by somebody else
who uses a “not none” signature hash. Example : Alice and Bob want to offer Carol a gift; Bob is in charge of
buying the gift; Alice give some money and signs a SIGASH-NONE type signature, letting Bob choose the
gift and sign the transaction including the address of the output coin)

– SIGHASH_SINGLE: sign all input + the output that shares the same index as the input being signed
=>impossible to change your part of the transaction but allowing other signers to change their part of the
transaction.
 Bitcoin Transaction: Signature Types (3/3)
• There are 6 different flags (Cont’d)
– SIGHASH_ALL|SIGHASH_ANYONECANPAY signs all of the outputs + one input => the destination and the
amount of the output(s) are fixed but the input list is open so that anyone can add her input with her
signature to contribute to the transaction (crowd funding).

– SIGHASH_NONE|SIGHASH_ANYONECANPAY signs only one input and no output => allows anyone to add
or remove other inputs or outputs.

– SIGHASH_SINGLE|SIGHASH_ANYONECANPAY signs one input and its corresponding output => allows
anyone to add or remove other inputs or outputs but nobody can change that output (i.e., allows some kind
of merge of transactions)

• Almost all Bitcoin transactions are of type SIGHASH_ALL (default type)

• For more information, see: https://wiki.bitcoinsv.io/index.php/SIGHASH_flags and

https://developer.bitcoin.org/devguide/transactions.html
From Transaction to Block(chain)
 Blockchain (a first overview)

Blockchain


Bitcoin = ledger of financial transactions i.e., data = set of transactions
(+ management header)
 Structure of a Block (Bitcoin)

• 3 fields
– Header: 80 Bytes
– Number of transactions (Varint) e.g., n
– n concatenated transactions

• Total size <= 1MB (this strongly limits the Bitcoin “bandwidth”; see
below)) (modified by the Segwit protocol (see below)
 Block Header (Bitcoin)
• 80 Bytes

• Version number (4 Bytes)

• Hash pointer to the previous block (32 Bytes)

• Root of the Merkle tree formed by the n transactions stored in the block (hash) (32 Bytes)

• Timestamp (uint32) (4 Bytes)

• nBits: Difficulty to solve the block (cf. mining) (uint32) (4 Bytes)

• Nonce result of the puzzle (cf. mining) (uint32) (4 Bytes)

Merkle Tree
• Efficiency: O(log(n))

• Integrity Control: if
the content of a
transaction is
altered, the Merkle
root changes

• Ralph Merkle, 1979

From Wikipedia
 Example of Block

https://www.blockchain.com/explorer?view=btc_blocks

https://btc.com/
 Blockchain (1/2)
• Block = data (transactions in Bitcoin)

• Hash (SHA256 (x2) of a block = address (~ unique id) of this block. In Bitcoin, one considers the
hash of the header.

• A block can also be identified by its height (note: in case of a “fork”, 2 blocks may have the same height
in two different branches)

• The header contains the root of the Merkle tree formed by the transactions stored in the block => a
change in the previous block payload => change of the Merkle tree => change of the block address =>
change of the child “previous block hash” field => change of the child address => etc. => immutability

• Block hashes are computed by each node when it receives the block (it is usually stored in a separate
database for indexing and retrieval purposes)
 Blockchain (2/2)
• Blocks are chained (ordered)

• “Full nodes” maintain a local copy of the entire blockchain

• Initial block: the “Genesis Block” (Bitcoin genesis block address (cf. chainparams.cpp):
0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f)

head

Genesis Block
Malleability, Malleability Attack, SegWit Protocol (1/3)
• Signatures are encoded in ASN.1; DER (Distinguished Encoding Rules) should be used to
guarantee a single representation
• Issue: DER is not always used; OpenSSL, which is used by Bitcoin, does not enforce it and
encoders are often buggy => verifiers tend to be “lenient”
• Consequence: signature malleability: it is possible to represent a signature with different
encodings
• Issue: signature malleability attack:
– an attacker creates a (valid) transaction with one of her coins as input ; she provides her signature to unlock the
coin
– In the pool of pending transactions (mempool), this transaction is indexed by its hash
– Then the attacker reuses the same coin in a second (valid) transaction using another encoding of her signature
– This second transaction is referred with a different id (hash) => the two transactions are placed in the mempool
– If the second transaction is confirmed before the first one, then the first one becomes invalid (double spending
of the coin) => the recipient of the transaction cannot get her money
• Other issue: scriptSig malleability: it is impossible to sign the scriptSig (a signature cannot
sign itself!) => possible to add unexpected data in the script
• https://medium.com/@herman_10687/malleability-attack-why-it-matters-7b5f59fb99a4
Malleability, Malleability Attack, SegWit Protocol (2/3)
• Segwit (Segregated Witness) protocol (introduced in 2017)
– Soft fork

– “Segregates the signature from the transaction id calculation”

– Separates the inputs/outputs from the “witness” i.e., the data necessary to check to validity of the
transaction (P2PKH “witness” = public keys and signatures)

– New format: n_version||marker (=0)||flag (=1)||inputs||outputs||witness||n_Lock_Time

– The witness is not taken into consideration to compute the txid (called “wtxid)

– 2nd Merkle tree of the witness data (stored as data (OP_RETURN) in the coinbase transaction)
(witness Merkle tree). Block validation  Merkle tree root OK and witness Merkle tree root OK

– New Pay-to-Witness-PubKey-Hash (P2WPKH) and Pay-to-Witness-Script-Hash (P2WSH) scripts

– Enables the Lightning protocol (see below)

 Malleability, Malleability Attack, SegWit Protocol (3/3)
• Segwit (Segregated Witness) protocol (introduced in 2017) (Cont’d)
– Consequence
• The malleability issue is fixed as the id of the transaction does not consider the signature anymore

– Additional features
• Extension of the size of the block
– Before: limited to 1MB
– Now: limited to 4 millions of weight units; 1 byte of non-witness data = 4 units; 1 byte of witness
data = 1 unit
• Upgrade of the signature functions to reduce their complexity
• Inclusion of the value of the coin in the hash which is signed => no more need for the wallets to find out
the value of a coin before signing the transaction (if the signed value does not match the actual value,
the signature will be invalid and the transaction be rejected)
– SegWit transactions represented 97% of all BTC transactions in 2923 (+14%)

– https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki (BIP: Bitcoin Improvement Proposal)

 Block Mining and Consensus Protocol (1/7)
• Transactions are broadcasted to the Bitcoin P2P network

• Mining = adding transaction records to Bitcoin's public ledger of past transactions

• This ledger is used to log legitimate transactions and prevent double spending

• This ledger = blockchain

• Issue: all peers must “see” the ledger in the same way (same blocks, same transactions) i.e.,
need for a consensus protocol
 Mining Blocks and Consensus Protocol (2/7)
• Miners role: check transactions, collect transactions to create blocks, chain blocks

• Checking transactions
– Check sum(inputs) >= sum(outputs)
– Check input coins have not already been spent (no double spending; cf. UTXO)
– Check redeem scripts (i.e., owners of the input coins agree to use them (= signed the transaction))

• Miners are rewarded for their work

– In each block, a reward transaction (“coinbase transaction”) is included. This transaction creates new
coins which are given to the miner. This reward halves every 210000 blocks (~4 years). Since May
11th, 2020 the reward = 6,25 bitcoins (50 bitcoins upto 2012). Next halving: mid April 2024
– Transactions may (actually should) include “transaction fees” that are given to the miner

• Mining is the only way to create coins

• Mining pools
 Mining Blocks and Consensus Protocol (3/7)
• Need for reliability and consensus!
– No trusted third party => who/how-to decide on the content of the blockchain?

– Concurrent/Asynchronous computing => possibility of different “visions”/versions

– Possibility of abuses e.g., DoS, spam, etc.

 Mining Blocks and Consensus Protocol (4/7)
• Deterring abuses in Bitcoin: Proof of work (PoW)
– PoW = piece of data hard to produce but whose validity can be easily verified. I.e., PoW requires miners
to spend CPU cycles (=> buy hardware and pay electricity)
– Objective: make abusing costly and difficult => only reliable peers can actually mine the blockchain

– Bitcoin PoW:
find a value (nonce = the “proof of work”) such that the hash of the concatenation
“header of the block + nonce” is lower that a specified threshold (the “target”) (i.e. the
hash starts with a certain number of ‘0’)

– as the coinbase transaction is specific to each miner (as it includes its address), each miner mines a
“personalized” block i.e., each miner solves a different puzzle
– Unpredictability and fairness of the puzzle => a miner with x% of the total computing power has x%
chance to be the first to solving the puzzle
– The difficulty of the puzzle is set to such a difficulty (target) that a block is mined approx. every 10 mn
– PoWs are verified by the other miners
 Mining Blocks and Consensus Protocol (5/7)
• An alternative to Proof-of-Work: Proof-of-Stake (PoS)
– First cryptocurrency using PoS: Peercoin
– Ethereum moved to PoS Sept. 22nd, 2022 (“The Merge”) (see below)
– No more puzzle to solve
– Basic idea: select the creator of the next block wrt its wealth (“stake”) (reason: this peer is the most
interested in the good functioning of the blockchain; if it cheats, the value of the coin will fall and it will
lose its money)
– Issue: risk of centralization: only the “richest peer” can mine new blocks
– Solutions: introduce some randomness, use the age of the coins (e.g., in PeerCoin, only coins unspent
for more than 30 days are considered), promote peers who submit more transactions
– Note: in PoS, no creation of new coins

• Another alternative: Proof-of-Reputation (PoR)

• See also: Byzantine Fault Tolerant (BFT) consensus protocols (cf. 5IF course, Sonia Ben
Mokhtar)
 Mining Blocks and Consensus Protocol (6/7)
• Agree on the content of the blockchain: Consensus algorithm

– The P2P Bitcoin network is an asynchronous network => multiple miners may solve their own puzzle
at the same time; each of them then broadcasts its block to the network => the chain is now “forked”

– A consensus protocol is required to fix this issue and make a decision on which block is the new block
 Mining Blocks and Consensus Protocol (7/7)
• Bitcoin protocol: choosing the longest chain
– If a node receives two blocks with the same “previous block hash” field (thus facing a chain with 2
branches), it stores both of them and tries to append a new block to one of the 2 branches (typically,
the first it receives)
– In the meantime, if it receives a new block for one of the branches, it discards the other one (i.e., the
shortest one)
– Eventually, all miners agree on the same chain (actually, as the chain always grows, they agree on
the same prefix)
– When a miner receives a longer chain, it needs to “roll back” the blocks (called “orphan blocks”) down
to the fork, then to add the newly received blocks
– Rewards attached to orphan blocks are not spendable (actually, not spendable on the longest
blockchain)
– Transactions logged in an orphan block return back to the memory/transaction pool of the miners
– The “length” of a branch is computed as the sum of the difficulties of the blocks of the branch (cf.
block header)
– It is usually considered that a block is confirmed after 6 other blocks are added to the blockchain

• Risk: 51% Attack

Mining Blocks and Consensus Protocol: Ethereum
– Ethereum¨PoS:
• “The Merge”: Sept. 15th, 2022
• “To participate as a validator, a user must deposit 32 ETH into the deposit contract […]
• One validator is randomly selected to be block proposer. This validator is responsible for creating a new block and
sending it out to other nodes on the network
• A committee of validators is randomly chosen to determine the validity of the block being proposed”. These validators
re-execute the transaction to check that the proposed changes to Ethereum's state are valid, and they check the block
signature. Based on these verifications, each validator of the committee broadcasts a vote (called “attestations)”
• If the block is invalidated, the validator who proposed the block lose a part of all of her deposit
• Time is divided into slots (12 seconds) and epochs (32 slots) ; the above protocol is executed in each slot
• Finalization: the first block in each epoch is a checkpoint. “Validators vote for pairs of checkpoints that they consider to be
valid. If a pair of checkpoints attracts votes representing at least two-thirds of the total staked ETH, the checkpoints are
upgraded. The more recent of the two (target) becomes "justified". The earlier of the two is already justified because it
was the "target" in the previous epoch. Now it is upgraded to "finalized". […] To revert a finalized block, an attacker would
commit to losing at least one-third of the total supply of staked ETH
• https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/

• The Merge reduced Ethereum's annualized electricity consumption by more than 99.988%. Likewise, Ethereum’s
carbon footprint was decreased by approximately 99.992% (from 11,016,000 to 870 tons CO2e) (CCRI (Crypto Carbon
Ratings Institute) study; see also Cambridge index)
• Ethereum electricity consumption ~30 000 to 50 000 times less than Bitcoin’s
 Storing non-Financial Data in Bitcoin (1/3):
OP_RETURN Script Operator
• OP_RETURN, when placed in an output script (scriptPubKey), makes the script fail => the
coin to which the script is attached is unspendable (“burnt”)

• Data placed after the OP_RETURN operator are not read by the miner (but they are stored
in the ledger)

• One can store upto 80 Bytes after OP_RETURN

• Used to create “colored” coins

• In March 2020, it represented 22% of all Bitcoin transactions (~10GB from Sept. 14 th, 2018
to December 31st, 2019) (E. Strehle et al. “Dominating OP Returns: The Impact of Omni and
Veriblock on Bitcoin”, March 2020) ; come mainly from two services (Omni and Veriblock)
• OP-RETURN transactions ~5% of all Bitcoin transactions created in 2023
 Storing non-Financial Data in Bitcoin (2/3):
Multisignature
• m of n: n addresses are attached to an output coin; at least m of
them must sign in order to use this coin

• Often use to introduce an escrow (signature 2 of 3)

• May be used to store information (“fake” address of a 1 of 2

signature)

• OP_CHECKMULTISIG operator
 Storing non-Financial Data in Bitcoin (3/3):
The Nine Ways to Insert Data in Bitcoin Blockchain
1. Coinbase transaction data field (used by miners (e.g. to declare the name of their mining pool or to
insert clims/recommendation regarding changes in Bitcoin protocol)
2. P2FKH (Pay-to-Fake-Key-Hash) script: store the date in the address field (Pub-Key-Hash) of the
output script = 20 data bytes/output address (=> need to « burn » some satoshis); formally valid
transaction => need to be kept by thee miners in the UTXO set
3. P2FK (Pay-to-Fake-Key) script: in the same way, store the data as as a fake public key (65 bytes) or
fake compressed public key (33 bytes), instead of a fake public key hash (deprecated)
4. OP_RETURN: considered as provably unspendable UTXO => not tracked in the UTXO set (=> some
risks/difficulty regarding the permanent storage of the data (pruning by the miners)
5. P2FMS (Pay-to-Fake-Multisig): e.g. one real address/public key and 2 fake addresses => spendable ;
more costly
6. P2FSH (Pay-to-Fake-Script-Hash)
7. 2 stages of P2SH (Pay-to-Script-Hash) transactions and store data in the scripts
8. OP_DROP: push data onto the stack (input script) and drops it off the the stack at output script
execution time: used to store relatively large amounts of data
9. Data Hash: similar but uses hashes to prevent data tampering
A. Sward et al. “Data Insertion in Bitcoin’s Blockchain” (2018)
Network Node Types and Roles
 Side Chain – Side Database – Lightning Protocol (1/3)

• Side chain

– Side chain = “separate” blockchain linked to the parent

blockchain (e.g., Bitcoin) through a currency exchange
protocol

– Unload Bitcoin with specific transactions

– Use verification protocols and business logic specific

to the application supported by the side chain

– May be private/controlled

– See e.g., roll-ups: “An Incomplete Guide to Rollups,”

by V. Buterin, 2021
From M. Saugier (5IF)’s PhD-Track thesis, 2024
(https://vitalik.ca/general/2021/01/05/rollup.html).
 Side Chain – Side Database – Lightning Protocol (2/3)

• Side database

– Not all data should be stored in a public blockchain

– Not all data should be stored in a blockchain

– Not all data can be stored in a blockchain (cf. bandwidth issues)

– Associate a blockchain and a database

– A typical example: store proofs of ownership in the blockchain and data in the database
 Side Chain – Side Database – Lightning Protocol (3/3)
• Lightning Protocol/Network (2016)
– On top of a blockchain
– "Layer 2" payment protocol
– P2P micro-payments
– Funding transaction on the level-1 blockchain (a kind of multi-signed money deposit transaction)
– Network of bidirectional payment channels
– Requires fixing transaction malleability e.g., through SegWits
– Micro-payment transactions (commitment transactions) are not broadcast to the level-1 chain
– The last commitment transaction/final distribution of funds is pushed on to the level-1 blockchain
– Dispute resolution protocol and penalty enforcement in case of misbehavior
– Pros
• Privacy
• Speed and throughput / Scalability
• Fees
– Cons
• Fraud deterrence => constant monitoring of the blockchain
• Complexity of the Lightning network
– https://lightning.network/lightning-network-paper.pdf
 Smart Contracts (1/2)

• See Ethereum (Vitalik Buterin, 2013-2015) ; Ethereum [white, yellow] paper:

https://ethereum.org/en/whitepaper/ and https://ethereum.github.io/yellowpaper/paper.pdf

• Smart contracts are pieces of code, which are (permanently) stored on the blockchain and
executed by the miners

• Ethereum contract = Ethereum Virtual Machine (EVM) bytecode

• From basic contract programming language (cf. Bitcoin) to Turing-complete languages e.g.,
Solidity (Ethereum)

• Business model based on incentives for the miners to execute the contracts e.g., Ethereum
gas
 Smart Contracts (2/2)
• Smart contracts are automatically triggered by transactions or messages (function calls, which allow data objects
exchanges across the network) received from other contracts or EOAs (Externally Owned Account i.e., normal
Ethereum address)

• Contract executions are redundantly replicated across nodes ⇒ expensive

• Network consensus => no more need for a Trusted Third Party

• No one can actually violate the contract: the violation of a contract requires subverting the entire network

• A blockchain is a “closed universe” => need for specific (trusted!) mechanisms to use external data (e.g., a
currency rate)

• Allows for secure Peer-to-Peer agreements that live on the blockchain forever

• Smart contracts definitely propose huge innovation opportunities and change our understanding of digital
ecosystems

• See Omar Hasan’s 5IF OT4 resources on INSA Moodle site: https://moodle.insa-lyon.fr/course/view.php?id=5992
From Permissionless to Permissioned
Blockchains
 2 Types of Blockchain

• Permissionless blockchain: open, no trusted third party. Ex: Bitcoin,

Ethereum

• Permissioned blockchain: control, some kind of trust. Ex: Hyperledger and its
family
 A few words about Hyperledger Fabric
• B2B orientation
• "Hyperledger Fabric is a platform for distributed ledger solutions underpinned by
a modular architecture delivering high degrees of confidentiality, resiliency,
flexibility and scalability. It is designed to support pluggable implementations of
different components and accommodate the complexity and intricacies that exist
across the economic ecosystem” (Hyperledger tutorial)”
• Shared distributed ledger, smart contracts, consensus
• Identity management/membership service/ACL, privacy/confidentiality
• Modular architecture: client, peer, endorser, orderer
• Transaction flow:
https://hyperledger-fabric.readthedocs.io/en/release-1.3/txflow.html
Integrating a blockchain
in a digital ecosystem
 Properties of the Blockchain

• No trusted third party (public blockchain)

• P2P network => no single point of failure / availability / reliability
• Data immutability => integrity, traceability, non-repudiability, security
• Contracts
• Open source
• Anonymity? It depends
• Cost effectiveness ? It depends
• Efficiency and Scalability ? It depends
 Usage: Illustration with some of our Projects

• Data marketplace and Traceability

• Reputation, Trust, Identity and Access Control
• Vote
• Fraud Detection
• Service Monitoring
• Micro credit lending
• Student transcripts and diploma
• Computing resource (“cloud”) marketplace
• Web 3
• Financial services
• …
Yet Another Buzzword or a
Paradigm Change?

Well, the revenue of D-Apps is forecast at 300-400 bn per year in 2027 (BBVA, Dec. 2022)
Some pictures

From UN University report: The Hidden Environmental Damages of

Cryptocurrencies, 2023
 Some figures

• https://www.blockchain.com/fr/charts
• https://bitinfocharts.com/bitcoin/
 Some figures (March 8, 2024)

• Cambridge Bitcoin Electricity Consumption Index (CBECI)

– Bitcoin's current estimated annual electricity consumption* (TWh): 168,8 TWh (estimation: between 84 and
434 TWh)  106,4 (51-177 one year ago)
 125,1 (49-292 2 years ago)
– (but “only” 82 TWh (in 2021) according to Coinshares Research = 0.05% of the total energy consumed))
– 0,76% of total electricity production
– 0,26% of total energy consumption
– ~annual electricity consumption Egypt of Poland
– 38% of France annual electricity consumption (447 TWh) (digiconomist.net: 18%)
– 2,2% of China annual electricity consumption
– 84% of the annual consumption of all data centers  53% last year
– 38 years of all the power used by tea kettles to boil water in the UK  24 years last year

– https://ccaf.io/cbnsi/cbeci/
 Some figures (March 8, 2024)

• Greenhouse gas emissions

– CBECI, Jan. 22: 85 MtCO2e??? (best case : 3,5 ; worst case 169)
– Some argue Bitcoin mining could support renewable electricity sources (e.g., by balancing energy supply and
demand (reduction of the electricity curtailment)…

• Environmental impacts
– See UN report:
https://inweh.unu.edu/wp-content/uploads/2023/10/Bitcoins-Environmental-Footprint-UNU-INWEH-2023.pdf
– Transparency
– Regulations
– Further studies
Some figures (March 8, 2024)
Some figures (March 8, 2024)
 Some figures (March 8, 2024)

• BTC Mining Countries

Old figures
 Some figures (February 6, 2023)
• Total bitcoins in circulation: 19,282,327
• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ $23,040  $45,430 one year ago, $67547 11/9/21, $9604 three
years ago!!!

• Bitcoin capitalization: $441,273,388,559  ~1260 billions USD 11/9/2021

• Nb of transactions per hour: 10,845. Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak
56,000 trans./s!
• Average transaction value: 1.03 BTC (2.93 BTC one year ago) ($23,627); median transaction value: 0.013 BTC ($289)

• 100 Largest Transactions last 24h: 111,400 BTC ($ 2,549,382,405), 41,45% Total (one year ago: 3,007,108 BTC
(68,307,428,599 USD) 252.64% Total)

• Median transaction fees: 0.000025 BTC ($0.568) (one year ago0.000016 BTC ($0.738)) – Average transaction fees:
0.000056 BTC ($1.28) 0.00000018 BTC/byte (one year ago: 0.000053 BTC ($2.41))

• Total blocks: 775,244

• Size of the Bitcoin blockchain: 518.12 GB
• Nb of blocks generated per day: ~145 (cf. 10mn per block; depends on the size of the transactions)
 Some figures (February 6, 2023)
• Hashrate: 301 exahashes (exa = 1018 = giga of giga, billions of billions)  196 one year ago,
110 two years ago!!!
→ Ethereum hashrate: from 1.3Phashes/s to 390 Mhashes/s (cf. The Merge, 9/15/22)

• Bitcoin mining profitability: 0.0668 USD/Day for 1 THash/s (reward per block:6.25+0.1045 BTC
($145,421.82)  0.2104 one year ago
• Miner revenue: ~20M USD per day  40 one year ago
• Wealth Distribution Top 10/100/1,000/10,000 addresses: 5.88% / 14.83% / 33.07% / 55.92% Total

• Active Addresses last 24h: 728,498

• Nb of orphan blocks generated per day: ~0-1 from June 2017 (last: 8/19; max 7 once in the history)

• The 4 more powerful mining pools concentrates 61% of the total computing power (biggest: 26%;
top-3:51.9%) (https://miningpools.com/bitcoin/)
 Some figures (February 6, 2023)
• Now figures become quite fuzzy…

• Cambridge Bitcoin Electricity Consumption Index (CBECI)

– Bitcoin's current estimated annual electricity consumption* (TWh): 106.4 TWh (estimation:
between 51 and 177 TWh)  125,1 (49-292 one year ago)
– (but “only” 82 TWh (in 2021) according to Coinshares Research = 0.05% of the total energy
consumed))
– 0,48% of total electricity production
– 0,16% of total energy consumption
– ~annual electricity consumption Philippines or Netherlands
– 24% of France annual electricity consumption (447 TWh) (digiconomist.net: 18%)
– 1,4% of China annual electricity consumption
– 53% of the annual consumption of all data centers  62% last year
– 24 years of all the power used by tea kettles to boil water in the UK
– https://ccaf.io/cbeci/index/comparisons
 Some figures (February 6, 2023)
• 22.4 petahashes per MW (Bitcoin Mining Council) - Actually, from 10 to 50 according to various sites

• More and more « green » electricity (~60%)

• https://coinshares.com/research/bitcoin-mining-network-2022 and
https://pd.coinshares.com/l/882933/2022-01-25/52bz1/882933/1643724699zWkQqOwT/COINSHARES_
BITCOIN_MINING_JAN22.pdf
– Bitcoin annual carbon footprint: 54 Mt CO2 (~Chile-Bahrain-Azerbaïdjan-Botswana)
– ~0.10% of the global annual emissions

• https://digiconomist.net/bitcoin-energy-consumption: annual Bticoin consumption: 86.3 TWh (vc

CBECI: 106.4 TWh). Bitcoin single transaction electricity consumption (kWh): 774 (~power consumption
of an average US household over 26 days… x3 in the last year!) ; carbon footprint ~957 VISA
transactions (remark: sources may be questioned)
• Ehereum consumption: https://digiconomist.net/ethereum-energy-consumption: from 94TWh to 0.02TWh

• https://bitinfocharts.com/bitcoin/ - https://www.blockchain.com/ - https://www.blockchainanalytics.pro/ -

https://btc.com/stats
Some figures (CBECI, February 6, 2023)

https://ccaf.io/cbeci/mining_map
Some figures (CBECI, February 6, 2023)

https://ccaf.io/cbeci/mining_map
Some figures (CBECI, February 6, 2023)

https://ccaf.io/cbeci/ghg/index
Some figures (CBECI, February 6, 2023)

https://ccaf.io/cbeci/ghg/index
 Some figures (February 6, 2023)

• Hash rate per country (https://worldpopulationreview.com/country-rankings/bitcoin-mining-by-country)

1. United States: 35.4%
2. Kazakhstan: 18.1%
3. Russia: 11.23%
4. Canada: 9.55%
5. Ireland: 4.68%
6. Malaysia: 4.58%
7. Germany: 4.48%
8. Iran: 3.1%

• Quite different from Cambridge’s figure before

 Some figures (February 10, 2022)
• Total bitcoins in circulation: 18,649,282
• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ $45,430  54343 USD on year ago, 9604 USD two years ago!!!
→ Today, Feb. 28th: $38,384 (-15%) !!!
• Bitcoin capitalization: $857,356,506,897  ~1000 billions USD one year ago

• Nb of transactions per hour: 10600. Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak
56,000 trans./s!
• Average transaction value: 2,93 BTC (1.61 BTC one year ago) ($132,352); median transaction value: 0.015 BTC ($664)

• 100 Largest Transactions last 24h: 3,007,108 BTC ($136,023,976,482), 404.12% Total (one year ago: 1,256,959 BTC
(68,307,428,599 USD) 252.64% Total)

• Median transaction fees: 0.000016 BTC ($0.738) (one year ago: 0.00014 BTC (7.34 USD)) – Average transaction fees:
0.000053 BTC ($2.41) 0.00000013 BTC/byte (one year ago: 1.61 BTC (87,512 USD)

• Total blocks: 722,654

• Size of the Bitcoin blockchain: 451.97 GB
• Nb of blocks generated per day: ~143 (cf. 10mn per block; depends on the size of the transactions)
 Some figures (February 10, 2022)

• Hashrate: 196 exahashes/s!!! (exa = 1018 = giga of giga, billions of billions)  110 two years
ago!!!
→ Ethereum hashrate ~1Phashes/s
• Bitcoin mining profitability: 0.2104 USD/Day for 1 THash/s (reward per block:6.25+0.1323 BTC
($288,699.77))

• Miner revenue: ~40M USD per day

• Nb of orphan blocks generated per day: ~0 from June 2017 (max 7 once in the history)

• The 4 more powerful mining pools concentrates 60% of the total computing power (biggest: 17%)

• Number of unique active addresses (in one day): 804,490

 Some figures (February 10, 2022)

• Cambridge Bitcoin Electricity Consumption Index (CBECI)

– Bitcoin's current estimated annual electricity consumption* (TWh): 125,1 TWh (estimation;
between 49 and 292 TWh)
– (but “only” 82 TWh (in 2021) according to Coinshares Research = 0.05% of the total energy
consumed))

– ~annual electricity consumption of Ukraine or Norway

– 29% of France annual electricity consumption
– 1,8% of China annual electricity consumption
– 62% of the annual consumption of all data centers
– 120% of the annual consumption of all US fridges
– 28 years of all the power used by tea kettles to boil water in the UK
– https://ccaf.io/cbeci/index/comparisons
 Some figures (February 10, 2022)
• 19.3 petahashes per MW (Bitcoin Mining Council)
• More and more « green » electricity (66%)
• https://coinshares.com/research/bitcoin-mining-network-2022 and
https://pd.coinshares.com/l/882933/2022-01-25/52bz1/882933/1643724699zWkQqOwT/COINSHARE
S_BITCOIN_MINING_JAN22.pdf
– Bitcoin annual carbon footprint: 39 Mt C02
– 0.08% of the global annual emissions (49,368 Mt CO2)
– Gold industry : 100-145 Mt CO2
– USA: 5830, China : 11580

• Bitcoin single transaction electricity consumption (kWh): 2106 (~power consumption of an average US
household over 72 days… x3 in the last year!)

• https://bitinfocharts.com/bitcoin/ - https://www.blockchain.com/ - https://www.blockchainanalytics.pro/ -

https://btc.com/stats
Some figures (February 10, 2022) (CBECI)
Some figures (February 10, 2022) (CBECI)

https://ccaf.io/cbeci/mining_map
Some figures (February 10, 2022) (CBECI)

https://ccaf.io/cbeci/mining_map
Some figures (February 10, 2022) (CBECI)

https://ccaf.io/cbeci/mining_map
Some figures (February 10, 2022)

https://coinshares.com/research/bitcoin-mining-network-2022
Some figures (February 10, 2022)

https://coinshares.com/research/bitcoin-mining-network-2022
 Some figures (March 9, 2021)
• Total bitcoins in circulation: 18,649,282
•
• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ 54343 USD  9604 USD one year ago!!!

• Bitcoin capitalization: 1,013,465,515,078 USD (more than 1000 billions USD)

• Nb of transactions per hour: 12,873. Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak 56,000 trans./s!

• Average transaction value: 1.61 BTC (87,512 USD); median transaction value: 0.017 BTC (925.55 USD)

• 100 Largest Transactions last 24h: 1,256,959 BTC (68,307,428,599 USD) 252.64% Total

• Median transaction fees: 0.00014 BTC (7.34 USD) – Average transaction fees: 1.61 BTC (87,512 USD)

• Total blocks: 673,913

• Size of the Bitcoin blockchain: 386.24 GB

• Nb of blocks generated per day: ~145 (cf. 10mn per block; depends on the size of the transactions)
 Some figures (March 9, 2021)
• Hashrate: 160 exahashes/s!!! (exa = 1018 = giga of giga, billions of billions)  110 one year ago!!!

• Bitcoin mining profitability: 0.3434 USD/Day for 1 THash/s  0.1412 one year ago!!!

• Miner revenue: ~50M USD per day

• Nb of orphan blocks generated per day: ~0-4 (max 7 once in the history); actually 2 only in all 2019, 0 in 2020)

• The 5 more powerful mining pools concentrates (over one year) 62.5% of the total computing power (biggest: 17,2%)

• Number of unique addresses (in one day): 950,073

• Bitcoin's current estimated annual electricity consumption* (TWh): 78,53 (estimation) (~Chile; ~16% France) or even 129,93
TWh according to Cambridge Bitcoin Electricity Consumption Index (CBECI) (~Ukraine, Sweden); carbon footprint: 37,3 Mt C02

• Bitcoin single transaction electricity consumption (kWh): 707 (~power consumption of an average US household over 24 days)

• https://bitinfocharts.com/bitcoin/ - https://www.blockchain.com/ - https://www.blockchainanalytics.pro/ - https://btc.com/stats

 Some figures (Feb. 25, 2020)
• Total bitcoins in circulation: 18,235,500
•
• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ 9604 USD  19343 USD in December, 16th, 2017

• Bitcoin capitalization: 175.2 billion USD

• Nb of transactions per hour: 14086. Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak
56,000 trans./s!

• Average transaction value: 2.54 BTC (24314 USD); median transaction value: 0.032 BTC (307 USD)

• Median transaction fees: 0.000033 BTC (0.313 USD); “cost” of a transaction: 53 USD;

• Total blocks: 618,917

• Size of the Bitcoin blockchain: 264.4 GB

• Nb of blocks generated per day: ~144 (cf. 10mn per block; depends on the size of the transactions)
 Some figures (Feb. 25, 2020)
• Hashrate: 110 exahashes/s!!!

• Bitcoin mining profitability: 0.1412 USD/Day for 1 THash/s

• Nb of orphan blocks generated per day: ~0-4 (max 7 once in the history); actually 0 since mid 2017)

• Computing power: 48.1 exahashes/s!!! – ~1400 millions of PFLOPS (#1 top500 supercomputer: 200 PFLOPS (Rpeak)-
143PFLOPS (Rmax)); sum of top500: 1600PFLOPS (Rmax))!!!!! (i7~: a few tens to hundreds of GFLOPS) (use of ASICS)

• The 5 more powerful mining pools concentrates 78.5% of the total computing power (the first 3 represent more than 50%)

• Number of unique addresses (in one day): ~500,000 - ~750000

• Bitcoin's current estimated annual electricity consumption* (TWh): 57.4 (estimation) (~CZech Rep.)

• https://bitinfocharts.com/bitcoin/ - https://www.blockchain.com/ - https://www.blockchainanalytics.pro/

 Some figures (Feb. 14, 2019)
• Total bitcoins in circulation: 17,538,179
•
• Total bitcoins to be ever produced: 21,000,000

• Exchange rate : 1 BTC~ 3613USD  19343 USD in December, 16th, 2017

• Bitcoin capitalization: 63.1 billion USD

• Nb of transactions per hour: 15333. Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak
56,000 trans./s!

• Average transaction value: 7.87 BTC (28293 USD); median transaction value: 0.047 BTC (167 USD)

• Median transaction fees: 0.000052 BTC (0.186 USD)

• Total blocks: 563,061

• Size of the Bitcoin blockchain: 238 GB

• Nb of blocks generated per day: ~149 (cf. 10mn per block)

 Some figures (Feb. 14, 2019)
• Hashrate: 48.144 exahashes/s!!!

• Bitcoin mining profitability: 0.1412 USD/Day for 1 THash/s

• Nb of orphan blocks generated per day: : 0-4

• Computing power: 48.1 exahashes/s!!! – 620 millions of PFLOPS (#1 top500 supercomputer: 200 PFLOPS (Rpeak)-
143PFLOPS (Rmax)); sum of top500: 1400PFLOPS (Rmax))!!!!! (i7~: a few tens to hundreds of GFLOPS) (use of ASICS)

• The 5 more powerful mining pools concentrates 72.6% of the total computing power (the first 3 represent more than 50%)

• Number of unique addresses (in one day): 500,000 – 1,000,000

• Bitcoin's current estimated annual electricity consumption* (TWh): 50 (~Singapore?) (peak: 73 TWh, end ’18; Austria?))

• https://bitinfocharts.com/bitcoin/ - https://www.blockchain.com/
 Some figures (Feb. 6, 2018)
• Total bitcoins in circulation: 16,200,950
• Total bitcoins to be ever produced: 21,000,000
• Exchange rate : 1 BTC~ 7700 USD  19343 USD in December, 16th, 2017
• Bitcoin capitalization: 129,5 billion USD
• Nb of transactions per hour: 9893. Note: max speed: 7 transactions per seconds; VISA : average 2000
trans./s, peak 56,000 trans./s!
• Total blocks: 508,011
• Size of the Bitcoin blockchain: 115 GB
• Nb of blocks generated per day: ~144 (cf. 10mn per block)
• Nb of orphan blocks generated per day: : 0-4
• Computing power: 23.9 exahashes/s!!! – 307,470,045 PFLOPS (#1 top500 supercomputer: 125 PFLOPS
(Rpeak)-93 PFLOPS (Rmax)); sum of top500: 845PFLOPS (Rmax))!!!!! (i7~: a few tens to hundreds of
GFLOPS) (use of ASICS)
• The 5 more powerful mining pools concentrates 76% of the total computing power (the first 3 represent more
than 50%)
• Number of unique addresses (in one day): 500,000 – 1,000,000
• Bitcoin's current estimated annual electricity consumption* (TWh): 47.42 (~Singapore?)
 Some figures (March 7, 2017 - Sept. 26, 2017)
• Total bitcoins in circulation: 16,200,950  16,587,125 in September, 26th, 2017
• Total bitcoins to be ever produced: 21,000,000
• Exchange rate : 1 BTC~ 1280 USD  3934 in September, 26th, 2017 !!!
• Bitcoin capitalization: 20,7 billion USD (19,6 billion €)  65,4 billion USD in September, 26th,
2017
• Nb of transactions per hour: 12140 (for 80,121 BTC). Note: max speed: 7 transactions per
seconds; VISA : average 2000 trans./s, peak 56,000 trans./s!
• Total blocks: 456,075  487,093 in September, 26th, 2017
• Size of the Bitcoin blockchain: 105 GB  134 GB in September, 26th, 2017
• Nb of blocks generated per day: 144
• Nb of orphan blocks generated per day: 0-4
• Computing power: 3.3 exahashes/s – 42,454,023 PFLOPS (#1 top500 supercomputer: 125
PFLOPS (Rpeak)-93 PFLOPS (Rmax)); sum of top500: 672PFLOPS (Rmax))!!!!! (i7~: a few tens
to hundreds of GFLOPS) (use of ASICS)
• The 5 more powerful mining pools concentrates 55% of the total computing power
• Number of unique addresses: 500,000+
 Conclusion: Why Using Permissionless Blockchains?
• Some nice properties

– No trusted third party, no single point of failure

– Reliability and immutability (very high replication factor)

– (eventual) Consistency

– Non-repudiability

– Existing infrastructure

– Open infrastructure

– Contracts
 Conclusion: Why Using Permissionless Blockchains?
• Some issues

– Security (in the ecosystem more than in the Bitcoin protocol itself)

– Total transparency; no real anonymity

– Hard consensus

– High latency, low throughput, poor transactional scalability (cf. huge computing power for only 12140
transactions per day!)

– Waste of resources and energy due to a huge replication factor and the solving of useless puzzles

– Immutability (cf. GDPR – personal data)

– PoW vs Proof of Stake vs Proof of something else

 Conclusion: Why Using Permissioned Blockchains?
• Some nice properties remain
– No single point of failure
– Distributed workload
– Reliability and immutability (very high replication factor)
– Non-repudiability
– Scalable infrastructure
– Contracts

• Additional nice features

– Controlled and trust-based environment (security?)
– Modular architecture
– Various consensus protocols => high throughput possible

• But a loss of openness and the need for trusted parties

• Nice for B2B, less nice to large scale open applications

From Gartner, 2017
 Conclusion: Blockchain 1.0, 2.0, 3.0, 4.0
• Blockchain 1.0 • Blockchain 3.0
– Transactions – Integration of blockchain into IT ecosystems –
– Bitcoin interoperability
– Cryptocurrency – D-Apps
– Scalability, rapidity (thousands of transactions per
second) ; sharding
• Blockchain 2.0 – Sustainability (no more PoW)
– Smart contracts – Alternatives ledger technologies: DAG
– Smart property (Tangle/IOTA, hashgraph/Hedera)
– First D-Apps – Cardano, Solana, Algorand
– Front-end user interfaces
– Decentralized Autonomous Organizations
(DAO) / Corporations (DAC) • Blockchain 4.0?
– Ethereum – Integration into the full business and economy
– Web 3.0
– Decentralized metaverse (e.g., Decentraland,
Axie Infinity, Starl)
– Usability
– Innovation
 A Subjective Research Agenda
• Mining: PoW, PoS, PoR, BFT... for improving scalability, latency, and energy
consumption
• Consensus
• Privacy
• Security
• Provability; see e.g., Implementing the EVM in Cairo: A Software-Centric Approach to the Ethereum Virtual
Machine in a Provable Language Scalable storage, M. Saugier, 5IF PhD-Track’s PhH thesis
• Quantum resistance
• Useability
• Applications: fintechs, e-commerce, supply chain, IoT, healthcare, e-gov,
smart property, vote, NFT, metaverse, Web 3...
• …