Christoph Sorge. February 12th, 2014 Bitcoin minisymposium at KNAW

Transcription

1 Bitcoin s Peer-to-Peer network Christoph Sorge February 12th, 2014 Bitcoin minisymposium at KNAW

2 Clipart source: users Machovka and Keistutis Department of Computer Science 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,

3 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,

4 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,

5 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 KNAW, Feb 12, Structured network: Chord

6 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,

7 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,

8 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,

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

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

11 Consistent view? Goal of the Peer-to-Peer network: Consistent view Network becomes inconsistent once a new block is generated Generates block 1235 Knows blocks 1 to Knows blocks 1 to Verifies block 1235 Knows blocks 1 to 1234 Transmits block 1235 (~200 KB) Knows blocks 1 to Verifies block 1235 Transmits block 1235 And so forth KNAW, Feb 12,

12 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,

13 Inconsistency example Generates block 1235 Knows blocks 1 to Does not accept block 1235a Knows blocks 1 to Verifies block 1235 Transmits block 1235 Knows blocks 1 to a Transmits block 1235 Transmits block 1235a Knows blocks 1 to 1235a 1234 Does not accept block 1235 Transmits block 1235a Verifies block 1235a Generates block 1235a KNAW, Feb 12,

14 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,

15 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,

16 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 doublespending 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,

17 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,

18 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 KNAW, Feb 12,

19 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 KNAW, Feb 12,

20 Image sources My PhD thesis, image with support from Denise Dudek and Wenzel Svojanovsky KNAW, Feb 12,