NAVY Research GroupDepartment of Computer Science

Faculty of Electrical Engineering and Computer Science VŠB-TUO17. listopadu 15

708 33 Ostrava-PorubaCzech Republic

Computer Attack and Defense

Bitcoin

Ivan Zelinka

MBCS CIPT, www.bcs.org/http://www.springer.com/series/10624

Department of Computer ScienceFaculty of Electrical Engineering and Computer Science, VŠB-TUO

17. listopadu 15 , 708 33 Ostrava-PorubaCzech Republic

www.ivanzelinka.eu

navy.cs.vsb.cz2

Topics

• Lectures structure.

• Lecture content and timeline

• Consequences.

navy.cs.vsb.cz3

Objectives

The objectives of the lesson are:

• Discuss structure of lectures in important details and mutual relations.

• Lecture content and timeline

• Consequences.

navy.cs.vsb.cz4

Lecture Structure

• Doplnim ja

navy.cs.vsb.cz5

Cryptocurrency

• digital asset designed to work as a medium of exchange using cryptography to secure the transactions and to control the creation of additional units of the currency

• cryptocurrency = subset of alternative currencies or specifically digital currencies

• Properties:

– Decentralization – it is not possible to control the cryptoccurency by the government or other institutions

– Transparency – public databases denoted as Blockchain

– Low or no fees

– No rejection of payment [1]

navy.cs.vsb.cz6

Legal Status of Digital Currencies in Different Countries

Legal status of digital currencies in different countries. From left to right and top to bottom: February

2014, March 2014, April 2014, and September2014. Green: permissive countries, red: hostile

countries, yellow: contentious countries, grey: unknown position. Data source [2]

• „Digital currencies are not media of payment allowed by law or recognized by any legal system as valid for meeting financial obligations.“[2]

navy.cs.vsb.cz7

Cryptocurrency

• Bitcoin

• Dash

• Ethereum

• Litecoin

• Dogecoin

• Peercoin

navy.cs.vsb.cz8

Bitcoin

• cryptocurrency and a payment system

• Satoshi Nakamoto (pseudonym of an unknown person or group of persons) – design of the software and protocol for Bitcoin –Bitcoin-Qt

• Nakamoto owns roughly one million bitcoins, with a value estimated at over US$1 billion

• Craig Steven Wright (Australian programmer) has claimed to be Nakamoto, however, this information has never been confirmed [4]

navy.cs.vsb.cz9

History

• 2007 – beginning of writing of the code

• 2008 and 2009 – 2 papers describing the bitcoin:

– Nakamoto, Satoshi (24 May 2009). "Bitcoin: A Peer-to-Peer Electronic Cash System" (PDF). Retrieved 5 March 2014.

– Nakamoto, Satoshi (31 October 2008). "Bitcoin P2P e-cash paper". Retrieved 5 March 2014.

• 2009 – first bitcoin software released (Version 0.1 was compiled using Microsoft Visual Studio)

• 2010 – the control of the source code repository and network key alert has been handed over to Gavin Andersen [4]

navy.cs.vsb.cz10

Main Idea

• Electronic payment system based on cryptographic proof => allowing any two willing parties to transact directly without the need for a trusted third part

• Transactions that are computationally impractical to reverse protect sellers from fraud

• Routine escrow mechanisms have been implemented to protect buyers [1]

navy.cs.vsb.cz11

Transactions I

• Electronic coin is defined as a chain of digital signature

• Owner transfers the coin to the next one by digitally signing a hash of the previous transaction and the public key of the next owner. This is added to the end of the coin

• A payee can verify the signatures to verify the chain of ownership

navy.cs.vsb.cz12

Transactions II

Source: [1]

navy.cs.vsb.cz13

Bitcoin Transaction in Scheme

Source: http://www.pcworld.com/article/2033715/7-things-you-need-to-know-about-bitcoin.html

navy.cs.vsb.cz14

Transactions Statistics

Number of average Bitcoin transactions in a

single block. Data source:[2]

Estimated number of giga hashes per

second (billions of hashes per second).

Datasource:[2]

navy.cs.vsb.cz15

Average Amount per Transaction (USD)

Comparison between different payment networks. Average daily USD amount per transaction from 1Q2011 to 1Q2015. Data source: [2]

navy.cs.vsb.cz16

Transactions Patterns

Log-scale distribution of Bitcoin transactions per number of inputs and number of outputs.

DataSource: [2]

navy.cs.vsb.cz17

Average Transaction Block Size

• In the Bitcoin network, typical transaction size is 500 bytes. The corresponding transaction fee for a low-priority transaction is 0.1 mBTC (i.e 0.0001 BTC)

