1. Blockchain & Bitcoin Notions fondamentales Lionel Brunie, Youakim Badr, Omar Hasan Institut National des Sciences Appliquées de Lyon

2. Outils de base (1/2) Fonction de hachage cryptographique
Associe à un objet numérique de taille variable, une chaîne de caractères de taille fixe (appelée résidu, empreinte, hash...)
Sens unique
Calcul du hash rapide (répétitions d’ additions, décalages, rotation, XOR, ^, etc.)
Calcul inverse extrêmement difficile
Probabilité très faible d’obtenir le même hash avec deux données d’entrée différentes (collision)
Petite modification de la donnée d’entrée => modification aléatoire du hash
Hashes différents => données d’entrée différentes avec une quasi-certitude
Utilisations
Intégrité : hash non modifié => donnée non modifiée avec une quasi-certitude
Masquage d’information, propriété et authenticité (log) : stocker le hash d’une donnée permet de masquer le contenu de celle-ci et de minimiser l’espace de stockage ; cependant, le propriétaire de la donnée d’entrée peut, en dévoilant celle-ci, en restituer le contenu dont l’authenticité est garantie par le hash

3. Outils de base (2/2) Chiffrement asymétrique
Deux clefs associées : clef publique / clef privée
Clef publique... publique (affichée à la vue/connue de tous) !
Clef secrète... secrète (conservée par devers soi et transmise à personne)
Quasiment impossible de déduire l’une des clefs à partir de l’autre
Chiffrement avec une clef, déchiffrement avec l’autre clef
Utilisations
Confidentialité : chiffrer avec la clef publique du destinataire
Authentification : chiffrer avec la clef privée de l’émetteur

4. Un exemple de blockchain publique : Bitcoin

5. What is Bitcoin?
“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 block chain. 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:

6. Bitcoin Address
Seminal paper: “Bitcoin: A Peer-to-Peer Electronic Cash System”, by Satoshi Nakamoto, Oct. 2008
Bitcoin manages transactions (i.e., flows) of « coins »
A coin « belongs » to an address
An address is the 160-bit hash of the SHA256 hash of thepublic key of a public/private ECDSA keypair (RIPEMD160(SHA256(ECDSA_publicKey)))
Bitcoin allows one to create as many addresses as one wants, and use a new one for every transaction => notion of wallet

7. Private Key, Public Key, and Bitcoin Address

8. Conversion of a Public Key into a Bitcoin Address
A candidate format: Bech32

9. 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

10. 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

11. Transaction (Bitcoin)
Header, incl.
Nb of inputs
List of inputs
Nb of outputs
List of outputs
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)

12. Input – Output – Coin (1/2)
A coin is not identified using a fixed id
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)
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

13. Input – Output – Coin (2/2)
Input format
hash of the previous transaction from which the input was produced
index number referencing the specific output of this transaction
script length
script (used notably to check the ownership of the inputs)
sequence number (allows modifying the transaction before LockTime expires (may be disabled))
Output format
value : nb of satoshis (1 satoshi = 1/10^8 bitcoins)
script (includes the Bitcoin address of the recipient of the output (hash of its public key)

14. Examples of Transactions
From en.bitcoin.it

15. Example of Transaction

16. Scripts and Verification
Stack-based language (Forth-like)
Pay-to-Pubkey-Hash Transaction
script on the inputs (scriptSig): <sig> <pubKey>
script on the outputs (scriptPubKey): OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
the “owner” of a transaction input (coin) provides her public key (<pubKey>) + her signature of the transaction which created this coin (remember a coin is created as output of a transaction) (<sig>)
the combination of the scripts 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
Pay-to-Script-Hash Transaction
allows sending coins to a script hash instead of a public key hash
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”

17. Example of Script Execution
From Judmayer and al.

18. 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)
Usually, one places less than 40 Bytes after OP_RETURN
Used to create “colored” coins

19. 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 use to store information (“fake” address of a 1 of 2 signature)

