[SOLVED] CS IS3101 Cryptocurrency & Blockchain

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

Cont. Lecture 1, Slide 46 81

Copyright By Assignmentchef assignmentchef

Begin Lecture 2, History of payment systems and the road to Bitcoin
Tutorial: Cont. Tutoiral. 1s 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, CAFE, 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
CyberCashs 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 doesnt 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 senders 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]