Many people have heard of Bitcoin that

it's a fully digital currency with no government to issue it;

and that no banks need to manage accounts and verify transactions;

and also that no one really knows who invented it.

And yet, many people don't know the answer to this question, at least not in full.

To get there,

and to make sure that the technical details underlying the answer actually feel motivated,

what we're going to do is walk through step by step

how you might have invented your own version of Bitcoin.

We'll start with you keeping track of payments with your friends using a communal ledger.

And then, as you start to trust your friends and the world around you less and less,

and if you're clever enough to bring in a few ideas from cryptography

to help circumvent the need for trust,

what you end up with is what's called a "cryptocurrency".

You see, Bitcoin is just the first implemented example of a cryptocurrency.

And now, there are thousands more on exchanges with traditional currencies.

Walking the path of inventing your own can help to set the foundations

for understanding some of the more recent players in the game

and recognizing when and why there's room for different design choices.

In fact, one of the reasons I chose this topic is that

in the last year, there's been a huge amount of attention and investment

and, well, honestly hype directed at these currencies.

And I'm not going to comment or speculate on the current or future exchange rates,

but I think we'd all agree that

anyone looking to buy a cryptocurrency should really know what it is.

And I don't just mean in terms of analogies with vague connections to gold mining,

I mean an actual direct description of what the computers are doing

when we send, receive and create cryptocurrencies.

One thing worth stressing, by the way, is that

even though you and I are going to dig into the details here,

and that takes meaningful time,

you don't actually need to know those details if you just want to use the cryptocurrency,

just like you don't need to know the details of what happens under the hood when you swipe a credit card.

Like any digital payment, there're lots of user-friendly applications that

let you just send and receive the currencies without thinking about what's going on.

The difference is that the backbone underlying this

is not a bank that verifies transactions.

Instead, it's a clever system of decentralized trust-less verification

based on some of the math born in cryptography.

But to start,

I want you to actually set aside the thought of cryptocurrencies and all that just for a few minutes.

We're going to begin the story with something more down-to-earth: ledgers and digital signatures.

If you and your friends exchange money pretty frequently,

you know, paying your share of the dinner bill and such,

it can be inconvenient to exchange cash all the time.

So you might keep a communal ledger

that records all of the payments that you intend to make some point in the future.

You know, Alice pays Bob $20,

Bob pays Charlie $40, things like that.

This ledger is going to be something public and accessible to everyone,

like a website, where anyone can go and just add newlines.

And let's say that at the end of every month,

you all go together, look at the list of transactions and settle up.

If you spent more than you received, you put that money in the pot;

and if you received more than you spent, you take that money out.

So the protocol for being part of this very simple system might look like this:

anyone can add lines to the ledger;

and at the end of every month you all get together and settle up.

Now, one problem with a public ledger like this is that anyone can add a line,

so what's to prevent Bob from going in writing "Alice pays Bob $100" without Alice approving?

How are we supposed to trust that all of these transactions

are what the sender meant them to be?

Well, this is where the first bit of cryptography comes in: digital signatures.

Like handwritten signatures,

the idea here is that Alice should be able to add something next to that transaction

that proves that she has seen it and that she's approved of it.

And it should be infeasible for anyone else to forge that signature.

At first, it might seem like a digital signature shouldn't even be possible.

I mean, whatever data makes up that signature can just be read and copied by a computer,

so how do you prevent forgeries?

Well, the way this works is that everyone generates what's called a "public key - private key pair",

each of which looks like some string of bits.

The "private key" is sometimes also called a "secret key",

so that we can abbreviate it as "sk", while abbreviating the public key is "pk".

Now as the name suggests, this secret key is something you want to keep to yourself.

In the real world, your handwritten signature looks the same no matter what document you're signing.

But a digital signature is actually much stronger,

because it changes for different messages.

It looks like some string of ones and zeros, commonly something like 256 bits;

and altering the message even slightly

completely changes what the signature on that message should look like.

Speaking a little more formally,

producing a signature involves a function that depends both on the message itself and on your private key.

The private key ensures that only you can produce that signature,

and the fact that it depends on the message

means that no one can just copy one of your signatures and then forge it on another message.

Hand-in-hand with this is a second function used to verify that a signature is valid.

And this is where the public key comes into play.

All it does is output "true" or "false"

to indicate if this was a signature produced by the private key

associated with the public key that you're using for verification.

I won't go into the details of how exactly both these functions work,

but the idea is that it should be completely infeasible to find a valid signature

if you don't know the secret key.

Specifically, there's no strategy better than just guessing and checking random signatures,

which you can check using the public key that everyone knows.

Now think about how many signatures there are with a length of 256 bits,

that's 2^256.

This is a stupidly large number.

To call it astronomically large would be giving way too much credit to astronomy.

In fact, I made a supplemental video devoted just to illustrating what a huge number this is.

Right here, let's just say that