20. 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”)

21. 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 in the block (hash) (32 Bytes)
Timestamp (uint32) (4 Bytes)
nBits: Difficulty to solve the block (uint32) (4 Bytes)
Nonce result of the puzzle (cf. mining) (uint32) (4 Bytes)

22. Merkle Tree Efficiency: O(log(n))
Integrity Control: if the content of a transaction is altered, the Merkle root changes
From Wikipedia

23. Example of Block
From Blockchain.info

24. 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. Note: 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 (usually stored in a separate database for indexing and retrieval purposes)
Blocks are chained (ordered)
Note: a block can also be identified by its height (in case of a “fork”, 2 blocks may have the same height in two different branches)
“Full nodes” maintain a local copy of the entire blockchain
Initial block: the “Genesis Block”

25. Mining Blocks and Consensus Protocol (1/3)
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)
Miners role: check the transactions, collect transactions to create blocks, chain blocks
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 blocks (~4 years). It’s now 12,5 bitcoins
Transactions may (actually should) include “transaction fees” that are given to the miner
Mining is the only way to create coins
Mining pools

26. Mining Blocks and Consensus Protocol (2/3
Need for reliability and consensus!
No trusted third party => who/howto decide on the content of the blockchain?
Concurrent/Asynchronous computing => possibility of different “visions”/versions
Possibility of abuses e.g., DoS, spam, etc.
Deterring abuses in Bitcoin: Proof of work (PoW)
PoW = piece of data hard to produce but whose validity can be easily verified
Objective: make abuse costly and difficult
Bitcoin PoW: find a value (nonce) 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 each miner mines a “personalized” block, each miner solves a different puzzle
Unpredictability 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

27. Mining Blocks and Consensus Protocol (3/3)
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
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

28. Network Node Types and Roles

29. Side Chain – Side Database
Separate blockchain linked to the parent blockchain (e.g., Bitcoin) through a currency exchange protocol fixed exchange rate)
Unload Bitcoin with specific transactions
Use verification protocols and business logic specific to the application supported by the side chain
May be private/controlled
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

30. Another Example of Public Blockchain – A Focus on Smart Contract Ethereum

31. What is Ethereum? Terminology
A blockchain is a fully-distributed, peer-to-peer software network which makes use of cryptography to securely host applications, store data, and easily transfer digital instruments of value that represent real-world money.
Currency refers to a fungible unit of value for the system, much like a token, or scrip.
“Ethereum” can be used refer to three distinct things:
the Ethereum protocol,
the Ethereum network created by computers using the protocol, and
the Ethereum project funding development of the aforementioned two.
High-level Overview
Ethereum is a decentralized platform designed to run smart contracts.
No single point of control/failure, censorship resistant
Account-based blockchain
Distributed state machine
(block of) transactions == state transition function
Has a native asset called ether (basis of value in the Ethereum ecosystem)

32. What Ethereum Does A stateful system The programming languages
The key component is this idea of a Turing-complete blockchain. ... As a data structure, it works kind of the same way that Bitcoin works, except the difference in Ethereum is, it has this built-in programming language.
—Vitalik Buterin, inventor of Ethereum 1
A stateful system
Smart contract
The programming languages
Turing completeness
Ensuing control flow
EX: Solidity, …
The Ehereum protocol2
A trustful global object framework messaging system
Reading
1 YouTube, “Technologies That Will Decentralize the World,” er-k3ehpFaM&feature=share, 2016.
2 GitHub, “Ethereum White Paper,”

33. Ethereum vs. Bitcoin Ethereum: Smart Contract Platform
Complex and feature-rich
Turing complete scripting language
significantly more powerful than Bitcoin Script.
enables smart contracts.
Account-based instead of UTXO-based
Bitcoin: Decentralized Asset
Simple and robust
Simple stack-based language; not Turing complete
The Ether asset is not primary goal
almost side effect of incentive-aligned smart contract platform.
Ethereum plans to move to Proof-of-Stake in the near future
Bitcoin likely remains Proof-of-Work

