department of computer science network security research …...network security research group...

Department of Computer Science

Network Security Research Group

Bitcoin‘s Peer-to-Peer network

Christoph Sorge

February 12th, 2014 Bitcoin minisymposium at KNAW

Department of Computer Science Network Security Research Group

What is a Peer-to-Peer network?

Common model for provision of services: Client/Server – Server provides the service

– Clients use the service

Development since the late 1990s: Peer-to-Peer – No central server (or central server with limited

functionality, e.g. directory server)

– Service provision and service usage no longer separate – participants can be client and server simultaneously

KNAW, Feb 12, 2014 2

Clip

art

sou

rce

: htt

p:/

/op

encl

ipar

t.o

rg, u

sers

Mac

ho

vka

and

Kei

stu

tis


Peer-to-Peer networks: Some advantages and drawbacks

Advantages – Robustness – failure of a single node within the system (usually)

without consequences • One motivation for Peer-to-Peer networks: Robustness

against legal measures

– Costs and workload shared among participants

Drawbacks – Difficult coordination between nodes (especially in highly

dynamic networks) – Possible manipulation by malicious participants (in case

of open participation) – Privacy issue: Less control over dissemination of information

(but: no central entity collecting all data)

KNAW, Feb 12, 2014 3


The Bitcoin Peer-to-Peer network

Bitcoin – uses accounts (represented by Bitcoin addresses) and transactions

between these accounts

– does not have a central (bank) server – pure Peer-to-Peer principle

Bitcoin clients have to agree on account balances (signatures of transactions do not suffice for this)

Bitcoin clients need information about transactions

Goal: Consistent view in the whole network

Peer-to-Peer network used to ensure this consistent view

KNAW, Feb 12, 2014 4


Peer-to-Peer network structure

Differentiation between structured and unstructured Peer-to-Peer networks

– Unstructured networks: Random connections between peers

– Structured networks: Nodes assigned to specific positions in a structure, e.g. ring • Positions have a meaning, e.g. node at position

17 stores content with hash values starting with “17”

• Nodes with certain responsibilities can be found efficiently

Structured network: Chord KNAW, Feb 12, 2014 5


Bitcoin‘s Peer-to-Peer network structure

Bitcoin: Unstructured Peer-to-Peer network – No overhead for maintaining the structure

– Simple implementation

– Main advantage of structured networks – quick finding of specific information – not applicable to Bitcoin: All nodes need (more ore less) complete information

– Still: Structured network might be more efficient

How to learn about other nodes? – After learning about a few nodes, ask about their neighbours

– Listen to advertisements of new joining nodes

KNAW, Feb 12, 2014 6


Joining the Peer-to-Peer network: How to start

First step: Finding some other peers

– Requires “cheating”: Finding peers without some central system is difficult

– Bitcoin’s approach(es) • Use pre-configured IP addresses

• Get IP addresses from an IRC channel (no longer used in the default setting)

• Get IP addresses via the Domain Name System (DNS servers run by volunteers)

KNAW, Feb 12, 2014 7


Connections in the Bitcoin network

Node knows some IP addresses of other nodes – Node connects to a certain number (default: 8) of these nodes

– Node accepts incoming connections beyond that limit (not always possible, e.g. due to firewalls)

– On average: About 30 connections per node that accepts incoming connections

Inactive nodes deleted from lists after timeout (several hours)

KNAW, Feb 12, 2014 8


Bitcoin transactions and blockchain

High-level view of Bitcoin transactions – Individual transaction from A to B

• A signs the transaction (including reference to incoming transaction) using the private key of his address

• A broadcasts the transaction to the whole Bitcoin network

– Confirmation of transactions • Nodes (miners) collect transactions in a “block”

• Miners append block to blockchain (=transaction history) and compute a proof of work

• Successful miner broadcasts the block to the whole Bitcoin network

(Main) information to be forwarded in the Peer-to-Peer network: Transactions and blocks

KNAW, Feb 12, 2014 9


Broadcasting

Sender informs all connected Bitcoin nodes about availability of a new transaction / new block – Invite message

On receipt of an invite message – Node requests the transaction / block if it does not know it yet

– Node verifies the transaction / block based on local blockchain copy

– Node informs all connected Bitcoin nodes about availability of a new transaction / new block

– …

KNAW, Feb 12, 2014 10


Consistent view?

Goal of the Peer-to-Peer network: Consistent view – Network becomes inconsistent once a new block is generated

