EmmanuelleAnceaume …people.irisa.fr/Emmanuelle.Anceaume/Bitcoin-keynote.pdf · 5 Publicledgers...

Emmanuelle Anceaume

Blockchain Technology and the Bitcoin Cryptocurrency

http://people.irisa.fr/Emmanuelle.Anceaume/

Content of this lesson

I Crypto backgroundI hash functionsI digital signaturesI hash pointersI Merkle trees

I Bitcoin principlesI Peer-to-peer networksI TransactionsI Blocks

I Agreement protocolsI Leader electionI « Nakamoto Consensus »

2008 : The Bitcoin white paper

An overview of Bitcoin

I Bitcoin is a cryptocurrencyand payment system

I It allows users toanonymously exchangegoods against digitalcurrency

I All the valid transactions arerecorded in a public ledger,the blockchain

I Allows anyone to auditand check the integrity ofall the transactions

Bob -> Alice ฿0.001 Chunk -> Sara ฿0.05Eva -> Alice ฿0.009Alice -> John ฿0.02Bob -> Chunk ฿0.7

Peter -> Bob ฿0.008Bob -> Alice ฿0.05

Bob -> Alice ฿0.046Bob -> Alice ฿0.008

Ledger

Public ledgers

No trustworthy centralized control.Everyone

I maintains its own copy of the ledgerI disseminates all the transactionsI can read all the transactions

Bob -> Alice ฿0.001 Chunk -> Sara ฿0.05Eva -> Alice ฿0.009Alice -> John ฿0.02Bob -> Chunk ฿0.7Peter -> Bob ฿0.008Bob -> Alice ฿0.05

Ledger

Ledger Bob -> Alice ฿0.001 Chunk -> Sara ฿0.05Eva -> Alice ฿0.009Alice -> John ฿0.02Bob -> Chunk ฿0.7Peter -> Bob ฿0.008Bob -> Alice ฿0.05

Ledger

AchievingI consistency, efficiency and availability of the ledgerI auditability, immutability of the transactions

While preventingI transaction censorchip and double-spending attacks

Basic principlesI Crypto currency

I relies on cryptographic toolsI Decentralized system

I peer-to-peer architectureI Trustless model

I does not require a central server to validate/abort financialtransactions but requires participants to be online

I Anonymous usersI neither sellers nor buyers use their real identities to use

Bitcoins but if you are not careful your transactions can be tiedtogether

Satoshi Nakamoto. Bitcoin : APeer-to-Peer Electroni Cash System.October 2008,http ://nakamotoinstitute.org/bitcoin/

Bitcoin relies on a set of distributed algorithms

Bitcoin:

Peer-to-Peer Network

• Dissemination of transactions and blocks in the open and large scale Bitcoin system

Cryptographic primitives

• Bitcoins are immutable• Hash functions• Digital signature

• Merkle tree

Mining & Incentive

• Approximate the selection of a leader randomly chosen• Proportional to a resource we hope nobody can monopolize

(denial of service)• proof of work using hash puzzle (moderately difficult to

compute, parametrizable cost, trivial to verify)• Regulate the creation of new bitcoins

Blockchain & Agreement

• No trusted entity in charge of validating transactions nor creating money

• Total and secure ordering of all the valid transactions ever created

• Append only data structure

Preliminaries on crypto

I cryptographic hash functionsI digital signaturesI Merkle tree

hash functions

All currencies need some way to control supply and preventcounterfeiting money

I Fiat currencies (Dollar, Euro, Yen, Yuan)I central banks mint physical currencyI integrity of bank notes is guaranteed by anti-counterfeiting

features to physical currencyI Digital currencies

I a string of « 0 » and « 1 »I no central bank to prevent double-spending attacksI heavy use of cryptography

Hash functions

A hash function is an algorithm that allows to compute afingerprint of fixed size from data of arbitrary size

H : 0, 1∗ → 0, 1n

M 7→ H(M)

I rather than manipulating data of arbitrary size, a fingerprint isassociated to each data which makes operation easier

Hash functionsA hash function satisfies the following properties

I The input space is the set of strings of arbitrarily lengthI « hello world » and « hellohellohello world » are perfectly fine

inputsI The output space is the set of strings of fixed length

I H(« hello world ») = 000223I H(« hellohellohello world ») = 130554

I H is deterministicI H is efficiently computable

I Given a string s of length n the complexity to compute H(s) isO(n)

In addition to these properties, crypto-hash functions haveadditional requirements

Properties of cryptographic hash functions

I Collision resistanceIt must be difficult to find two inputs x and x ′ such that

H(x) = H(x ′)

I Second pre-image resistanceGiven an input x , it must be difficult to find an input value

x ′ 6= x such that H(x ′) = H(x)

I Pre-image resistanceGiven z , it must be difficult to find an input value x such that

H(x) = z

Collision resistance

Find two inputs x and x ′ such that H(x) = H(x ′)