34. Ethereum vs. Bitcoin Misc. Implementation Details
Block creation time: (~12 sec vs ~10 min)
Proof-of-Work: (Ethash vs Sha256)
Ethash is (currently) ASIC resistant

35. Accounts vs. UTXOS Recall:
A Bitcoin user’s available balance is the sum of unspent transaction outputs for which they own the private keys to the output addresses.
Instead Ethereum uses a different concept, called Accounts.
Account:
Address
Balance
(optional) code

36. Ethereum Account Types
Externally Owned Accounts (EOAs):
Generally owned by some external entity, e.g., person, corporation, etc...
Address
Ether balance
Can send transactions
transfer ether to other accounts, trigger contract code
Contract Accounts (Contracts):
Has associated contract code
Code execution is triggered by transactions or messages (function calls) received from other contracts or EOAs.
Contracts have persistent storage
Accounts Rationale
Space Savings: Nodes only need to update each account’s balance instead of storing every UTXO
More Intuitive : smart contracts are more easier to program when transferring between accounts with a balance
See: Mist wallet

37. EthereumTransactions

38. What Is a Smart Contract?
(noun) /ˈkäntrakt/
1. a written or spoken agreement ... that is intended to be enforceable by law.
smart con·tract
(noun) /smärt ˈkäntrakt/
1. code that facilitates, verifies, or enforces the negotiation or execution of a digital contract.
a. Trusted entity must run this code

39. What Is a Smart Contract?
In Ethereum, smart contracts are executed by the network itself
Network consensus removes need for Trusted Third Party
No one can violate the contract
No trusted entity to fudge contract execution
Violation of contracts requires subverting the entire network
Allows for secure Peer-to-Peer agreements that live on the blockchain forever
Contracts in Ethereum are like autonomous agents that live inside of Ethereum network
React to external world when "poked" by transactions (which call functions)
Have direct control over:
internal ether balance
internal contract state
permanent storage

40. What Smart Contracts (Really) Do
Courtesy of : Philip Hayes Max Fang (Blockchain at Berkely)

41. Smart contracts are often equated to software applications
A smart contract is similar to a class
Attributes (states)
Functions
Authentication
Send / receive Ether
Events (logs)

42. EVM The EVM (Ethereum Virtual Machine) runs contract code.
Contract code that actually gets executed on every node is EVM code
EVM code is a low-level, stack-based bytecode language.
Kind of like JVM's bytecode
Every Ethereum node runs the EVM as part of its block verification procedure.
EVM as a state transition mechanism:
(block_state, gas, memory, transaction, message, code, stack, pc)
where block_state is the global state containing all accounts
includes balances and long-term storage

43. What are Virtual Machines, Actually?
The Ethereum Virtual Machine (EVM) is a worldwide computer that anyone can use, for a small fee, payable in ether
Deterministic
Turing complete
Global singleton machine
EVM Applications Are Called Smart Contracts
The EVM Runs Bytecode

44. How the EVM can be programmed ?
Executes programs (same as smart phones)
 Consumes gas (fees paid in Ether ) for each operation (anti DoS, avoid infinite loops)
Manages global variable (gasPrice, blockNumber, timestamp..)
Waits for inputs (transactions) to modifier its variable (states).
 Kind of a database

45. Compiling

46. EVM Gas and Fees Immediate Issue:
What if our contract has an infinite loop?
Every node on the network will get stuck executing the loop forever!
By the halting problem, it is impossible to determine ahead of time whether the contract will ever terminate
⇒ Denial of Service Attack!