Knows blocks 1 to 1234




Generates block 1235


Transmits block 1235 (~200 KB)

Verifies block 1235

Verifies block 1235

Transmits block 1235



And so forth…

KNAW, Feb 12, 2014 11


Information propagation

Investigation by Decker and Wattenhofer (Proc. IEEE P2P‘13) – Connection to a large number of nodes, observation of information

propagation

– Average time till a node receives a new block: 12.6 seconds

– Long tail: 5% of nodes do not have the new block after 40 seconds

Problem of propagation time: Other miner may find a new block within that time two inconsistent versions of the blockchain (blockchain fork) – Decker and Wattenhofer observe 169 blockchain forks during a period

of 10,000 generated blocks (some forks may have been missed)

KNAW, Feb 12, 2014 12


Inconsistency example





Generates block 1235



Verifies block 1235

Verifies block 1235a


Knows blocks 1 to 1235a

Generates block 1235a

Knows blocks 1 to 1235a

Transmits block 1235a

Transmits block 1235a

Does not accept block

1235a


Does not accept block

1235

KNAW, Feb 12, 2014 13


Dealing with inconsistency

Each miner continues with one version of the blockchain – First newly generated block leads to longest chain

– All nodes switch to longest chain once that block has been received

Transaction only present in the shorter version: Not lost, but integrated into the next block

Note: Implementation bugs can lead to long-living forks – Implementation bug lead to fork between Bitcoin 0.7 and Bitcoin 0.8

client versions (quickly resolved)

KNAW, Feb 12, 2014 14


Full vs. limited nodes

Full node: Has all the functionality described so far – Blockchain currently at about 14 GB (and growing)

– Mining only attractive on special-purpose hardware

Alternative: Leave out some functionality – Calculation of proofs of work (Mining)

– (complete) verification of transactions

– Acceptance of incoming connections

Simplified payment verification – Store only block headers instead of complete blocks

– Verification of a transaction also requires (part of) the block it is contained in

Verification if transaction was accepted by others, i.e. proof(s) of work include the transaction (no own check for double spending etc.)

KNAW, Feb 12, 2014 15


Full vs. limited nodes (2)

Potential attacks on SPV – Attacker controls victim‘s internet connection, double-spends and

computes own proof(s) of work – victim does not check for double-spending and believes in validity of transaction

Storage of complete blockchain helps uncover irregularities – e.g., attacker with lots of computational power

Alternative to running a full node – Client/server architecture, with full blockchain stored on the server

Some full nodes required in the network – For mining – Some nodes must accept incoming connections

KNAW, Feb 12, 2014 16


Privacy issues

Bitcoin privacy research concerning the transaction graph – linking different Bitcoin addresses of a user

Concerning the Peer-to-Peer network – Figure out origin (IP address) of a transaction by finding

the first node that broadcasts it

Try to get connections to as many nodes as possible • Connect to nodes in the network that accept incoming

connections (described in a talk by Dan Kaminsky, 28th Chaos Communication Congress, December 2011)

• Join the network under many fake identities to get many other nodes to connect to you

KNAW, Feb 12, 2014 17


Other (selected) Bitcoin issues

Scalability – of the Peer-to-Peer network itself: Probably not a practical issue – of the Bitcoin protocol, which requires broadcast of transactions:

claimed to be unproblematic • Bitcoin Wiki comparison: VISA has 2,000 transactions per second, which would

lead to data rate of 8 megabits/s if Bitcoin was used

Storing data in the Blockchain – Possible for arbitrary data wasted storage capacity

Denial-of-Service attacks – Attacks trying to cause overload or stop the transmission of legitimate

transactions/blocks – Hard to counteract in a Peer-to-Peer network – Basic countermeasures (like block size limits) already implemented

18 KNAW, Feb 12, 2014


Summary / Conclusion

Bitcoin‘s Peer-to-Peer network is simple, but works

Unstructured network, simple broadcast scheme

Privacy not guaranteed by the network – May be addressed using additional protocols, like Tor

Denial-of-Service attacks also possible

19 KNAW, Feb 12, 2014


Image sources

http://openclipart.org/detail/2154/computer-system-case-by-machovka

http://openclipart.org/detail/168489/pc-laptop-notebook--by-keistutis

My PhD thesis, image with support from Denise Dudek and Wenzel Svojanovsky

KNAW, Feb 12, 2014 20

department of computer science network security research …...network security research group...

Documents