navy.cs.vsb.cz18

Average Cost per Transaction

where Ex is the average exchange rate (BTC/USDE and LTC/USD) [2]

_ _ _ _ _ _ _ min_ cos _ _

._ _ _ _

Daily trans free in coins earned by ersAvg t per trans Ex

Nr of unique daily trans

navy.cs.vsb.cz19

Average Confirmation Time

navy.cs.vsb.cz20

Problem in Transactions

• Double-spend of the coin, which can not be verified by payee

• Possible solution

– Trusted central authority or mint checking each transaction for double-spend => dependence on the company running the mint

• Solution in Bitcoin:

– transactions must be publicly announced

– need a system for participants to agree on a single history of the order in which they were received

– „The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.“[1]

navy.cs.vsb.cz21

Timestamp Server

• Timestamp server – take a hash of block of items to be timestamped and widely publish the hash (such as in a newspaper or Usenet post)

• „The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash.“ [1]

• Each timestamp includes the previous timestamp in its hash -> forming a chain

• Each additional timestamp reinforce the ones before it [1]

navy.cs.vsb.cz22

Proof-of-work I

• In Bitcoin proof-of-work system similar to Adam Back‘s Hashcash

• Involves scanning for a value that when hashed (such as SHA-256) the hash begins with a number of zero bits

• „The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.“ [1]

• In Bitcoin – proof-of-work implemented by incrementing a nonce (arbitrary number that may only be used once) in the block until a value is found that gives the block‘s hash the required zero bits [1]

navy.cs.vsb.cz23

Proof-of-work II

• „Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work.“ [1]

• Solution of the problem of determining representation in majority decision making

• Proof-of-work is based on one-CPU-one-vote instead of one-IP-address-one-vote

• The majority decision is represented by the longest chain having the greatest proof-of-work effort expended in it [1]

navy.cs.vsb.cz24

Proof-of-work III

• Majority of CPU power is controlled by honest nodes => the honest chain grows the fastest and outpaces any competing chains

• In the case of the attack:

– „The attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes.“ [1]

– It has been shown that the probability of a lower attacker catching up diminishes exponentially as subsequent blocks are added

• The proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour (compensate for increasing HW speed and varying interest in running nodes over time) [1]

navy.cs.vsb.cz25

Proof-of-work Example

• Goal: find out the variation of „Hello world!“ that SHA-256 hashes to a value beginning with ‚000‘

• How to do this: varying the string by adding an integer value to the end (nonce) and incrementing it each time

• 4251 tries for „Hello world!“

• To keep roughly constant rate of block generation Bitcoin automatically varies the difficulty [4]

navy.cs.vsb.cz26

Network I

• The steps to run the network [1]:

– New transactions broadcast to all nodes

– Each node collects new transactions into a block

– Each node tries to find a difficult proof-of-work for its block

– When a node finds a proof-of-work, it broadcasts the block to all nodes

– Nodes accept the block only if all transactions in it are valid and not already spent

– Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash

• The longest chain is always considered to be the correct one by nodes, which are working on extending it [1]

navy.cs.vsb.cz27

Network II

• Two nodes broadcast different versions of the next block simultaneously [1]:

- Some nodes receive one or the other first

- The nodes work on the first received block, however, they save the other branch in the case it becomes longer

- When the next proof-of-work is found and one branch becomes longer, the tie will be broken

- The nodes working on the other branch will then switch to the longer one

• Block broadcast are tolerant of dropped messages

• „If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.“ [1]

navy.cs.vsb.cz28

Incentive I

• The first transaction in a block = special transaction starting a new coin owned by the creator of the block

• The incentive for nodes to support the network is added

• The way to initially distribute coins into circulation is provided

• There is no central authority, which would issue the nodes

• Price: CPU time and electricity [1]

navy.cs.vsb.cz29

Incentive II

• Incentive can also be funded with transaction fees

• Inflation free – once predetermined number of coins have entered circulation

• Incentive helps encourage nodes to stay honest

• In the case of attack:

- Attacker would have to be able to assemble more CPU power than all the honest nodes

- In the case of the more CPU power the attacker had to defraud people by stealing back his payments or using them to generate new coins [1]

navy.cs.vsb.cz30

Disk Space Reclaiming I

• Transactions are hashed in a Merkle Tree with only the root included in the block‘s hash

• Old blocks compacted by stubbing off branches of tree

• It is not need to store the interior hashes

• A block header with no transactions – about 80 bytes

• „If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year.“ [1]

• Conclusion: „The storage should not be a problem even if the block headers must be kept in memory.“ [1]

navy.cs.vsb.cz31

Disk Space Reclaiming II

• Merkle Tree