47. EVM Gas and Fees
Ethereum’s Solution:
Every contract requires “gas”, which “fuels” contract execution.
Every EVM op-code requires some gas in order to execute.
Every transaction specifies
the startgas , or the maximum quantity of gas it is willing to consume
the gasprice , or the fee in ether it is willing to pay per unit gas.
At the start of the transaction
startgas * gasprice ether are subtracted from the sender’s account.
If the contract successfully executes
the remaining gas is refunded to the sender.
If the contract execution runs out of gas before it finishes
then execution reverts
startgas * gasprice are not refunded.
What about the infinite loop?
Ethereum still allows the infinite loop
However, the attacker attempting to DoS the network has to pay enough ether to fund the DoS
Think of purchasing gas as purchasing distributed, trustless computational power.

48. Estimating Gas Fees for Operations
The costs of some common EVM operations

49. Mining’s Place in the State Transition Function
For each transaction in a block, the EVM (state transition function) performs the following:
Check whether the transaction is in the right format. Does it have the right number of values? Is the signature valid? Does the nonce—a transaction counter—on the transaction match the nonce on the account? If any of these are missing, return an error.
Calculate the transaction fee by multiplying the amount of work required (represented by STARTGAS) by the gas price. Then deduct the fee from the user’s account balance, and increment the sender’s nonce (transaction counter). If there’s not enough ether in the account, return an error.
Initialize the gas payment; from this point forward, take off a certain amount of gas per byte processed in the transaction.
Transfer the value of the transaction—the amount being sent—to the receiving account. If the receiving account doesn’t exist yet, it will be created. (Offline Ethereum nodes can generate addresses, so the network may not hear of a given address until a transaction takes place.). If the receiving address is a contract address, run the contract’s code. This continues either until the code finishes executing or the gas payment runs out.
If the sending account doesn’t have enough ether to complete the transaction, or the gas runs out, all changes from this transaction are rolled back. A caveat are the fees, which still go to the miner and are not refunded.
If the transaction throws an error for any other reason, refund the gas to the sender and send any fees associated with gas used to the miner.
Reading
Ethereum White Paper, “Ethereum State Transition Function” wiki/wiki/White-Paper#ethereum-state-transition-function,

50. Basic Use Case: SMART ASSETS
A token system is very easy to implement in Ethereum Database with one operation
Ensure Alice has enough money and that she initiated the transaction
Subtract X from Alice, give X to Bob
Example (from Ethereum white paper):*

51. Basic Use Case: Public Registry / Public Database
Example: Namecoin
DNS system
Maps domain name to IP address
"maxfa.ng" => " "
Immutable
Easy implementation in Ethereum
Example (from Ethereum white paper)

52. Ethereum Objectives
Ethereum is not about optimizing efficiency of computation
Its parallel processing is redundantly parallel
efficient way to reach consensus on the system state without needing trusted third parties.
Contract executions are redundantly replicated across nodes
 ⇒ expensive
creates an incentive not to use the blockchain for computation that can be done off chain.

53. What Ethereum Is Good For
“Without any possibility of downtime, censorship, or third-party interference”
“A secure, free, and open platform for the Internet of Things”
“Enabling transparent governance for communities and businesses”
“Handles user authentication and secure payments for you, as well as messaging and even decentralized storage”
“No need to sign up or pay for application host; the world’s first zero-infrastructure platform”
Reading
1 Ethereum Blog, “The Business Imperative Behind the Ethereum Vision,”
Ethereum.org/2015/05/24/the-business-imperative-behind-the-Ethereum-vision/, 2015.

54. What You Can Build Today
Private and Public Chains
Send and Receive Ether
Write Smart Contracts
Create Provably Fair Applications
Launch Your Own Token

55. Ethereum Vision of the Blockchain
Transactions
denote state changes in the distributed database (blockchain)
change account balances within the EVM
Messages
Data objects exchanges across the network between smart contracts
Blocks
Refer to a unit of time that encompasses a certain number of transactions
Blockchain
The blocks on the blockchain represent units of time; the blockchain itself is a temporal dimension and represents the entire history of states at the discrete time points designated by the blocks on the chain.3
Gas
a tiny fee to process a transaction

