[SOLVED] CS代考 IS3101 Cryptocurrency & Blockchain

IS3101 Cryptocurrency & Blockchain
Lecture 2 History of payment systems and the road to Bitcoin

● Con’t. Lecture 1, Slide 46 – 81

Copyright By PowCoder代写加微信 assignmentchef

● Begin Lecture 2, History of payment systems and the road to Bitcoin
● Tutorial: Con’t. Tutoiral. 1’s Activity 3 last questions

History of Cryptocurrencies ● Digital cash and payment systems prior to
● Bitcoin: proposals & ventures
● [In next lecture]
○ The history of other Bitcoin dependencies: ○ Proof of work and secure time-stamping
○ What we can learn about Satoshi from this history

Many Schemes
● ACC, Agora, AIMP, Allopass, b-money, Bitbit, Bitgold, Bitpass, C-SET, CAFÉ, CheckFree, ClickandBuy, ClickShare, CommerceNet, CommercePOINT, CommerceSTAGE, Cybank, CyberCash, CyberCents, CyberCoin, CyberGold, DigiGold, Digigold, Digital Silk Road, e-Comm, E-Gold, Ecash, eCharge, eCoin, Edd, eVend First Virtual, FSTC Electronic Check, Geldkarte, Globe Left, Hashcash, HINDE, iBill, iKB, IMB-MP, InterCoin, Ipin, Javien, Karma, LotteryTickets, Lucre, MagicMoney, Mandate, MicroMint, Micromoney, MilliCent, Mini-Pay, Minitix, MobileMoney, Mojo, Mollie, Mondex, MPTP, Net900, NetBill, NetCard, NetCash, NetCheque, NetFare, No3rd, One Click Charge, PayMe, PayNet, PayPal, PaySafeCard, PayTrust, PayWord, Peppercoin, PhoneTicks, Playspan, Polling, SET2Go, SubScrip, Trivnet, TUB, Twitpay, VeriFone, VisaCash, Wallie, Way2Pay, WorldPay, X-Pay

Traditional Financial Arrangements

1 has food and wants to have a tool
2 has a tool and wants to have medicine

1 has food and wants to have tool
2 has a tool and wants to have medicine

Person 2 has a tool and wants to have medicine
Person3 has medicine and wants food
1 has food and wants to have tool

2 has a tool and wants to have medicine
Person3 has medicine and wants food
Coordination problem
1 has food and wants to have tool

1 has food and wants to have tool
Christina has medicine
Person 2 has a tool and wants to have medicine
and wants food
Credit System

2 has a tool and wants to have medicine
1 has food and wants to have tool
Person3 has medicine and wants food

Cancel Debt

2 has a tool and wants to have medicine
3 has medicine and wants food
1 has food and wants to have tool

2 has a tool and wants to have medicine
3 has medicine and wants food
1 has food and wants to have tool
Cash value

Value of the tool
1 has food and wants to have tool
2 has a tool and wants to have medicine
3 has medicine and wants food

Money swap
2 has a tool and wants to have medicine
3 has medicine and wants food
1 has food and wants to have tool

1 has food and wants to have tool
2 has a tool and wants to have medicine Person3 has medicine and wants food

● Cash requires an initial allocation ● Credit acquires risk
● Cash allows fine-grained precision of value
● Combined: cash allows credit to be quantified
Cash vs Credit

P2P File-Sharing
● Mojo Nation & Karma: P2P file-sharing services
● Users are allocated Mojo/Karma (tokens/money/credits) upon joining
● Spend to download files, receive to share files
● Solves free-loading and barter coordination

Credit Card Payment Systems
• Creditsystem:competing • Cashsystem:Bitcoin

The trouble with credit cards online
● Fraudulent transactions
● Lose your credit card information

Credit card and payment details
Web payment

Financial system Credit card processor
Credit card and payment details
Amazon website

system Credit card processor
Merchant Bank
Card Issuing Bank Credit Card Company
Credit card and payment details
Amazon website

Intermediary approach

Credit card and payment details
Amy paid for your item x
Amazon website
Intermediary architecture

FirstVirtual (1994)
● One of the earliest credit card systems (& aside: earliest virtual offices)
● Both user and merchant must be enrolled
● Transactions occur over email:
● the merchant emails the details
● the user is sent an email for confirmation
● the user responds with Yes/No/Fraud
● if yes, users’ Credit Card is billed
● ~91 days later the merchant receives payment
● OpenMarket was a similar scheme that used URL encodings instead of email;
● NetBill used a custom MIME type over HTTP

eCommerce Website
Competing approach
SET Intermediary

eCommerce Website

CyberCash: Points of interest
● CyberCoin was a micropayments version of CyberCash
● The money was backed by US FDIC insurance in for up to $100K
● CyberCash’s software was given special exemption from export laws by the US Department of State (thought to be harder to extract than to write from scratch)
● Y2K issues with their payment processor (customers were double-billed)
● Bankrupt in 2001; assets now owned by PayPal

SET: Post-Mortem ● Who needs public key certificates?
● iKP defined 3 levels (each increases accountability): 1. Just the processor
2. Processor and all merchants
3. Processor, all merchants, and all users
● CyberCash used(3), then SET effectively did too
● Requiring all users to obtain certificates was a disaster

