O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Confira estes a seguir

1 de 31 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a Bitcoin (20)


Mais recentes (20)


  2. 2. OnlineTransactions ■ Physical cash – Non-traceable (mostly) – Secure (mostly) – Low inflation ■ Can’t be used online directly  Electronic credit or debit transactions  Bank sees all transactions  Merchants can track/profile customers
  3. 3. E-Cash ■ Secure ■ Low inflation ■ Privacy-preserving
  4. 4. E-Cash Crypto Protocols  Chaum82: blind signatures for e-cash  Chaum88: retroactive double spender identification  Brandis95: restricted blind signatures  Camenisch05: compact offline e-cash ■ Various practical issues: – Need for trusted central party – Computationally expensive – Etc.
  5. 5. Bitcoin ■ Proposed by Satoshi Nakamoto, 2008 ■ A distributed, decentralized digital currency system ■ Effectively a bank run by an ad hoc network – A distributed transaction log
  6. 6. Public & Private key: Encryption & Decryption ■ Key pair generation Message Encrypted Message Message Privat e Key Public Key Encryption Decryption
  7. 7. Public & Private key: Digital signature &Verification ■ Keys work inversely Message Message HashValue Signed Message Hash Privat e Key Sign Message HashValue Public Key Message Message HashValue Compose Verify (Encrypt) (Decrypt) Hash
  8. 8. Bitcoin ■ Electronic coin = chain of digital signatures ■ Bitcoin transfer: – message = Previous transaction + payee’s public key – Ownership verification – Sign[Hash(message)] with Payer’s private key Alice gets 5 BTC fromTx 0, and wants to sent it to Bob Tx 0 Bob’s Public Key Hash Alice’s Signature Alice’s Private Key Sign Tx 1 Alice’s Public Key Verify
  9. 9. Address 0xa8fc93875a972ea Signature 0xa87g14632d452cd Public key 0xc7b2f68...
  10. 10. Transaction (cont.) ■ Input: – Multiple inputs allowed – Refer to an output from previousTx – Special: generation transaction ■ Output: at most 2 – One for payment – One for change (return to payer) In Out Out 12.5 BTC In In In Out 0.5 BTC 0.1 BTC 0.2 BTC 0.8 BTC In (Gen) Out 12 BTC Tx 1 Tx 0 Tx 2
  11. 11. Double-spending ■ Payee cannot verify whether the payer double-spent the coin ■ Common solution: introduce trusted central authority (3rd party) ■ What about BTC? Mint Each transaction: A B return issue Only trust money from mint Check money
  12. 12. Avoid double-spending ■ Be aware of all transactions: publicly announce them! ■ Need a system agreed on a single history. ■ Each node (miner) verifies validity ofTxs. ■ Include validTxs into a block, attach it to the current chain.
  13. 13. Proof-of-Work ■ Pick a random node in proportion to some resource that no one can monopolize. ■ Proof ofWork: – in proportion to computing power. – Nodes compete for right to create a block – Make it relatively hard to create new blocks ■ Proof of Stake: in proportion to ownership.
  14. 14. Proof-of-Work ■ Cryptographic Hash Functions – Consistent: hash(X) always yields same result – One-way: givenY, hard to find X s.t. hash(X) =Y – Collision resistant: given hash(W) = Z, hard to find X s.t. hash(X) = Z ■ SHA-256 is used for PoW.
  15. 15. Proof-of-Work ■ Block:Txs + Prev Hash ■ Find a nonce such that Hash(Txs, prev hash, nonce) < E – Find a hash value whose leading bits are zero – The work is exponential in the number of zero bits required ■ Hard to find, easy to verify.
  16. 16. PoW Properties ■ Difficult to compute! – Only miners bother to compete – Say 1020 hashes per block (in August 2014) ■ Cost is parameterizable – Recalculate the target space every 2 weeks so amount of work to find a block increases. – Prob (Alice wins next block) = fraction of global hash power she controls ■ Key Security Assumption – Majority of miners weighted by hash power are honest
  17. 17. Block chain ■ A distributed timestamp server on a peer-to-peer basis ■ Longest chain – Has the greatest proof-of-work effort invested in it – Represent majority decision (One-CPU-one-vote)
  18. 18. Tie breaking ■ Two nodes may find a correct block simultaneously. – Keep both and work on the first one – If one grows longer than the other, switch to work on the longer one
  19. 19. Bitcoin Network ■ Each P2P node runs the following algorithm: 1. New transactions are broadcast to all nodes. 2. Each node (miners) collects new transactions into a block. 3. Each node works on finding a proof-of-work for its block. 4. When a node finds a proof-of-work, it broadcasts the block to all nodes. 5. Nodes accept the block only if all transactions in it are valid (digital signature checking) and not already spent (check all the transactions). 6. Nodes express their acceptance by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
  20. 20. Reverting is Hard ■ Reverting gets exponentially hard as the chain grows. 1. Modify the transaction (revert, change the payer, etc.) 2. Recompute nonce 3. Recompute the next nonce
  21. 21. 51% Attack ■ The attacker with >= half of all the computation power can succeed. ■ Gambler’s Ruin problem 0 1 2 3 P(right) = p P(left) = 1-p = q P(n) = P(1)n (prob. that move from n to 0) cliff P(1) = 1-p+p*P(2) P(2) = P(1)2 P(1) = (1-p)/p = q/p p<=0.5, then P(1)>=1 p>0.5, P(1)<1, the larger n, the safer
  22. 22. 51% Attack (cont.) ■ BTC: if attacker is behind the longest chain by z blocks ■ Actually, 50% will do… (as long as p<= 0.5, P(1)>=1) ■ If honest is the majority: the larger the z, the safer 0 z … z+1 honest node (p) attacker node (q)
  23. 23. Vanishing chance ■ Simulation result: P(Attacker succeed) drop off exponentially with z
  24. 24. Practical Limitation ■ At least 10 mins to verify a transaction. – Agree to pay. – Wait for 1 block (10 mins) for the transaction to go through. – But for a large transaction ($$$) wait longer. ■ More block attached, more secure ■ For large $$$, wait for 6 blocks (1 hour).
  25. 25. Incentives ■ For miners – N new BTC reward for each new block ■ N starts from 50, halved every 210k blocks (~4 yrs) ■ Total BTC amount will not exceed 21 million – Transaction fees ■ Encourage nodes to stay honest – Attacker succeed when >= 50% CPU power – Find more profit when playing by the rules
  26. 26. Privacy ■ Anonymous public key ■ A new key pair for each transaction – Avoid linking to a common owner
  27. 27. A final word… ■ Distributed currencies are good or bad? ■ A future world without governments Q&A
  28. 28. Optimizations ■ MerkleTree (Hash tree) – Block header only contains the root hash – Block header is about 80 bytes – 80 bytes * 6 per/hr * 24 hrs * 365 = 4.2 MB/year
  29. 29. Simplified payment verification ■ Get the longest proof-of-work chain. ■ Query the block thatTx3 is in. ■ Only need Hash01 and Hash2 to verify. VerifyTx3
  30. 30. Reclaiming Disk Space ■ Prune spent transactions – A leaf (Tx) can be pruned when all of its outputs have been spent.

Notas do Editor

  • Ownership verification: when Bob wants to spend the money, other’s will use Alice’s public key to verify this transaction
  • Block contains transactions to be validated and previous hash value.

    Pick a nonce such that H(prev hash, nonce, Tx) < E. E is a variable that the system specifies. Basically, this means to finding a hash value who’s leading bits are zero. The work required is exponential in the number of zero bits required.

    the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases. (Remain the same average speed even the computation power becomes higher and higher) ~1 block/10mins

    It’s hard to find the nonce value satisfy the requirement, but once found, it can be easily verified by other nodes (just doing the hash) due to the asymmetry property of hash functions. Anybody can verify that a miner has computed the nonce
  • Majority decision making: one-CPU-one-vote
    Majority computation power controlled by honest nodes, then honest chain grow fastest
    Nodes work on the longest chain
  • 1. But in reality, new transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long.
    4. Block broadcasts are also 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.
  • Probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.
  • Slow
  • The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party.
    The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone.

    Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.
  • Depends on who’s using it!

    Crime is bad! Tax evasion is bad! But sometimes governments are bad too!
  • Any user can verify a transaction easily by asking a node.
    Only need Hash01 and Hash2 to verify; not the entire transactions.