56. Solidity programming
High-level contract-oriented language with similarities to JavaScript and C languages
The Promise of Solidity
Develop smart contracts and compile them to EVM bytecode
Create a complementary currency
Browser-based compiler
Easy Development
Ethereum Dapps
“Hybrid” Ethereum Dapps
Cases for Business Logic in Solidity :
rewards programs, membership clubs, and large retail districts,

57. Solidity programming Can mark functions internal
Syntax looks like JavaScript
Contracts look like classes/objects
Can mark functions internal
Static typing
Most types can be cast e.g. bool(x)
supports inheritance, libraries, and complex user- defined types
Write inline assembly code
assembly {...}
Fully deterministic
Testing with Ropsten testnet

58. PiggyBank.sol
Naming conventions:
Solidity file structures, see

59. Solidity in Depth Layout of a Solidity Source File
Version Pragma
Importing other Source Files
Comments
Structure of a Contract
State Variables
Functions
Function Modifiers
Events
Structs Types
Enum Types
Types
Value Types
Reference Types
Mappings
Operators Involving LValues
Conversions between Elementary Types
Type Deduction
Units and Globally Available Variables
Ether Units
Time Units
Special Variables and Functions
Expressions and Control Structures
Input Parameters and Output Parameters
Control Structures
Function Calls
Creating Contracts via new
Order of Evaluation of Expressions
Assignment
Scoping and Declarations
Error handling: Assert, Require, Revert and Exceptions
Check this:

60. Solidity in Depth Contracts Solidity Assembly Miscellaneous
Creating Contracts
Visibility and Getters
Function Modifiers
Constant State Variables
View Functions
Pure Functions
Fallback Function
Events
Inheritance
Abstract Contracts
Interfaces
Libraries
Using For
Solidity Assembly
Inline Assembly
Standalone Assembly
Miscellaneous
Layout of State Variables in Storage
Layout in Memory
Layout of Call Data
Internals - Cleaning Up Variables
Internals - The Optimizer
Source Mappings
Tips and Tricks
Cheatsheet
Check this:

61. Functions
see the following URL: solidity.readthedocs.io/en/develop/units-and-global- variables.html#mathematical-and-cryptographic-functions.
Public functions: Visible externally and internally (an accessor function for storage/state variables is created)
Private functions: Visible only in the current contract (default)
Use semicolons to chain statements
function first(); function second()
Mathematical and cryptographic functions (Global Functions)
keccak256(...) returns (bytes32): Computes the Ethereum- SHA-3 (Keccak-256) hash
sha3(...) returns (bytes32): An alias to keccak256()
sha256(...) returns (bytes32): Computes the SHA-256 hash of the (tightly packed) arg.
ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address): recovers address associated with the public key from elliptic curve signature, returns 0 on error
addmod(uint x, uint y, uint k) returns (uint): Computes (x + y) % k, where the addition is performed with arbitrary precision and does not wrap around at 2**256
mulmod(uint x, uint y, uint k) returns (uint): Computes (x * y) % k, where the multiplication is performed with arbitrary precision and does not wrap around at 2**256
this (current contract's type): The current contract, explicitly convertible to its address

62. From Permissionless to Permissioned Blockchains

63. 2 Types of Blockchain
Permissionless blockchain: open, no trusted third party. Ex: Bitcoin, Ethereum
Permisioned blockchain: control, some kind of trust. Ex: Hyperledger and its family

64. 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, endorsers, orderer
Transaction flow:

65. 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: (for 80,121 BTC). Note: max speed: 7 transactions per seconds; VISA : average 2000 trans./s, peak 56,000 trans./s!
Total blocks: 456,  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+

66. 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  USD in December, 16th, 2017
Bitcoin capitalization: 129,5 billion USD
Nb of transactions per hour: 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): (~Singapore?)

68. 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
Some issues
Security (in the ecosystem more than in the Bitcoin protocol itself)
Total transparency; no real anonymity
Hard consensus
Low latency, low throughput, poor transactional scalability (cf. huge computing power for only 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

69. 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