Points of interest
● 1996: SET was a standard, not a system
● 1995+: W3C attempted to extend HTTP with payment negotiation
● Fall 2015: W3C is moving again toward payment standardization, including Bitcoin

From Credit to (Crypto) Cash

● Parallel research into building cash-like systems:
1. Higher anonymity
2. Offline transactions
● More extreme vision than Bitcoin

Chaum (1983)
● Imagine I hand you a $100 bill and a “contract” that says you will pay $100 to whoever brings the contract back to you
● You sign the contract
● It is effectively worth $100

Chaum (1983)
● If we do this digitally, a problem emerges
● Digital documents can be copied, and thus spent more than once (double-spending)
● First attempt at a fix: serial number
● This introduces a problem: traceability

Blind Signatures
● Imagine if I printed the contract in invisible ink and you sign it
● Later I reveal the ink and it looks like a normal signed document
● While invisible, it is hiding and binding

Blind Signatures
● Solves the traceability problem: you do not see the serial number
● Creates an even bigger problem: you have no idea what it says (it might say you will pay $1M)
● How can I convince you to sign?

Cut and Choose
● I create 100 invisible ink contracts with different serial numbers
● You choose one at random, reveal the ink, and see it encodes $100
● You choose another and another until there is one left
● You are pretty sure the one left encodes $100 and sign it

Back to double spending
● You keep a list of all serial numbers for contracts (coins) you have issued
● You stay online and a transaction is not complete until you state that the coin has not been spent
● The coin must now be purged

Chaum, Fiat, Naor (1988)
● Preventing offline double-spending seems hard
● We detect, not prevent, bad cheques
● What if we just detect double-spending and can determine who did it?

Chaum, Fiat, Naor (1988) ● Coins have serial numbers
● If serial numbers can be mapped to IDs: no anonymity
● If serial numbers are random and not correlated to IDs: full anonymity
● Is there a middle ground?

Chaum, Fiat, Naor (1988)
● Imagine two serial numbers that both look random but when added together reveal the ID
● Secret sharing: m-out-of-n shares recovers the secret for any m or n
● In this case, it is 2-out-of-2 sharing of the ID

Chaum, Fiat, Naor (1988)
● Idea: print two shares on the coin (the bank checks these add up during cut & choose)
● When I spend my coin, I leave both serial numbers hidden initially
● But then the receiver chooses one at random and I reveal it

Chaum, Fiat, Naor (1988) ● If I single-spend, one share does not reveal my ID
● If I double-spend, the second receiver will pick a random share to reveal:
○ 50% it is the same share. And I stay anonymous (the banks still detects the double-spend but doesn’t know who did it)
○ 50% it is the other share and my ID is blown (to the bank)

Chaum, Fiat, Naor (1988)
● We can boost the probability with repetitions: Albert 31337

Chaum, Fiat, Naor (1988) ● We can boost the probability with repetitions:

Chaum, Fiat, Naor (1988) ● We can boost the probability with repetitions:

Chaum, Fiat, Naor (1988)
● We can boost the probability with repetition:
● Pr[caught]=1-2(-N) = 99.999% (N=20)
● Coin can be spent one-time: they encode the original sender’s ID

Improvements
● Efficiency:20 x 2 = 40 x 100 = 4000 serials
● Replace cut & choose with ZKPs
● [Chaum, Pedersen; Brands;,
Hohenberger & Lysyanskaya]
● Divisible coins [Okamoto &. Ohta]

DigiCash (1989 – 98) ● Deployment of Chaum: ecash & cyberbucks
● Available from banks in US and Finland
● Clients are anonymous, merchants are not (they must redeem coins)

DigiCash: Variants
● MagicMoney: cypherpunks implementation for testing
● Lucre: implementation that side-steps patent on blind sig [Laurie]
● HINDE: enables merchant to provide change to an anonymous payer [Goldberg]

DigiCash: Post-Mortem
● Hard to persuade banks and merchants – low user demand
● User-to-user was not strongly supported (only senders were anonymous)
● Credit cards won the day

Tamper-Resistant Hardware
● DigiCash experimented with secure hardware ● Prevents, not just detects, double-spending
● Others: Mondex (MasterCard), VisaCash, CAFE

Mondex: Post-Mortem
● Many trials including Guelph, Ontario
● Lost, stolen, malfunctioning cards created issues
● Wallet was clunky & slow, retailers hated having multiple terminals
● Smart card technology -> Chip & PIN

● Traditional Financial Arrangements
● Credit Card Payment Systems
● From Credit to (Crypto) Cash
● [In next lecture]
○ The history of other Bitcoin dependencies:
○ Proof of work and secure time-stamping
○ What we can learn about Satoshi from this history
● History of Cryptocurrencies

Tutorial Exercise

References
● Building blocks of blockchains
○ Internet networking & TCP/IP ○ Databases
● Narayanan et al. Preface, Ch 1 ○ Hashing algorithms (1.1) ○ Merkle trees(1.2)
○ Digital signatures (1.3)
○ Asymmetric key cryptography (public and private keys) (1.4) ○ Ledgers & distributed ledgers (1.5)
● Blockchain Infrastructure Landscape: A First Principles Framing,Conaghy

程序代写 CS代考加微信: assignmentchef QQ: 1823890830 Email: [email protected]