In this portion of the lecture,
we'll begin looking at the history
of payment systems that were
invented prior to Bitcoin.
We're going to start by looking
at credit based systems.
In general, what you can do is
you can take all the systems and
sort them into two piles.
There's pile based on credit systems and
there's piles based on cash systems.
Bitcoin obviously is in
the pile of cash systems.
However, we should also look at credit
based systems, even though Bitcoin's not
part of that pile because these are the
systems that are competing with Bitcoin.
Credit card transactions are the dominant
payment method that is used on
the web today.
If you've ever bought something
from a website such as Amazon,
you know how the arrangement goes.
You type in your credit card details,
you send it to Amazon and
then Amazon turns around with
these credit card details and
they talk to the system,
the financial system.
We don't have to go into all
the details of who the parties are that
are involved in the financial system.
But in general there's a credit card
processor and the credit card processor is
going to talk to the banks, the credit
card companies, and other intermediaries.
The other architecture that you may see
if you use something like PayPal is
an intermediary architecture.
In this case there's a company that
sits between you and the website.
So, you send your credit card details to
this company, it approves the transaction,
and settles with the website.
The advantages of this type
of architecture are privacy.
In this case,
the user is never fully disclosing all
their credit card details to the website.
The drawback is that
the user's no longer directly
interacting with the website alone.
The user has to interact
with his intermediary.
They have to be aware that
the intermediary exists.
They may have to have an account
with the intermediary.
Now an early system to use this type
of architecture was a company called
FirstVirtual.
It was founded in 1994.
FirstVirtual is an interesting company
because beyond just being one of
the earliest players in doing electronic
payments they were also one of
the earliest companies to try and
set up a virtual office as it was called.
And that's why they called
their company FirstVirtual.
So in a virtual office there was no
physical office where people met.
People were scattered
across the country and
they communicated through
email on the internet.
Now remember, in 1994 this was before
the days of GitHub and Skype and Slack.
And so it was very hard to
run a business this way.
And they have an interesting paper
outlining some of the challenges of that
business model.
But anyways,
back to what they actually propose.
What they propose is a system
where both the user and
the merchant sign up with FirstVirtual,
they have an account, and
then they conduct transactions of
electronic payments over email.
The idea is that one you put something in
your cart and say I'd like to check out,
what the merchant will do is they'll
send an email to transfer@card.com,
which is an email address
run by FirstVirtual.
And it will have all
the details of the transaction.
The user is then sent an email with
the transaction details asking them to
approve it.
If the user emails back yes,
then FirstVirtual will bill
their credit card of the user.
A credit card that the user had provided
when they enrolled in the service.
Then what will happen is FirstVirtual
will wait to see if the user will dispute
the credit card change.
The user typically had 90
days to file a dispute.
And so FirstVirtual will
ride out these 90 days and
it's only on the 91st day that
the merchant actually gets paid the money.
This is a major drawback of this system,
having to wait that long to receive
payment if you're a merchant.
However, amazingly, it's not that much
different than what happens today.
Today, the merchant does get
paid immediately, however,
there still is the threat that
the customer will file a charge back, or
dispute the credit card statement.
And in this case,
the merchant will have to pay the money
back to the credit card company.
Two other systems who use this
architecture are OpenMarket and NetBill.
And when you look at
these early protocols,
what is interesting is to drill down and
see at a protocol level what protocols
they are using to send
transactions back and forth.
FirstVirtual, as mentioned,
was based on email.
There were other competing approaches.
In OpenMarket, it was based on encoding
information into the URL For NetBill,
they use a custom MIME type over HTTP.
In the mid 90s there was
also competing approach
to the FirstVirtual intermediary
based architecture.
We'll call it the SET architecture.
Like the intermediary architecture,
it also tries to dress the problem
of users not sending all of their credit
card information to the merchants.
It's actually remarkable that no one
thought that was a good idea in the 90s.
It wasn't until much later that
that system became predominant.
In this system, it also tried to
address the idea of the user having to
enroll with the intermediary.
So, what they decided to pursue is
an architecture, where the user,
once they've settled on
the transaction that they want to
conduct with the website,
they only interact with the website.
However, what they do is they take their
view of what the transaction details
are and they encode their credit card
information, and they encrypt it such that
some server, some third party can decrypt
it but the merchant cannot decrypt it.
They send it to the merchant, and
the merchant takes this information
since it can't decrypt it.
All it can do is blindly forward
it on to the third party.
However, they also append their own
view of what the transaction looks like.
Then the third party can
decrypt both of these.
They can compare the views of
the transactions, and if they align,
they both say the same thing,
then they'll approve the transaction.
Now SET was a standard that
was developed by Visa and
MasterCard in conjunction with a lot
of technology companies at the time.
Netscape, Microsoft, Verisign, RSA.
SET was sort of had some
intellectual ancestors.
There was another company at
the time called CyberCash.
IBM had a proposal called IKP
that was later standardized
into a standard Called SEPP.
And Microsoft working with Visa has
also developed their own standard.
All of these use that same architecture
that we just described, and so
the idea of SET was to unify this
architecture, provide a specification
where all of these systems would
fit under the umbrella of SET.
Now CyberCash is the one company that went
into SET is an interesting company that
we'll spend a few minutes looking at.
CyberCash had very good relationships
with the US government.
In addition to their product that was
based on credit cards, they also had
a coin-based system, a digital
cash-based system called CyberCoin.
CyberCoin was a micropayment system,
so what that meant is you probably
never have more than ten dollars in
your account at any one given time.
However what CyberCash was able to
do is they were able to actually
get FDIC insurance for
each account for up to $100,000.
Back in the 90s when
CyberCash was operating
there was also a restriction
on the export of cryptography.
Cryptography was considered a weapon and
so
you couldn't export it to other nations.
In this case CyberCash wanted
to export their software.
They wanted other people around
the world to be able to use it.
However it used the encryption technology.
So normally this export would not be
allowed, however what CyberCash was able
to do, is work with the state of
department to get a special exemption for
their software.
And the argument was,
that going into their software and
extracting the encryption technology out
of it would be way more work than it
would take to just to write
the crypto from scratch.
Also leading into the year 2000 there
was a lot of concern over a bug called
the Y2K bug.
The Y2K bug didn't turn out
to be that big of a deal.
There weren't a lot of systems that
were influenced or effected by the bug.
However, CyberCash has the dubious
distinction of being one that was
effected by it.
And their payment processor
software exhibited double
payments as a result of this bug.
They later went bankrupt in 2001.
Their intellectual property was acquired
by Verisign, who then turned around and
sold it to PayPal, where it lives today.
So, let's think about why the SET
architecture didn't work.
The big problem, probably the fundamental
problem of the SET architecture,
has to do with a subject of
distributing public keys to
all the people that need
public keys in the protocol.
This is called PKI, or
Public Key Infrastructure.
And a nice way of thinking about
this was actually developed by iKP,
the IBM project that was one
of the predecessors to SET.
What iKP did is they came up
with three levels of security.
In the most basic security, only
the processor had to have a public key.
Now, they had to have more than a public
key, this public key had to be bound
to their identity in something
called a certificate, so
we can think of these as certificates.
On the second level of security,
all the merchants also had
to acquire certificates.
And in the third level of security-
the highest level of security,
not only did the processor and all the
merchants have to have certificates, but
they suggested that all users also
have to go and acquire a certificate.
Now these certificates are used so
that everybody in the protocol
has signing keys.
And essentially what happens is
every time you do a transaction,
everybody signs everything they do,
and if there's disputes later,
then there's a record of who
said what about the transaction.
So it's used to keep everybody
accountable in the protocol.
CyberCash always required level three.
And when the standardization
SET came along,
they decide that level
3 was the best level.
This is the level where; as I mentioned,
all users have to go and
acquire certificates.
Now this was a disaster.
Users don't want go and
acquire certificates, it's complicated,
you have to deal with
the certificate authority.
In these days,
it wasn't an automated process.
You have to send enough information about
who you are so that you could be granted
the certificates, and so that's a big
reason why the SET architecture failed.
Some other points of interest about SET,
it was,
as I mentioned SET is not a system itself.
It is an attempt at standardization.
It was done in 1996.
Around the same time, another group,
the World Wide Web Consortium,
were also looking at
standardizing financial payments.
They took a different approach, they
thought it would be interesting to extend
HTTP the protocol is
sort of arbitrary ways.
And they had a very general proposal for
how you might extend it, and
one of the use cases that
they had was doing payments.
This never happened, essentially
this was never actually deployed,
the whole extension framework
was never deployed, and so
this was another standardization
attempt that failed.
At the time that we're
recording this lecture in 2015,
the W3C has recently came out and
said that they would like to
do another attempt at
standardizing financial systems.
And in this case, Bitcoin will
be part of that standardization.
However, given the past failures,
they have a tough hill to climb.