when you verified that a signature against a given message is valid,

you can feel extremely confident that the only way someone could have produced it

is if they knew the secret key associated with the public key you used for verification.

Now making sure that people sign transactions on the ledger is pretty good,

but there's one slight loophole:

if Alice signs a transaction, like "Alice pays Bob $100",

even though Bob can't forge Alice's signature on a new message,

he could just copy that same line as many times as he wants.

I mean, that message-signature combination remains valid.

To get around this, what we do is make it so that when you sign a transaction,

the message has to also include some sort of unique ID associated with that transaction.

That way, if Alice pays Bob $100 multiple times,

each one of those lines on the ledger requires a completely new signature.

All right, great!

Digital signatures remove a huge aspect of trust in this initial protocol,

but even still, if you were to really do this,

you would be relying on an honor system of sorts.

Namely, you're trusting that everyone will actually follow through

and settle up in cash at the end of each month.

What if, for example, Charlie racks up thousands of dollars in debt

and just refuses to show up.

The only real reason to revert back to cash to settle up

is if some people (I'm looking at you, Charlie) owe a lot of money.

So maybe, you have the clever idea that you never actually have to settle up in cash,

as long as you have some way to prevent people from spending too much more than they take in.

Maybe what you do is start by having everyone pay $100 into the pot,

and then have the first few lines of the ledger read

"Alice gets $100", "Bob gets $100", "Charlie gets $100", etc.

Now, just don't accept any transactions

where someone is spending more than they already have on that ledger.

For example, if the first two transactions are

"Charlie pays Alice $50" and "Charlie pays Bob $50",

if he were to try to add "Charlie pays you $20", that would be invalid,

as invalid as if he had never signed it.

Notice, this means that verifying a transaction

requires knowing the full history of transactions up to that point.

And this is more or less also going to be true in cryptocurrencies,

though there is a little room for optimization.

What's interesting here is that

this step removes the connection between the ledger and actual physical US Dollars.

In theory, if everyone in the world was using this ledger,

you could live your whole life just sending and receiving money on this ledger

without ever having to convert to real US Dollars.

In fact, to emphasize this point,

let's start referring to the quantities on the ledger as "ledger dollars", or "LD" for short.

You are, of course, free to exchange ledger dollars for real US Dollars.

For example, maybe Alice gives Bob a $10 bill in the real world

in exchange for him adding and signing the transaction

"Bob pays Alice 10 LD" to this communal ledger.

But exchanges like that, they're not going to be guaranteed by the protocol.

It's now more analogous to how you might exchange dollars for Euros,

or any other currency on the open market,

it's just its own independent thing.

This is the first important thing to understand about Bitcoin or any other cryptocurrency:

what it is is a ledger, the history of transactions is the currency.

Of course, with Bitcoin,

money doesn't enter the ledger with people buying in using cash.

I'll get to how new money enters the ledger in just a few minutes,

but before that, there's actually an even more significant difference

between our current system of ledger dollars and how cryptocurrencies work.

So far, I've said that this ledger is in some public place,

like a website, where anyone can add newlines.

But that would require trusting a central location,

namely "who hosts the website?",

"who controls the rules of adding new lines?".

To remove that bit of trust, we'll have everybody keep their own copy of the ledger.

Then when you want to make a transaction, like Alice pays Bob 100 LD,

what you do is broadcast that out into the world

for people to hear and to record on their own private ledgers.

But, unless you do something more, this system is absurdly bad.

How could you get everyone to agree on what the right ledger is?

When Bob receives a transaction, like Alice pays Bob 10 LD,

how can he be sure that everyone else received and believes that same transaction

that he'll be able to later on go to Charlie and use those same 10 LD to make a transaction?

Really, imagine yourself just listening to transactions being broadcast,

how can you be sure that everyone else is recording the same transactions and in the same order?

This is really the heart of the issue.

This is an interesting puzzle.

Can you come up with a protocol for how to accept or reject transactions

and in what order so that you can feel confident that

anyone else in the world who's following that same protocol

has a personal ledger that looks the same as yours?

This is the problem addressed in the original Bitcoin paper.

At a high level, the solution that Bitcoin offers is

to trust whichever ledger has the most computational work put into it.

I'll take a moment to explain exactly what that means,

it involves this thing called a "cryptographic hash function".

The general idea that we'll build to

is that if you use computational work as a basis for what to trust,

you can make it so that fraudulent transactions and conflicting ledgers

would require an infeasible amount of computation to bring about.

Again, I'll remind you that this is getting well into the weeds

beyond what anyone would need to know just to use a currency like this,

but it's a really cool idea!

And if you understand it, you understand the heart of Bitcoin and all other cryptocurrencies.

So first things first, what's a hash function?

The inputs for one of these functions can be any kind of message or file,

it really doesn't matter.

And the output is a string of bits with some kind of fixed length, like 256 bits.