IS3101 Cryptocurrency & Blockchain
Lecture 2 History of payment systems and the road to Bitcoin
● Con’t. Lecture 1, Slide 46 – 81
Copyright By PowCoder代写 加微信 powcoder
● 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代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com