Placeholder Image

Subtitles section Play video

  • The following content is provided under a Creative

  • 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.