Commons license.

Your support will help MIT OpenCourseWare

continue to offer high-quality educational resources for free.

To make a donation, or to view additional materials

from hundreds of MIT courses, visit MIT OpenCourseWare

at ocw.mit.edu.

TADGE DRYJA: Today we're going to talk about wallets and SPV.

And if you don't know what SPV stands

for, that will be defined as well, so don't worry.

First, you get your software.

That's something of a problem, like how

do you know you got the right Bitcoin software,

there can be issues there, but anyway--

there are multiple implementations that

should be consensus compatible.

I often use BTCD, which is a version written in Go,

but the main implementation is written in c++.

So, you get the software, and then

you somehow connect to peers in the network,

but there's all these asterisks, which

mean it's not completely decentralized.

You have to find where to get it,

you have to find who to connect to.

Once you do that, you get all the headers, which

are 80 bytes each, you verify all the work,

and then you start getting the blocks,

looking through the transactions.

You replay the history of the last nine years of the coin,

and then you arrive at a UTXO set,

an unspent transaction output set,

and it should be the same as everyone else got.

Everyone else has the same headers, the same work,

the same transactions.

They'll get the same set of which coins are encumbered

by which keys as you do.

And the idea is it would be very expensive to have

different UTXO sets because you'd have to do all that work.

So that's how a node works.

But what about dealing with actual money?

So far, we've just looked at here's

how to get your node running, here's

how to observe the network and come

to the same conclusion as everyone else,

but you probably want to actually do something

with this.

You want to pay people or get paid.

Those are the two fundamental functions

that this tries to address.

So the software that manages this feature is called

a wallet, and it's not necessarily

the same software as what's connecting to the network,

downloading, and verifying.

In the case of Bitcoin Core, it is,

although many of the programmers of Bitcoin Core wish that it

weren't.

And there's sort of a long-term goal

of, it'd be really great if we could pull these two

things apart into maybe separate binaries, separate programs,

something.

But they're really intertwined, and it's kind of ugly.

But there are other things that are separate

OK, so wallet software functionality-- seems simple,

you send and receive money.

Simple.

Of course, you need to receive money before you can send it,

so let's start with that.

OK, so we did not talk about receive addresses.

We did talk about the script, and how it's generally

used pay to pubkey hash, where you put the hash of your pubkey

in your output script, and then in your redeem script,

in your input, you put the pubkey

itself, which is then checked against the hash,

and then the signature is verified.

Most likely, if you've looked at Bitcoin at all,

you've seen these types of addresses.

They usually start with 1, they're a bunch of characters

long, a weird mix of lowercase, uppercase, Latin numbers,

and letters.

There is a standard for converting a 20-byte pubkey

hash into this address.

So the idea is since almost everything

is using the same pubkey hash script,

you can forget about the opcodes,

like op_dup, op_hash160, op_equalverify

because they're always the same.

And so it's this standard, like, OK we're just

taking that 20-byte hash, and now

let's convert it to something hopefully somewhat

human readable and writeable so that people can write it down,

say it over the phone.

This is the one Satoshi made.

It's got 58 characters and then the last 4 bytes,

which ends up being like 5 or 6 of the letters,

is sort of a checksum, where you take

the hash of the first however many letters

and then that's supposed to like equal to the next one.

So, hopefully, if you typed something wrong,

it doesn't change the hash and then

you send it to the wrong place and then no one has

a matching key for that.

There's a newer standard for this

where all the all the letters are lowercase.

That's introduced, actually, today in Bitcoin Core.

Version 0.16 came out, and so there's

a new standard called Bech32.

They did some research, and they found

it was actually much faster to transmit over

the phone via voice because you didn't

have to say whether things were uppercase or lowercase,

which ended up being very annoying for people,

because, you know, 1 big F, a little f, 1, 2, big E, 4--

it's annoying.

Anyway, the idea is this is just an encoding

of the 20-byte pubkey hash, so when you type this

into a program, it reads this, converts it

into a 20-byte hash, builds the output script.

OK, so the outputs are all the same.

So this is sort of like a UI thing.

The addresses don't really exist at the protocol level.

Any questions about addresses?

OK.

We're not going to put--

UI and usability is super important, but not

the focus yet of what we're doing.