H(x)=H(y)

collisions do exist

possible inputspossible outputs

Image source: Bitcoin and Cryptocurrency Technologies.

collisions do exist

possible inputspossible outputs

but can anyone find them ?

Image source: Bitcoin and Cryptocurrency Technologies.

Collision resistance property

Generic attack (i.e., a technique capable of attacking any n-bithash function )

I Choose 2n/2 random messages (birthday paradox)I Compute the hashed values and store themI Find one pair (x,x’) such that H(x) = H(x ′)

Birthday paradoxBirthday paradox is about the probability that, in a set of mrandomly chosen people, some pair of them will have the samebirthday.

I if m = 23 the probability to have collision is 50%I if m = 70 then p is equal to 99.9%

Birthday paradoxLet us first compute the probability that no two persons have thesame birthday. Let p′(m) be this probability

p′(m) =365365

364365

. . .365− (m − 1)

(365−m)!

Thus the probability p(m) that there exists two persons having thesame birthday is

p(m) = 1− p′(m) = 1− 365!(365−m)!

' 1− e−m(m−1)2×365

m(p) '

√2× 365 ln(

11− p

Birthday paradox

m(p) '

√2× 365 ln(

11− p

we get

m(1/2) = 23

In our case, the set of possible values is equal to 2n with n thelength of the binary string of the fingerprintThus

m(1/2) '√2 ln 2 2n/2

' 2n/2

Collision resistance property

Generic attack (i.e., a technique capable of attacking any hashfunction)

I Choose 2n/2 random messagesI Compute the hashed values and store themI Find one pair (x , x ′) such that H(x) = H(x ′)

If a computer calculates 10, 000 hashes/sI it would take 1027 years to output 2128 hashes, andI thus 1027 years to produce a collision with probability 1/2

Astronomical number of computations ! !So far no hash functions have been proven to be collision resistant

Collision resistance propertyTo summarize :

Collision resistant hash functions allows usI to identify data by its hashed value (i.e digest, fingerprint)

I if H(x) = H(y) then it is safe to assume that x = y

I Bitcoin :I to identify blocks in the blockchainI to make blocks resistant to tampering (modifying a single bit

changes the fingerprint)

Second-preimage resistance

Given an input x , it is difficult to find an input value x ′ 6= x suchthat H(x ′) = H(x)

Generic Attack : probabilistic search

I Given x and its hashed value H(x) (n bits value)I Randomly choose xi and compute zi = H(xi )

I Proba(zi = H(x)) = 1/2n

I Thus after having chosen 2n inputs it is likely that one canfind a pre-image xi 6= x such that H(xi ) = H(x)

File integrity

file1 H( file1) = 3214 5670 ab67 0123 8760 2123 34BF 0A23

(256 bits)

Assume you have file 1

Is it possible to build another file, file 2, such that both files have the same fingerprint?

Preimage resistance

Given z , find an input value x such that H(x) = z

Generic Attack : probabilistic search

I Given a hashed value z

I Randomly choose xi and compute zi = H(xi )

I Proba(zi = z) = 1/2n

I Thus after having chosen 2n inputs it is likely that one canfind a pre-image xi such that H(xi ) = z

Passwords storage

I In your machine, passwords are not stored. Only their hashedvalue is stored

I When you want to authenticate, the login pg computes thehashed value, which is compared with the one stored in/etc/passwd

Property : Given the hashed value y it must be difficult to find xsuch that H(x) = H(password) = y

Merkle-Damgard construction

Hash pointers

A hash pointer is the cryptographic hash value of the pointedinformation

H(bloc)=6736a

info n

H(bloc)=1b781 H(bloc)=56ac3

Hash pointers

Hash pointers allows the construction of a log data structure thatallows the detection of any manipulation

H(bloc)=6736a

info n

Hash pointers

Hash pointers allows the construction of a log data structure thatallows the detection of any manipulations

H(bloc)=6736a

info n

Hash pointers

H(bloc)=6736a

info n

Hash pointers

H(bloc)=6736a

info n

3 By only keeping the hash pointer of the head of the datastructure, we have a tamper-evident hash of a possibly verylong list

Hash tree : Merkle Tree

A Merkle tree 1 is a tree of hashes

I Leaves of the tree are data blocksI Nodes are the hashes of their childrenI Root of tree is the fingerprint of the tree

1. Merkle, R. C. (1988). "A Digital Signature Based on a ConventionalEncryption Function". Advances in Cryptology - CRYPTO ’87.

h000 = h(b0) h001 = h(b1)

h00 = h( h000 || h001 )

h0 = h( h00 || h01 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h100 = h(b4) h101 = h(b5)

h10 = h( h100 || h101 )

h1 = h( h10 || h11 )

h110 = h(b6)

h11 = h( h110 || h110 )

h = h( h0 || h1 )

3 Checking the integrity of the n data blocks of the treeI easy due to collision resistance property of crypto. hash

functionsI Data blocks membership

I checked with log n pieces of information and in log n operations

h000 = h(b0) h001 = h(b1)

h00 = h( h000 || h001 )

h0 = h( h00 || h01 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h100 = h(b4) h101 = h(b5)

h10 = h( h100 || h101 )

h1 = h( h10 || h11 )

h110 = h(b6)

h11 = h( h110 || h110 )

h = h( h0 || h1 )

I know the root of the Merkle tree, and I would like to knowwhether data block b3 belongs to the tree ?

Question : How can I do that without looking for the full tree ?

h = h( h0 || h1 )

h011 = h(b3)

h = h( h0 || h1 )

h010 = h(b2) h011 = h(b3)

h = h( h0 || h1 )

h01 = h( h010 || h011 )

h00 = h( h000 || h001 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h00 = h( h000 || h001 )

h0 = h( h00 || h01 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h = h( h0 || h1 )

h00 = h( h000 || h001 )

h0 = h( h00 || h01 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h = h( h0 || h1 )

h1 = h( h10 || h11 )

h00 = h( h000 || h001 )

h0 = h( h00 || h01 )

h010 = h(b2) h011 = h(b3)

h01 = h( h010 || h011 )

h = h( h0 || h1 )

h1 = h( h10 || h11 )

I know the root of the Merkle tree, and I would like to knowwhether data block b3 belongs to the tree ?

Question : How can I do that without looking for the full tree ?

I need log n pieces of information and log n hash operations

Digital signature primitive

A digital signature is just like a signature on a document

I Only the creator of the document can sign, but anyone canverify it

I Signature is tied to a particular document

How can we build such a digital signature ?

Digital signatureThree functions :

I (sk ,pk) := generateKeys(keysize)I sk : private signing keyI pk : public verification key

I sig := sign(sk , H(message))I ver := verify(pk , sig)

Digital signatureRequirements :

I The verify operation must return true when fed with validsignatures

verify(pk , sign(sk , H(message)))=H(message)I The signature scheme is unforgeable

An adversary that knows pk and can choose any messages tobe signed cannot produce a verifiable signature for another

message

Digital signature

H(M) = 01011011

SIG(H(M),s_k)(M, sig)

Alice Bob

VER(p_k,sig) = ver

if (ver = H(M)) then sig is valid

Indeed: ver = VER(p_k, sig) = VER(p_k, SIG(H(M),s_k)) = H(M)

Digital signature

I The algorithms to generate keys and sign must have access toa good source of randomness

I Signing the hash of a message is as safe as signing themessage itself

In Bitcoin, the signature scheme is ECDSA (Elliptic Curve DigitalSignature Algorithm) 2

I private key = 256 bitsI Public key = 512 bitsI Message = 256 bitsI signature = 512 bits

2. Johnson, Don, Alfred Menezes, and Scott Vanstone. The elliptic curvedigital signature algorithm (ECDSA) . International Journal of InformationSecurity 1.1 (2001) : 36-63

Using verification public key as an identityIdea : use the verification key of a signature as an identity

I If you see a msg such that the signature verifies under pk (i.e.verify(pk , sig)= msg) then on can see pk as a party sayingstatements by signing them

I To speak on behalf of pk one must know skI So there is an identity in the system such that only a single

one can speak for it which is what we want for a signature

3 By looking at public keys as identities you can generate asmany identities as you want !

Using verification public key as an identity

I Create new identities :I Eric creates a new pair (sk ,pk)I pk is the public name Eric usesI Eric is the only person that can speak on behalf of pk because

he knows skI pk is sufficient ! nobody needs to know that Eric created it

I Creation of identities as often as you want !I no central authority in charge of registering new identities !I this is the way Bitcoin creates identities (called addresses)

I address = Hash(public key)

Using verification public key as an identitySome words on privacy

I no relationships between pk based identities and real identitiesI by using the same pk (identity) an adversary can infer some

relationships based on the activity of pk

Transaction

The state of the Bitcoin world is represented by transactions

I data structure that allows Alice to transfer bitcoins to Bob andCharly

I does not contain any confidential informationI verifiable by anyone → no trusted third-party !

I Alice’s account(input address)

I Bob’s and Charly’saccounts (outputaddress)

I possibly somechange

I transactions fees

Input #1

Output ref. + script

Input #2

Transaction

Output #1account + ฿

Transaction

An account is a « one shot object »

I an account is a <(private key,public key), amount of bitcoins>I debited once !I each time you are the recipient of a transaction, it’s safer if

you create a new account (privacy reasons)

Checking the ownership of an account

I how can anyone check that I am the legitimate owner of anaccount since there are no identities in a transaction ?

I using « public keys » as identities

Transaction

I Bitcoin relies on a (limited) script languageI to lock an output, the script provides a challenge

I i.e., fingerprint of the recipient public key, H(pk)I to unlock an input, the script provides the solution of the

challengeI i.e., public key pk together with sk ’s signature

Input #1

Input #2

Transaction

Script language

Input ----

Output OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Transaction T

Input <sig> <pubKey>

Output ----

Transaction T'

OP_DUP OP_HASH<pubKey>

pubHashA>

OP_EQUALVERIFY

OP_CHECKSIGif true empty

Relying on past transactions to create new ones

Transaction 20ab3701i

Transaction 74201ab3c

UTXO = Unspent Transaction Output

Output #2account + ฿ + script

Input #1

Transaction 1206ac34e

Input #1

Input #2

Input #1

Input #2

Do not forget Tx fees, i.e., ฿ input > ฿ output

I Topology formed through a randomized processI No coordinating entityI Broadcast is based on flooding/gossiping neighbors’ link

Tx d->e

Tx a->B

Tx a->B Tx a->B

Tx a->B

Tx d->e

Tx a->B

Tx d->e

Tx a->B

Tx a->BTx d->e

transactiontransactiontransactiontransactiontransaction

transactiontransactiontransactiontransaction

transactiontransactiontransactiontransactiontransactiontransaction

bag of transactions

node of the network

Internet

Resistance to « double-spending attacks »

bag of transactions

node of the network

Internet

Required properties

1. ConnectivityI Each node should receive any broadcast information

2. Low latency 3

msg. transmission timeblock time interval

3 Allows to keep the probability of fork small (i.e. 10−3)3 PoW mechanism allows this ratio to continuously hold7 No more than 7 trans/s can be permanently confirmed in

average ! !

3. J. Garay and A. Kiayias, The Bitcoin Backbone Protocol : Analysis andApplication, Eurocrypt 2015

A chain of blocks : the blockchain

A publicly, immutable, and totally ordered log of transactions

Block of transactions

Transaction 945846Transaction 58801aTransaction 665389Transaction 7654ab

.Transaction 321456

Blocks of transactions

.Transaction 321456

Transaction 437621Transaction 8593abTransaction 12367bTransaction 793154

.Transaction 653278

Transaction 336789Transaction 7245abTransaction 635566Transaction 12f4a22

.Transaction 232356

Resistant to attacks

.Transaction 321456

.Transaction 653278

.Transaction 232356

Resistant to attacks

.Transaction 321456

.Transaction 653278

.Transaction 232356

Transaction 945846Transaction 58801aTransaction 665389

Transaction 7654ab...

Transaction 321456

I Why digital signatures are not sufficient ?

7 do not prevent double-spending attacks

I How can we securely link blocks ?

3 by linking them with cryptographic fingerprints

I How can we prevent transactions in a block from beingmanipulated ?

3 efficient cryptographic fingerprint of the transactions

I Who is allowed to create blocks ?

3 any node in the network capable of solving a given challenge

I Who is in charge of checking that blocks are correctlycreated ?

3 everyone ! !

I Why digital signatures are not sufficient ?7 do not prevent double-spending attacks

I How can we securely link blocks ?

3 by linking them with cryptographic fingerprints

3 everyone ! !

I How can we securely link blocks ?3 by linking them with cryptographic fingerprints

3 everyone ! !

3 efficient cryptographic fingerprint of the transactionsI Who is allowed to create blocks ?

3 everyone ! !

3 any node in the network capable of solving a given challengeI Who is in charge of checking that blocks are correctly

created ?

3 everyone ! !

3 any node in the network capable of solving a given challengeI Who is in charge of checking that blocks are correctly

created ?3 everyone ! !

How can we securely link blocks ?

Cryptographic Hash functions

I allows you to compute a fixed-size fingerprint from any type ofdata

I deterministic functionI efficiently computableI practically impossible to invert (« one-way function »)

More on Merkle tree

H(block n-6)Merkle root

H(block n-4Merkle root

.Transaction 321456

.Transaction 653278

.Transaction 232356

Transaction 652a11Transaction 432312Transaction 733566Transaction 22f432

.Transaction 672356

.Transaction 232356

.Transaction 653278

.Transaction 321456

4. Merkle, R. C. (1988). "A Digital Signature Based on a ConventionalEncryption Function". Advances in Cryptology - CRYPTO ’87.

Who is allowed to create blocks ?

Miners, i.e., any node capable of solving a highly complexcomputational puzzle

I A leader election algorithm is run among all the minersI Probabilistic oracleI Synchronize the creation of blocksI Prevent Sybil attacksI Incentivize correct behavior through currency creation

Minting money to incentivize correct behavior

BLOCK n

Previous block n-1

Merkle tree (root)

Proof of work

TransactionsT0T1...

BLOCK n-1BLOCK n-2

Coinbase transaction�12.5 + transactions

I Nodes are working (racing) to solve the computational puzzleI This is in exchange for monetary rewards

I Coinbase transaction = 12.5 bitcoins + transaction feesI Started at 50 bitcoins and is halved every 210, 000 blocks

I This incentivizes miners to only work on valid blocksI « valid block » : for miners, this means blocks for which the

majority will accept to build upon

Blockchain Proof-of-Work

I Comes down to compute a hash partial inversionI find pre-image for a partially specified hash function output

Proof-of-Workstring=HelloWorld !, nonce=0, difficulty=000

Proof-of-Work

string=HelloWorld !, nonce=0, difficulty=000 1

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a

Proof-of-Work

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106aHelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27

Proof-of-Work

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106aHelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27HelloWorld!2:5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320

Proof-of-Work

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106aHelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27HelloWorld!2:5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320HelloWorld!3:9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78....

Proof-of-Work

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106aHelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27HelloWorld!2:5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320HelloWorld!3:9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78....HelloWorld!94:7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6

Proof-of-Work

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106aHelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27HelloWorld!2:5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320HelloWorld!3:9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78....HelloWorld!94:7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6HelloWorld!95:b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43HelloWorld!96:447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9

Proof-of-Work

string=HelloWorld !, nonce=97, difficulty=000, 6

HelloWorld!0:3f6fc92516327a1cc4d3dca5ab2b27aeedf2d459a77fa06fd3c6b19fb609106a

HelloWorld!1:b5690c48c2d0a09481186aaa99e4e090901ff2ac4d572e6706dfd30eefc22a27

HelloWorld!2:5b6fd9c27fcb54ca23404d9428f081b7c9280ba6370e33a6a20b16f40ce76320

HelloWorld!3:9c5d769416aa0ca894abf22bd17bd30fbb6959291423ae1903a9f86a1fe7ce78

HelloWorld!94:7090a0e5d88cff635e42ea33fcd6091a058e9cdd58ab8cd5c21c1c70421e35c6

HelloWorld!95:b74f3b2cf1061895f880a99d1d0249a8cedf223d3ed061150548aa6212c88d43

HelloWorld!96:447ca2fa886965af084808d22116edde4383cbaa16fd1fbcf3db61421b9990b9

HelloWorld!97:000ba61ca46d1d317684925a0ef070e30193ff5fa6124aff76f513d96f49349d

Blockchain Proof-of-Work

Properties

I Algorithmically computableI Difficult to solve but quickly verifiedI Difficulty proportional to computation power

I average generation time : 10 minutesI proba p that one try is successful is p = D/2κ with {0, 1}κ the

range of H(.) and D the difficultyI around 23, 000, 000× 1012 hash/s

I Memoryless process

Nounce

Coinbase transac.Transaction 945846Transaction 58801aTransaction 665389Transaction 7654ab

Coinbase transac.Transaction 437621Transaction 8593abTransaction 12367bTransaction 793154

Coinbase transac.Transaction 336789Transaction 7245abTransaction 635566Transaction 12f4a22

Coinbase transac.Transaction 652a11Transaction 432312Transaction 733566Transaction 22f432

Coinbase transac.Transaction 336789Transaction 7245abTransaction 635566Transaction 12f4a22

Coinbase transac.Transaction 437621Transaction 8593abTransaction 12367bTransaction 793154

Coinbase transac.Transaction 945846Transaction 58801aTransaction 665389Transaction 7654ab

Blockchain construction

Block !

A B C D E F G

(B0,⊥)

(B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥)

2 5 3 3 4 1 2

Block ! Block ! Block ! Block ! Block ! Block ! Block !

A B C D E F G

(B0,⊥)

(B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥)

Block !

A B C D E F G

(B0,⊥)

(B0,⊥)(B1,B)

(B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥) (B0,⊥)

5 1 3 5 1 4 3

A B C D E F G

(B0,⊥)(B1,B)

5 4 2 3 2 1 1

A B C D E F G

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

Conflict : Transient inconsistencies

6 3 5 5 4 6 5

Block !

Block ! Block ! Block ! Block !

Block !

A B C D E F G

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B6,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B ′6,F )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

Blockchain fork

BLOCK n-2BLOCK n-3 BLOCK n-1 BLOCK n BLOCK n+1 BLOCK n+2

BLOCK n+1

Nakamoto conflict chain ruleMine on the longest branch !

I Proba. that a block is removed from the blockchain decreasesexponentially with the number k of blocks appended to it.

I k = confirmation levelI When k ≥ 6, this proba is very small

1 3 6 5 4 2 6

Block ! Block !

Block !

Block ! Block ! Block !

Block !A B C D E F G

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B6,A)

(B7,G )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B ′6,F )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B ′6,F )

(B ′7,C )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B ′6,F )

(B ′7,C )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B6,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B ′6,F )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,E )

(B6,A)

(B7,G )

6 3 2 5 4 2 4

Block !

Block ! Block ! Block ! Block ! Block ! Block !

A B C D E F G

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

(B8,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

(B8,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

(B8,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

(B8,A)

(B0,⊥)(B1,B)

(B2,E )

(B3,C )

(B4,A)

(B5,B)

(B6,A)

(B7,G )

Nakamoto consensus protocol

1. Leader election among all the minersI Probabilistic oracleI Synchronize the creation of blocksI Prevent Sybil attacksI Incentivize correct behavior through currency creation

2. A simple and local arbitration ruleI Select the chain which required the greatest among of work

Nakamoto consensus protocol

1. Leader election among all the minersI Probabilistic oracleI Synchronize the creation of blocksI Prevent Sybil attacksI Incentivize correct behavior through currency creation

2. A simple and local arbitration ruleI Select the chain which required the greatest among of workI Random nature of the PoW = one chain will be extended more

than the others

The 50% attack

I Once a transaction has been inserted in a block B of theblockchain, the sender of coins will typically expect someproduct or service in return

I This is undermined if the sender would be able, after receivingthe product, to broadcast a conflicting transaction sending thesame coin back to itself, and such that by chance this nonlegitimate transaction would appear in some concurrent blockB ′

I By applying the Bitcoin rule, this concurrent block B ′ mightinvalidate the legitimate one B if B ′ belongs to a longest chainthan the one of B

The 50% attack (con’t)

I Thus as long as a legitimate recipient of a transaction is notsure that the coins it received will not be redirected to anotherparty, it is safer for him to wait before delivering the product(otherwise the recipient would lose its product withoutreceiving any coins)

The question is how long the recipient of transaction T ′ mustwait before delivering its product/service ?

I If an attacker controls a substantial computational power hemay succeed in computing sufficiently many concurrent blocksso that eventually « his » branch becomes longer than the onemined by honest miners, and win its attack

The 50% attack

I A transaction is said to have n confirmations if it included in ablock B which is part of the longest chain, and there are nblocks in the path from that block B to the leaf of the chain

I It is generally assumed that a transaction with enoughconfirmations is safe from double spending attacks

I We now study what it means « enough confirmations »

A game between two teamsWe consider two teams :

I A bad team Q which tries to make a successfuldouble-spending attack

I A honest team P which behave correctlySuppose that the legitimate transaction T belong to block B , andthe conflicting one T ′ belongs to block B ′

A game between two teams

1. Secretly team Q mines a chain of blocks B ′ . . . which builds onthe latest block that precedes block B

2. Team Q waits until block B receives enough confirmations andthe recipient, confident in its payment, sends the product

3. Team Q continues to mine blocks in the secret chain (whichcontradicts block B) until this secret chain is longer than thepublic chain (the one that contains B)

4. Then team B broadcasts its secret chain. This chain beinglonger that the public one, it is considered as the new validone, and thus the payment to the recipient will be replaced bythe payment to the attacker

I Let n be the number of blocks after the fork in the publicchain (mined by team P)

I Let m be the number of blocks that team Q succeded to mineafter the fork

I Both teams are trying to win the competitionI The question is « Is team Q will be able to catch-up with a

longer chain ? » or will the gap just keep increasing, leavingteam Q behind with a chain which will never be valid ?

nblocks

m blocks z blockslatetocatchup

TeamQTeamP

I We suppose that the total hashrate of team P and team Q isconstant and equal to H

I Team P has a hashrate of p.HI Team Q has a hashrate of q.H, where p + q = 1

I Let z = n −m

I z is the number of blocks by which the honest team (P) hasan advantage on the attacker (team Q)

I when team P finds a block, z increases by 1 and when team Qfinds a block, z decreases by 1

I z = −1 then the attack of team Q succeeds. If it neverhappens, the attack fails

I This process is equivalent to a discrete time Markov chainI A step is defined as finding a block by team P or team QI We have at step i + 1

zi+1 = zi + 1 with probability p andzi+1 = zi − 1 with probability q

I Let az be the probability that the attacker will be able tocatch up when it is z block behind the honest team (initialdisadvantage = z)

I if z < 0 then az = 1 (the attacker has a longer branch)I now, if z ≥ 1, what is the value of az ?I if the next block which is found is found by the honest team,

which happens with probability p, then the attacker will bez + 1 blocks behind, and its probability of success will be az+1

I if the next block which is found is found by the attacker,which happens with probability q, then the attacker will bez − 1 blocks behind, and its probability of success will be az−1.

I This leads to the following relation

az = paz+1 + qaz−1

I We haveaz = paz+1 + qaz−1

I remember that p + q = 1, which leads to

az = 1 if z < 0 or if q > p

az = (q/p)z+1 if z ≥ 0 and q ≤ p

Remarks :I if the attacker owns more than 50% of the computational

power, then he always succeeds catching up, from any gap z

I when q < p the probability of success decreases exponentiallywith gap z . The lower q is, the faster the decay.

I We have just seen that the probability that the attackersucceeds depends on z

I So what is a reasonable value for the number of confirmationsn for a merchant to be sure that his transaction will stayforever in the blockchain ?

I We model m as the number of successes (blocks found by theattacker) before n failures (blocks found by the honest team).Thus m is a negative binomial variable.

I The probability P(q,m, n) of having m success before nfailures is

P(q,m, n) =

(m + n − 1

I Once n blocks have been mined by the honest team in aperiod of time during which m + 1 blocks have been found bythe attacker, the race starts with z = n −m − 1

I Thus the probability for a double-spending attack to succeedwhen the merchant waits for n confirmations blocks is theprobability of the attacker progressing from 1 pre-computedblock to m blocks and then catching up from a difference ofm −m blocks :

d =∞∑

an−m−1P(q,m, n)

d =n∑

an−m−1P(m) +∞∑

an−m−1P(m)

d =n∑

an−m−1

(m + n − 1

)pnqm+

∞∑m=n+1

an−m−1

(m + n − 1

d = 1−∑n

m=0(m+n−1

)(pnqm − qnpm) if q < p

d = 1 if q ≥ p

Probability of a successful double spend attack as a functionof the attacker’s hashrate q and the number ofconfirmations n

Looking at the blockchain as a shared object

Block !

A B C D E F G

(B0,⊥)

Block !

A B C D E F G

(B0,⊥)

Block !

A B C D E F G

(B1,B)(B0,⊥)

write(B

Block !

A B C D E F G

(B1,B)(B0,⊥)

read()=(B

0 ,⊥)(B

Block !

A B C D E F G

(B5,E )(B4,A)(B3,C )(B2,E )(B1,B)(B0,⊥)

Block !

A B C D E F G

(B5,E )(B4,A)(B3,C )(B2,E )(B1,B)(B0,⊥)

write(B

read()=?

Block !

A B C D E F G

(B5,E )(B4,A)(B3,C )(B2,E )(B1,B)(B0,⊥)

write(B

read()=?

write(B

The main steps to write and read the blockchain

I As you have seen, each miner needs to locally manage a datastructure from which it extracts the blockchain, i.e., thelongest chain (more exactly the one which required the mostamount of work)

I Actually this data structure is a treeI the root of the tree is the common block called the genesis

blockI Let T B be this tree, and B be the longest chain in T BI What about the read and write operations :

I a read operation on T B should return BI a write operation on T B should try to change the value of T B

with a new block B, that is B to which is appended B

The main steps to write and read the blockchainI When a miner wishes to augment the blockchain with a new

blockI it first invokes a read on T B to get the current blockchain BI then the miner creates its block B1, appends it to B :B ← B ⊕ B1

I then it invokes a write on T B with B as parameterI finally it broadcasts B in the system (actually from a practical

point of view, only B is broadcast)

Blockchain -as-a-shared -object Algorithm //run by a miner

{repeat forever{B = DLR.read()create the well -formed block b from Bappend b to BDLR.write(T B,B)

Classical Shared RegistersLiveness : Any read / write operation terminates1. Safe register Safety :

read() =

{last written value,any value of the register domain if concurrent write

2. Regular register Safety :

read() = v

{last written value,value written by a concurrent write

3. Atomic register Safety :(Regular register safety) +

(no old / new inversions

Blockchain

BLOCK n-2BLOCK n-3 BLOCK n-1 BLOCK n BLOCK n+1 BLOCK n+2

BLOCK n+1

Classical Shared Registers

I If we look at the blockchain as a shared object, we observethat it is quite different from a read/write register

I In a classic R/W register, we do not impose that writeoperations depend on each other

I We need to introduce a new object that better captures thesemantics of blockchains

Algorithm run by a miner in terms of read and writeoperations

Blockchain -as-a-shared -object Algorithm // runby a miner

{repeat forever{B = DLR.read()create the well -formed block b from Bappend b to Bwrite(T B,B)

Operation read(){

return best_chain(B)}

Operation write(T B,B){

update_tree(T B,B)broadcast(B)

return}

I Recall that an important property of Bitcoin is the number ofconfirmations n

I Once a block has n (e.g. n = 6) confirmations then one mayhave confidence that this block will stay forever in theblockchain

write(!)$ read()%>$!'

Operation write(T B,B){

update_tree(T B,B)broadcast(B)repeatB′ = read()

until length(B′) ≥ length(B)+nif B = prefix(B′)

return trueelse

return abort

upon deliver(B)update_tree(T B,B)

Distributed Ledger Register (DLR)

I A DLR should mimic the behavior of a blockchain andI A DLR should allow any number of writers (miners) to write it

andI A DLR should allow any number of readers (anyone) to read it

Distributed Ledger Register (DLR)

I DLR = tree structure T BI Root = genesis blockI Branch = sequence of blocks

I Value of DLRI longest sequence of blocks starting from the genesis block

(initial value of the register)I called the blockchain, and denoted B

I Two operations :I DLR.read() : returns the blockchainI DLR.write(B) : update the value of DLR with B

write() operation

Definition (n-valid)

Operation write(B) invoked at time tw > 0 is n-valid if and onlyif for any read operation r invoked at time tr , tr > tw , r returns B′such that

I B is a prefix of B′ and length(B′) ≥ length(B) + n.write(B) :update T B with Breturns true if it is n-valid, abort otherwise

write(!)$%>$true

read()%>$!'

write(!'')$%>$abort

Specification of the Distributed Ledger RegistersA Multi-Reader/Multi-Writer Distributed Ledger is defined by thefollowing properties :

I Liveness Any invocation of a read or a write(B) operationterminates

I n-consistency Any read() operation returns B whose prefixB′ is the value of the register written by the last n-validwrite(B′) operation that precedes read().

In other words the n-consistency property says that the returnedblockchain except for the last n appended blocks isexactly the value written by the last n-valid write()operation

Blockchain-as-a-shared-object Algorithm proof : liveness

LemmaBlockchain-as-a-shared-object Algorithm (A) satisfies the livenessproperty of the DLR

ProofI The read() operation (see code) always returns since the read

is executed locallyI For the write() operation (see code), the only blocking part of

the code is the repeat loopI By assumption of A, miners continuously try to create blocks

which gives rise to the invocation of write() operationperiodically

I Thus the loop stops, which allows the write() operation toeither return true or abort

I This ends the proof

Blockchain-as-a-shared-object Algorithm proof : n-validity

LemmaEach non aborted write() operation invoked by A satisfies then-validity property of the DLR

ProofI Let w be any non aborted write(B) operation that completes

at time t

I Note that this operation returns only when the best chain inthe tree, say B′, has B as a prefix and has at least k additionalblocks (see code)

I Let r be a read() operation that happens after op w .I If r is invoked by the miner that invoked w then necessarily the

n-validity holdsI Otherwise, by the property of the broadcast, there is a time τ ,

such that by time t + τ , B′ has reached all the nodes. Henceany read() invoked after t + τ returns at least B′

I This completes the proof

Blockchain-as-a-shared-object Algorithm proof :n-consistency

LemmaEach read() operation invoked by A after that τ time units haveelapsed since the last n-valid operation satisfies the n-consistency

EmmanuelleAnceaume …people.irisa.fr/Emmanuelle.Anceaume/Bitcoin-keynote.pdf · 5 Publicledgers...

Documents

Transcript of EmmanuelleAnceaume …people.irisa.fr/Emmanuelle.Anceaume/Bitcoin-keynote.pdf · 5 Publicledgers...

Bitcoin Trezor - hardware bitcoin wallet

Bitcoin - Bitter to Better - Bitcoin-Stanford

Bitcoin & bitcoin mining(final)

Bitcoin buy | Vancouver Bitcoin

Bitcoin Investment Trust - Bitcoin 2014

Understanding Bitcoin Bitcoin Beginner Guide

THE BITCOIN FUND - 3iQ Corp · The Bitcoin Fund (the “Fund”) invests in the digital currency bitcoin. Given the speculative nature of bitcoin and the volatility of the bitcoin

Let's Talk Bitcoin, episode 1, "Let's Talk Bitcoin!"

Bitcoin tech talk @Purdue Bitcoin Club

BITCOIN FORENSICS - liacfe.orgliacfe.org/images/meeting/011818/2018_01_18_bitcoin_forensics... · BITCOIN FORENSICS Why is Bitcoin worth anything? Bitcoin is similar in ways to Gold:

Bitcoin Security, Bitcoin Startups Berlin

How To Mine Bitcoin Profitably (Scaling Bitcoin - Montreal)

Class 21: Scaling Bitcoin & Web Bitcoin Blockchain 2.0

EmmanuelleAnceaume …people.irisa.fr/Emmanuelle.Anceaume/consensus-asynchrone-FLP.pdf · FLPimpossibilityresult[FLP85] Theorem(FLPimpossibilityresult) Thereexistsnodeterministicalgorithmthatsolvesthebinary

Let's Talk Bitcoin, episode 09, "Bitcoin 2013 Kickoff!"

Bitcoin 101 - Bitcoin For Beginners by World Bitcoin Network

Boom, Bust, and Bitcoin: Bitcoin-Bubbles As Innovation ...

Blockchain/Bitcoin Functionality in Land Administration · Blockchain/Bitcoin Functionality in Land ... 1 bitcoin = 1 sq land unit = = Grid. ... Blockchain/Bitcoin Functionality in

Bitcoin - Zerocoin - Anonymous Distributed E-Cash From Bitcoin

verge.zendesk.com · GATEWAY Accept Payment Verge, Bitcoin, Bitcoin Cash, Ethereum, Litecoin, Tron , Horizon Fiat CAD, Euro Instantly Settlement Crypto: Bitcoin, Bitcoin Cash, Ethereum,