- Used to sign a limited number of messages with one public key denoted as pub

- The number of possible messages must be a power of two => the possible number of messages is N=2n

- public keys and private keys

- For each public key Yi, a hash value hi=H(Yi) is computed

- With the hash values hi, the Merkle Tree is build

- Node denoted as ai,j, where i = level of the node (defined by distance from the leaf)

- Hash values hi = leafs of a Binary tree => hi=a0,i

- Each inner node of the tree is the hash value of the concatenation of its two children [6]

navy.cs.vsb.cz32

Disk Space Reclaiming III

Concatenation

a1,0 = H(a0,0 || a0,1)

a2,0 = H(a1,0 || a1,1)

• Example of Merkle Tree [6]

The root of the tree an,0 is the public key pub of the

Merkle Signature Scheme

navy.cs.vsb.cz34

Simplified Payment Verification I

• It is possible to verify payments without running a full network node

• User keeps a copy of the block headers of the longest proof-of-work chain.

Source: [1]

navy.cs.vsb.cz35

Simplified Payment Verification II

• In the case of attack:

– „The verification is reliable as long as honest nodes control the network.“ [1]

– Method can be fooled by attacker‘s fabricated transactions (when attacker can overpower the network)

• Defence:

– Accept alerts from network nodes in the case that they detect an invalid block

– Prompt the user‘s software to download the full block and alerted transactions to confirm the inconsistency

– „Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.“ [1]

navy.cs.vsb.cz36

Privacy

• Traditional banking model: limiting access to information

• In the case of Bitcoin network: breaking the flow of information in another place -> keeping public keys anonymous

• „The public can see that someone is sending an amount to someone else, however, there is no information linking the transaction to anyone.“ [1]

navy.cs.vsb.cz37

Bitcoin statistics I

• Time between blocks: 9.99 minutes

• Bitcoins mined: 1,687.5 BTC

• Total transaction fees: 133.23717552 BTC

• Market summary:

– Market price: 1,023.09 USD

– Trade volume: 31,334,413,91 USD

– Trade Volume: 30,627.08520592 BTC

• Information taken from [3]

navy.cs.vsb.cz38

Bitcoin statistics II

• Mining cost

– Total miners revenue: 1,862,786.87 USD

– % earned from transaction fees: 7.32 %

– % of transaction volume: 0.99 %

– Cost per transaction: 7.15 USD

• Hash Rate and Electricity Consumption

– Difficulty: 422,170,566,883

– Hash rate: 2,833,138,716 GH/s

• Information taken from [3]

navy.cs.vsb.cz39

Hash Rate

• Hash rate = the measuring unit of the processing power of the

Bitcoin network. When the network reached a hash rate of 10

Th/s, it meant it could make 10 trillion calculations per second [5]

navy.cs.vsb.cz40

Hash Rate Distribution

The market share of the most popular bitcoin mining pools.

navy.cs.vsb.cz41

Bitcoin Hardware

Source: https://www.hobbymining.com/mining-hardware/

• Bitcoin mining HW (bitcoin mining) X Bitcoin hardware wallets (bitcoin storing)

• ASICs and Rigs- more hashing power from graphic cards

- Graphic cards were surpassed by ASICs

- ASIC = Application Specific Integrated Circuits

• Bitcoin mining without HW• Less than one penny per month• More damage to the computer [7]

navy.cs.vsb.cz42

Bitcoin Hardware

Source: [7]

navy.cs.vsb.cz43

Most Efficient Bitcoin Hardware

Source: [7]

navy.cs.vsb.cz44

References

• [1] Nakamoto, Satoshi (24 May 2009). "Bitcoin: A Peer-to-Peer Electronic Cash System" (PDF). Retrieved 5 March 2014

• [2] Tasca, Paolo. "Digital currencies: Principles, trends,

opportunities, and risks." (2015)

• [3] https://blockchain.info

• [4] Wikipedia

• [5] https://bitcoin.org/• [6] Becker, Georg. "Merkle signature schemes, merkle

trees and their cryptanalysis." Ruhr-University Bochum,

Tech. Rep. (2008).

• [7] https://www.hobbymining.com/mining-hardware/

navy.cs.vsb.cz45

Conclusion

• Doplnim ja

46 navy.cs.vsb.cz

THANK YOU FOR YOUR ATTENTION

ivan.zelinka@ieee.org

www.ivanzelinka.eu

navy.cs.vsb.cz47

Copyright

This didactic material is meant for the personal use of the student only,and is copyrighted. Its reproduction, even for a partial utilization, isstrictly forbidden in compliance with and in force of the law on Authorsrights.

Copyright©NAVY.CS.VSB.CZ