The idea, in a lot of cases, is you

want to receive money and know that you received it,

or somehow interact with people over computers,

and you could put a bunch of addresses on a server,

but keep your private keys offline.

Because if you keep both your public key and your private key

on the same computer, that's kind of an attractive target

for someone to break into your system because they say,

oh, this guy's running Bitcoin and he's accepting payments.

There might be a bunch of money in this computer

if I can get into it.

I can take all the money.

So one issue that people ran up against pretty early is--

well, let's say I generate 10 keys--

10 private keys, 10 public keys, 10 addresses.

I put them on the server, then I run out.

And I can reuse addresses, but that can hurt privacy

because people can then see that the same people are

using these keys.

So is there any clever way we can generate pubkeys

without the private key?

Is there, given all the fun key stuff we've talked about,

can anyone think of any clever ways to do that?

OK, well pretty straightforward.

This is called BIP32, Bitcoin Improvement Proposal 32.

This is a super-simplified version,

but this is the basic idea of what they do,

and they do it much more involved and complicated.

But basically, you've got your public key P--

big P-- and some kind of randomized data--

randomizer data, r and your private key is just little p.

So the idea is you want to send to an address,

you want to generate a new address.

Well, it's just your public key plus the hash of r concatenated

with 1 times G. And if you wanted to make this 2, 3,

you can make this any number you want.

And then your private key is just

going to be that same public key plus the hash of r.

So you give someone some extra data,

which they can throw into a hash function.

Use this as a known private key and you add it

to your private key.

So no one just knowing this data can spend from it.

That's really nice because then the server

can generate arbitrary numbers.

Does this make sense?

AUDIENCE: What's the difference big A and a?

TADGE DRYJA: Oh, yes.

So in the last one, big A is a public key.

It's a point on the curve.

Little a is the private key.

I screwed that up.

That does not have a G. So G is the generator for the group.

G is how you convert from a private key to a public key.

You just multiply by G, which is just an arbitrary point.

Yes.

AUDIENCE: So your private key doesn't change?

TADGE DRYJA: So in this case, there's two private keys.

There's your standard private key

that you actually just randomly created-- this number p,

multiply it by G, to get big P. But your private key

for any particular address does change.

You're adding the hash of r, 1 or r, 2, r,3.

Yes?

AUDIENCE: Assuming the size of r is relatively small

compared to p because don't you have to keep

track of the nonce?

TADGE DRYJA: R should be, like, 32 bytes or something.

You know, you don't want any--

AUDIENCE: Do you have to start with it every time that you

create a new hash code?

TADGE DRYJA: You sort of don't.

What you can do is, you have your server.

You say, hey, I'm going to accept

payments for cookies or shoes or whatever I'm selling.

And then you give the server your public key, P,

and the randomizer r, and you just say to the server,

go wild, make whatever number you want here.

This number should be fairly small,

let's say less than a billion.

And then when you want to find how much you've gotten paid,

well, you can generate a billion private keys here--

some reasonable number that the computer can actually do it--

and you could just increment this,

generate a ton of addresses, and look for them

on the blockchain.

So does that makes sense at all?

BIP32 is actually quite a bit more involved and complicated.

This is the basic idea, but they make trees of it,

and you can say, oh, well, we can make instead

of just one level, we can make a whole tree of these things,

and have different accounts, and make

a really full-featured system in case people

want to use this kind of thing.

So you can put the public key and this random data

on the server.

The server can make addresses as needed, really quickly.

And what's nice is observers can't link these addresses.

If you're just looking at the blockchain,

you won't see the difference between a sub 1 and a sub 2,

if this number and 1 and 2 because it's

going through this hash function, you never see that.

To an observer, it looks like all completely different

addresses.

And if someone hacks into the server

and finds this P point, and this r randomizer, well,

that will allow them to link everything.

Now they can see-- oh, we can also

generate all these addresses.

We can see that it's all the same person.

But that doesn't let them steal any of the funds.

So compromising the server with this, well,

you lose the privacy, but you don't lose your money,

so that's a pretty good trade.

Other questions about BIP32?

So that's one of the features for wallets.

You've got to do this.

The basic procedure-- you're going to request a payment.

And you're going to say, hey, if you want this jacket, send

one coin to address F8f12E.