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.

  • ALIN TOMESCU: My name is Alin.

  • I work in Stata, in the Stata Center.

  • I'm a PhD student there in my fifth year.

  • And today we're going to be talking about one

  • of our research project called Catena.

  • And Catena is a really nice way of using bitcoin

  • to build append-only logs.

  • Bitcoin itself is an append-only log.

  • And a lot of people have been using it to put data in it.

  • And I'll describe a really efficient way

  • of doing that and its applications.

  • And if there is time, we'll talk about a tax and maybe colored

  • coins and some other stuff.

  • We'll talk about the what, the how and the why.

  • And that's the overview of the presentation.

  • So let's talk about this problem called the equivocation

  • problem.

  • So what is this?

  • In general, non-equivocation means saying the same thing

  • to everybody.

  • So for example, if you have a malicious service

  • and you have Alice and Bob, the service

  • should say the same thing to Alice and Bob.

  • So it would make a bunch of statements.

  • Let's say s1, s2, s3 over time and Alice and Bob

  • would see all of these statements.

  • So this is very similar to what bitcoin provides, right?

  • In bitcoin you see block one, block two, block three.

  • And everybody agrees on these blocks in sequence, right?

  • Does that make sense?

  • So this is non-equivocation and in some sense

  • this is what bitcoin already offers.

  • And in general with non-equivocation,

  • what you might get is some of these statements

  • might actually be false or incorrect.

  • Non-equivocation doesn't guarantee you

  • that this statement is a correct statement.

  • But it just guarantees you that everybody

  • sees the same statements.

  • And then they can detect incorrect statements.

  • In bitcoin you get a little bit more.

  • You actually know that if this is a block,

  • it's a valid block, assuming there are enough blocks on top

  • of it, right?

  • So equivocation means saying the same thing to everybody.

  • So for example, this malicious service at time four,

  • he might show Bob a different statement than Alice.

  • So Bob sees s4 and Alice sees s4 prime.

  • This is what happens in bitcoin sometimes.

  • And that's how you can double spend in bitcoin

  • by putting the transaction here sending money to the merchant,

  • and then putting another transaction

  • here sending money back to you.

  • Right, are you guys familiar with this?

  • Yeah, OK.

  • All right, so why does this matter?

  • Let me give you a silly example.

  • Suppose we have Jimmy and we have Jimmy's mom and Jimmy's

  • dad, right?

  • And Jimmy wants to go outside and play.

  • But he knows that mom and dad usually don't let him play.

  • So what he does is he tells dad, hey dad,

  • mom said I can go outside.

  • Right, and then he tells mom, hey mom.

  • Dad said I can go outside.

  • And let's say mom and dad are in different rooms

  • and they're watching soap operas and they're not

  • talking to one another.

  • So they can actually confirm that.

  • You know, mom can confirm that dad really said that.

  • And dad can really confirm that mom said that.

  • But they both trust Jimmy.

  • So you see how equivocation can be really problematic

  • because now mom and dad will say sure,

  • go outside as long as the other person said that, right?

  • But let me give you a more practical example.

  • So let's look at something called a public-key directory.

  • A public-key directory allows you to map user's public keys--

  • a user name to a public key.

  • Right, so here I have the public key for Alice

  • and here I have the public key for Bob.

  • And they look up each other's keys in this directory.

  • And then they can set up a secure channel.

  • How many of you guys use Whatsapp, for example?

  • So the Whatsapp server has a public-key directory.

  • And when I want to send you a message,

  • I look up your phone number in that directory

  • and I get your public key, right?

  • If that directory equivocates, the following thing can happen.

  • What the directory can do is it can create a new directory

  • at time two where he puts a fake public key for Bob

  • and he shows this to Alice, right?

  • And at time two also, he creates another directory for Bob

  • where he puts a fake public key for Alice, right?

  • So now the problem here is that when

  • Alice checks in this directory, she looks at her own public key

  • to make sure she's not impersonated.

  • And Alice looks in this version and sees, OK.

  • That is my public key.

  • I'm good.

  • She looks in this version, OK.

  • This is my public key.

  • I'm good.

  • So now I'm ready to use this directory.

  • And I'll look up Bob and I'll get his public key.

  • But Alice will actually get the wrong public key.

  • Does everybody see that?

  • And similarly Bob will do the same.

  • So Bob will look in his fork of the directory, right?

  • And he looks up his key here and his key here.

  • And he thinks he's OK.

  • He's not impersonated.

  • But in fact, Alice has impersonated there.

  • OK?

  • And now as a result, they will obtain fake keys

  • for each other.

  • And this man in the middle, attacker

  • who knows the corresponding secret keys

  • for these public keys can basically

  • read all of their communications.

  • Any questions about this?

  • This is just one example of how equivocation

  • can be really disastrous.

  • So in a public-key directory, if you can equivocate,

  • you can show fake public keys for people

  • and impersonate them.

  • So in other words, it's really important

  • that Alice and Bob both see the same directory.

  • Because if Bob saw this directory,

  • the same one Alice saw, then Bob would notice that this is not

  • the public key he had.

  • He would notice his first public key and then

  • that there's a second one there.

  • And then he would know he's impersonated.

  • And he could let's say, talk to the New York Times,

  • and say, look.

  • This directory is impersonating me.

  • So in conclusion, equivocation can be pretty bad.

  • So this idea that you say different things

  • to different people can be pretty disastrous.

  • And what Catena does is it prevents that.

  • So in general, if you have this malicious service that is

  • backed by Catena, if it wants to say different things

  • to different people. it cannot do that.

  • It has to show the same thing to everybody.

  • And the way we achieve that is by building on top of bitcoin.

  • And that's what we're going to be talking about today.

  • So any questions about sort of the general setting

  • of the problem and our goals here?

  • So let's move on then.

  • So why does this matter?

  • So this matters for a bunch of other reasons,

  • not just public-key directories and secure messaging.

  • It matters because when you want to do secure software update,

  • equivocation is a problem.

  • And I'll talk about that later.

  • So for example, at some point bitcoin

  • was concerned about malicious bitcoin binaries

  • being published on the web and people

  • like you and me downloading those binaries

  • and getting our coins stolen.

  • Right, and it turns out that that's an equivocation problem.

  • Somebody is equivocating, right?

  • It's equivocating about the bitcoin binary.

  • It's showing us a fake version and maybe

  • other people the real version.

  • Secure messaging, like I said before,

  • has applications here and.

  • Not just secure messaging but also the web.

  • Like when you go on Facebook.com,

  • you're looking up Facebook's public key.

  • And if somebody lies to you about that public key,

  • you could be going to a malicious service

  • and you could be giving them your Facebook password.

  • Does that make sense?

  • And also it has applications in the sense

  • that if you have a way of building a append-only log,

  • you really have a way of building a blockchain right

  • for whatever purpose you want.

  • And we'll talk about that as well.

  • So the 10,000 feet view of the system

  • is we built this bitcoin based append-only log.

  • And the way to think about is that bitcoin is already

  • an append-only log.

  • It's just that it's kind of inefficient to look

  • in that log.

  • If you want to pick certain things from the Bitcoin

  • blockchain, like you put your certain bits and pieces of data

  • there, you have to kind of download

  • the whole thing to make sure you're not missing anything.

  • And I'll tell you why soon.

  • So instead of putting stuff naively

  • in the Bitcoin blockchain, we put it

  • in a more principled way.

  • And in a sense we get a log and another log.

  • We get our log and the bitcoin log.

  • And this generalizes to other cryptocurrencies.

  • Like you could do this in light coin,

  • for example, or even in ethereum.

  • Though I don't think you guys yet

  • talked about how the ethereum blockchain works.

  • And the cool thing about this Catena log that we're building

  • is that the Catena log is as hard to fork as the bitcoin

  • blockchain.

  • If you want to fork our log, you have to fork bitcoin.

  • However, unlike the Bitcoin blockchain,

  • Catena is super efficient to verify.

  • So in particular, remember, I described the log

  • in terms of the statements in it.

  • So if you have 10 statements, each statement

  • will be 600 bytes to audit.

  • So you don't have to download the whole Bitcoin

  • blockchain to make sure you're not missing a statement.

  • And you also have to download 80 bytes per bitcoin block.

  • And we have a Java implementation of this.

  • And if you guys are curious, you can go to my GitHub page,

  • and take a look at the code.

  • All right, so before we start, I know you guys already

  • know a lot about how the Bitcoin blockchain,

  • but it's important that I reintroduce some terminology

  • just so we're on the same page.

  • So this is the bitcoin blockchain.

  • We have a bunch of blocks connected

  • by hash chain pointers.

  • And we have Merkle trees of transactions.

  • And you know, these arrows indicate hash pointers.

  • It means that block n stores a hash of block n minus 1 in it,

  • right?

  • So in that sense.

  • Block n has a hash pointer to block n minus 1.

  • All right, and like I said, each tree has a Merkle tree.

  • Each block has a Merkle tree.

  • And everybody agrees on this chain

  • of blocks via proof of work consensus, which all of you

  • already know.

  • And importantly, in the Merkle trees, we have transactions.

  • And transactions can do two things.

  • Right, a transaction can mint coins, create new coins.

  • So here I have transaction a.

  • It created four coins by storing them in an output.

  • Are you familiar with outputs?

  • So you guys already discussed transaction outputs and inputs.

  • So that's what we're going over here again real quick.

  • So an output specifies the number of coins

  • and the public key of the owner of those coins,

  • as you already know.

  • And the second purpose of transactions

  • is that they can transfer coins, right, and pay fees

  • in the process.

  • So here if you have a transaction b,

  • this transaction b might say, hey, here's

  • a signature from the owner of these coins here.

  • Here's a signature and transaction b.

  • And here's the new owner with public key

  • b of three of those four coins.

  • And one of those coins I'll just give it

  • to the miners as a transaction fee.

  • Does this make sense?

  • How many of you are with me?

  • All right, any questions about how transaction inputs

  • and outputs work?

  • So if you remember in the input here,

  • you have a hash pointer to the output here.

  • All right.

  • So and the high level idea here is

  • that the output is just the number

  • of coins in a public key.

  • And the input is a hash pointer to an output

  • plus a digital signature from that output's public key, OK?

  • And yeah, so what happens here is

  • that transaction b is spending transaction a's first output.

  • Right, that's the terminology that we're going to use.

  • And I think you guys have already

  • used terminology like this.

  • And in addition, what we're going to talk about today

  • is the fact that in these bitcoin transactions

  • you can actually embed data.

  • And I think you touched briefly on this concept of op return

  • transaction outputs.

  • Right, so this is an output that sends coins to a public key.

  • But here I can have an output that sends coins to nobody.

  • It just specifies some data.

  • And in fact, I'll use that data to specify the statements

  • that I was talking about earlier.

  • So that the high level point here

  • is that you can embed data in bitcoin transactions using

  • these operations.

  • And there's a bunch of other ways to do it, actually.

  • Like initially what people did is

  • they put the data as the public key.

  • They just set the public key to the data.

  • And in that sense, they kind of wasted bitcoins.

  • Right, they said hey, send these three bitcoins

  • to this public key, which is just some random data.

  • But nobody would know the corresponding secret key

  • of that public key.

  • So therefore those coins would be burned.

  • Did you did you cover this in class already?

  • Maybe, maybe a little bit.

  • So but that's kind of inefficient

  • because if you remember, the miners

  • have to build this UTXO set.

  • And they have to keep this output that

  • has this bad public key in their memory

  • forever because nobody's going to be able to spend it.

  • So we don't want to do that.

  • We want to build a nice system, a system that treats bitcoin

  • nicely, the bitcoin miners.

  • So that's why we use these return outputs.

  • All right, so the high level here

  • is that Alice gives Bob three bitcoins.

  • And the miners collect a bitcoin as a fee.

  • And of course, you can keep doing this, right?

  • Like Bob can give Carol these two bitcoins later by creating

  • another transaction with an input referring to that output

  • and with an output specifying Carol's public key.

  • All right, and the high level idea of bitcoin is that you

  • don't-- you cannot double spend coins.

  • And what that means is that a transaction output can only

  • be referred to by a single transaction input.

  • So this thing right here in bitcoin where I have two inputs

  • spending an output cannot happen, right?

  • How many of you are familiar with this already?

  • OK, good.

  • So actually this is the essential trick

  • that Catena leverages.

  • And we'll talk about it soon.

  • And yeah, the moral of the story,

  • the reason I told you all of this is because you know,

  • basically if you have proof of work consensus in the bitcoin

  • sense, you cannot do double spends.

  • So this thing right here, that I said before,

  • just cannot occur in the Bitcoin blockchain unless you break

  • the assumptions, right, unless you have more mining power than

  • you should.

  • In that case, you either have to tx2 or tx2

  • prime, but not both, right?

  • And what Catena really realizes is

  • that if I put statements in these transactions now,

  • what that means is that I can only have a second statement.

  • I cannot have two second statements.

  • I cannot equivocate about the second statements if I just

  • restrict my way of issuing statements in this way.

  • I put the first statement in the transaction

  • and the second statement I put it

  • in a transaction that spends the first one.

  • So does everybody agree that if I do things in this way

  • and I want to equivocate about the second statement,

  • I would have to double spend?

  • So that's the key insight behind our system.

  • Any questions about this so far?

  • You know it's really hard to talk if you guys talk back,

  • it's way easier.

  • Yeah?

  • AUDIENCE: A question.

  • And maybe, I think I'm getting this right.

  • If you're setting up the first transaction,

  • then you're adding data on?

  • You're burning bitcoins every time you're doing it,

  • so at some point, you're going to run out.

  • ALIN TOMESCU: That's an excellent question.

  • So let's-- we'll go over that.

  • But the idea is that in this output,

  • I won't burn any bitcoins.

  • I'll actually specify my own public key here.

  • And I'll just send the bitcoins back to myself.

  • And in the process I'll pay a fee to issue this transaction.

  • Does that make sense?

  • Yeah?

  • And we'll talk about it later.

  • OK, so real quickly, what did previous work

  • do regarding this?

  • So how many of you are familiar with blockstack?

  • 1, 2, only two people?

  • OK how many of you are familiar with Keybase?

  • OK, so blockstack and Keybase actually post statements

  • in the Bitcoin blockchain.

  • And they're both public directories.

  • They map user names to public keys.

  • And for example, Keybase, what Keybase does

  • is they take this Merkle route hash,

  • and they put it in the transaction.

  • And then six hours later, they take the new route hash,

  • and they put it in another transaction, and so on.

  • Every six hours, they post the transaction.

  • But unfortunately, they don't actually do what Catena does.

  • So they don't have their new transaction spend the old one.

  • And as a result, if you're trying

  • to make sure you see all of the statements for Keybase,

  • you don't have a lot of recourse other

  • than just downloading each block and looking in the block

  • for all of the relevant transactions.

  • Another thing you could do is you could sort of

  • trust the bitcoin miners--

  • the bitcoin full nodes to filter the blocks for you.

  • So you could contact a bunch of bitcoin full nodes

  • and say, look.

  • I'm only interested in transactions

  • that have a certain IP return prefix in the data.

  • And they could do that for you.

  • But unfortunately, bitcoin full nodes

  • could also lie to you very easily.

  • And there is no cost for them to lie to you.

  • Everybody can be a bitcoin full node.

  • So then it becomes a very bandwidth intensive process

  • because you have to ask a lot of full nodes

  • to deal with the fact that someone might lie to you.

  • But you either need to download full blocks

  • to find let's say, a missing statement like this one

  • that a bitcoin full node might hide from you,

  • or you can trust the majority of bitcoin full nodes

  • to not hide statements, which is not very good, right?

  • So I don't want to trust these full nodes

  • because all of you guys could run a full node right

  • now in the bitcoin network.

  • It doesn't cost you anything.

  • And if I talk to your malicious full node, I could be screwed.

  • So our work just says, look.

  • Instead of issuing transactions in sort

  • of an uncorrelated fashion, just do the following thing.

  • Every transaction you issue should spend the previous one.

  • So as a result, if someone wants to equivocate

  • about the third statement, they have

  • to double spend like I said before.

  • Right?

  • Yeah?

  • AUDIENCE: So what's the connection back

  • to Keybase and blockstack again?

  • ALIN TOMESCU: Yeah, so Keybase and blockstack

  • are public directories.

  • And what they do is they want to prevent themselves from--

  • is there a whiteboard I can draw here?

  • Yeah so, let's say, you know, if you remember the picture

  • from the beginning, I can have a public directory

  • that evolves over time, right?

  • So this is v1 of the directory, and it

  • might have the right public keys for Alice and Bob.

  • But at v2, the directory might do this.

  • It might do v2.

  • It might have Alice, Bob, but then put a fake key for Alice.

  • And at V2 prime, it might do Alice, Bob as before,

  • and put a fake key for Bob.

  • So in other words it keeps the directory append-only.

  • But it just adds fake public keys for the right people

  • in the right version.

  • So here this one is shown to Bob.

  • And here this one is shown to Alice.

  • So now Alice will use this fake key for Bob.

  • So she'll encrypt a message with b prime for Bob.

  • And now the attacker can easily decrypt this message

  • because he has the secret key.

  • So what the attacker can do then is re-encrypt it

  • with the right public key for Bob

  • and now he can read Alice's messages.

  • And the whole idea is that the attacker--

  • you know, this b prime is the public key, is pk b prime,

  • let's say.

  • But the attacker has this sk b prime.

  • He knows sk b prime because the attacker put this in there.

  • The attacker being really, blockstack or Keybase.

  • And of course, they're not attackers in the sense

  • that they want to be good guys.

  • But they're going to be compromised eventually.

  • So they want to prevent themselves

  • from doing things like these.

  • Is that sort of answer your question?

  • Yeah.

  • All right, so yeah, a really simple summary.

  • If I had two slides to summarize our work, this would be it.

  • Right, they would be these two.

  • Look, don't do things this way.

  • Do them this way.

  • All right, so let's see, let's look a little bit

  • at the design.

  • So remember we have these authorities that

  • could equivocate about statements they issued

  • like blockstack and Keybase.

  • So what we propose is look, these authorities

  • can run a lock server, a Catena lock server.

  • And they start with some funds locked in some output.

  • And what they can do first is they

  • can issue this genesis transaction

  • to start a new lock.

  • So for example, Keybase would issue this genesis transaction

  • starting the log of their public directory Merkle routes.

  • And this genesis transaction can be

  • thought of as the public key of the log.

  • Once you have this genesis transaction,

  • you know it's transaction ID.

  • You can verify any future statements,

  • and you can implicitly prevent equivocation about statements.

  • And what the lock server is going to do

  • is it's going to take these coins

  • and send them back to the server to answer your question.

  • So if there was a public key, if these coins

  • are owned by some public key, they're

  • just sent back to same public key here

  • and paying some fees in the process.

  • Right, so we're not burning coins in the sense

  • that we're just paying fees that are

  • miners, which we have to do.

  • OK, so now what you can do is if you

  • want to issue the first statements,

  • you create a transaction.

  • You send the coins from this output to this other output.

  • You pay some fees in the process.

  • You put your statement in an op return output.

  • And as a result, if this lock server wants to equivocate,

  • it has to again, double spend here,

  • which it cannot do unless it has enough mining power.

  • So Keybase and blockstack, if they

  • were to use a system like this, they

  • could prevent themselves from equivocating.

  • And this can keep going, right?

  • So you issue another transaction.

  • Spend the previous output.

  • Put the new statement.

  • Yes?

  • AUDIENCE: This doesn't seem like a new problem.

  • How have authorities prevented equivocation in the past?

  • ALIN TOMESCU: This doesn't seem like a new problem.

  • How did authorities do it?

  • The problem is not new.

  • The problem is eternal.

  • So you are correct there.

  • How did they do it in the past?

  • They just used a Byzantine consensus algorithm.

  • So in some sense this is what we're doing here as well.

  • We're just piggybacking on top of Bitcoin's

  • Byzantine consensus algorithm.

  • AUDIENCE: So you're rolling down to a newer Byzantine consensus

  • algorithm basically.

  • ALIN TOMESCU: Sure, I'm not sure what rolling down means.

  • But yeah, we're piggybacking on top of bitcoin.

  • The idea is that look, a byzantine consensus

  • is actually quite complex to get right.

  • We already have a publicly verifiable business consensus

  • algorithm.

  • It's bitcoin.

  • Why can't we use it to verify, let's say, a log of statements

  • super efficiently?

  • So up until our work, people didn't seem to do this.

  • So Keybase didn't do this.

  • Blockstack didn't do this.

  • They kind of forced it to download the entire bitcoin

  • block chain to verify let's say, three statements.

  • So in our case, you only have to download a few kilobytes

  • of data to verify these three statements,

  • assuming you have the bitcoin block headers, right,

  • which we think is a step forward.

  • And it's sort of like the right way

  • to use these systems should be you

  • know, the efficient way, not the inefficient way.

  • Because bandwidth is expensive, right?

  • Computation is cheap.

  • Bandwidth is expensive.

  • All right, so anyway the idea is that if the lock server becomes

  • malicious, if Keybase or blockstack gets hacked,

  • they cannot equivocate about the third statement.

  • They can only issue one unique third statement.

  • And the advantages are, you know,

  • it's hard to fork this lock.

  • It's hard to equivocate about third statement.

  • But it's efficient to verify.

  • And I'll walk you through how clients verify soon.

  • The disadvantages are that if I want

  • to know that this is the second statement in the log,

  • I have to wait for six more blocks

  • to be built on top of this statement's block, right?

  • Just like in bitcoin, you have to wait for six blocks

  • to make sure a transaction is confirmed, right?

  • Why do you do that?

  • The reason you do that is because there could

  • be another transaction here, double spending

  • because sometimes there are accidental forks in bitcoin

  • and things like that.

  • What are some other disadvantages

  • that you guys can point out?

  • Yeah?

  • AUDIENCE: It's going to be expensive.

  • ALIN TOMESCU: It's going to be expensive to issue

  • these trends.

  • So Alin-- Alin and I share the same name.

  • So Alin is pointing out that you know,

  • every time I issue these statements,

  • I have to pay a fee, right?

  • And if you remember, the fees were quite ridiculous

  • in bitcoin.

  • So that's a problem, right?

  • So let's see, is that the next thing?

  • The next thing was you have to issue--

  • you can only issue a statement every 10 minutes, right?

  • So if you want to issue statements really fast.

  • you can't do that.

  • All right, like Alin said you have to pay bitcoin transaction

  • fees.

  • And the other problem is that you don't get freshness

  • in the sense that it's kind of easy for this lock server

  • to hide from you the latest statement.

  • You know, unless you have a lot of these log servers

  • and you ask many of them, hey, what's the latest statement?

  • And they show you back the latest statement.

  • If there is just one log server and it's compromised,

  • it could always pretend no, no, no.

  • This is the latest statement.

  • And if you don't trust it, the best recourse you have

  • is to download the full block and look for the statement

  • yourself.

  • So you don't get freshness.

  • Those are some disadvantages.

  • Now let's look at how clients audit this log?

  • So I was claiming that it's very efficient

  • to get these statements and make sure

  • that no equivocation happened.

  • So let's say, you have a Catena client

  • and you're running on your phone with this client.

  • And your goal is to get that list of statements.

  • And there's the Catena log server over there in the back.

  • And there's the bitcoin peer to peer

  • network which at the moment has about 11,000 nodes.

  • And remember, I said the first thing you need

  • is the genesis transaction.

  • Does everybody sort of understand

  • that if you get the wrong Genesis transaction,

  • you're completely screwed, right?

  • Because it's very easy to equivocate

  • if you have the wrong Genesis transaction, right?

  • I mean, you know there's the right GTX here where you have,

  • let's say, a s1.

  • And then you have s2 in their own transactions, right?

  • But if there's another GTX prime here and you're using that one,

  • you're going to get s1 prime, s2 prime, different statements.

  • So if Alice uses GTX but Bob uses GTX prime,

  • Alice and Bob are back to square one.

  • So in some sense, you might ask, OK, so then what's the point?

  • What have you solved here?

  • I still need to get this GTX, right?

  • So what we claim is that this is a step forward because you only

  • have to do this once.

  • Once you've got this GTX, you can

  • be sure you're never equivocated to, right?

  • Whereas in the past, you would have

  • to for each individual statement,

  • you'd have to do additional checks

  • to make sure you're not being equivocated

  • to, like you would have to ask in a full node, let's say.

  • Right, so as long as you have the right GTX, you're good.

  • And how do you get the right GTX?

  • Well, usually you ship it with the software on your phone.

  • And there's some problems there as well,

  • like there is no problem solved in computer

  • science in some sense.

  • But you know, we're trying to make progress here.

  • OK, so let's say you have the right GTX because it

  • got shipped with your software.

  • Now the next thing you want to do is get the block headers.

  • So you have header i, but there are

  • some new headers being posted.

  • Let's say the bitcoin peer to peer network sends them to you.

  • You have these headers.

  • You verify the proof of work, right?

  • So this only costs you 80 bytes per header, right?

  • Does everyone see that this is very cheap?

  • So far, so far I have the GTX, which is let's say 235 bytes.

  • And now I'm downloading some headers.

  • And now I'm ready to ask the log server what's

  • the first statement in the log, right?

  • And what the log server will do is

  • he's going to reply with the transaction

  • with the statement, which is 600 bytes and the Merkle proof.

  • So all of this is 600 bytes, actually.

  • Right, and now what the Catena client will do

  • is he'll check the Merkle proof against one

  • of the headers so to see in which headers does it fit.

  • And then he'll also check that the input here

  • has a valid signature from the public key in the output here.

  • All right, I want at least one question about this.

  • Yeah?

  • AUDIENCE: Sorry I came in late, but is the Catena client

  • over there similar to the SPV?

  • ALIN TOMESCU: Yeah, so that exactly.

  • It's an SPV client.

  • Yeah, so the idea is that we want SPV clients.

  • We don't want these mobile phone clients

  • to download 150 gigabytes of data.

  • We want them to download let's say 40 megabytes worth of block

  • headers, which they can discard very quickly as they verify.

  • And then we want them to download

  • 600 bytes per statement, but still

  • be sure that they saw all of the statements in sequence,

  • and that there was no equivocation.

  • Yeah?

  • AUDIENCE: So in our previous classes,

  • we discussed, if you can have a full node and an SPV node,

  • do these sort of vulnerabilities exist with the [INAUDIBLE]

  • client?

  • ALIN TOMESCU: So which vulnerabilities

  • that you did talk about?

  • AUDIENCE: I forget.

  • ALIN TOMESCU: Did you talk about--

  • AUDIENCE: There was just a box that was like less secure.

  • And then there was another box that was something else bad.

  • There was one about [INAUDIBLE].

  • The clients would lie to you about--

  • If you say, here's some transactions

  • or here are some unspent outputs,

  • then they could just tell you something different.

  • ALIN TOMESCU: Yes.

  • Yeah?

  • Sorry.

  • AUDIENCE: Well, they can't tell you

  • that transactions exist or don't exist.

  • They can just not tell you--

  • ALIN TOMESCU: Yeah, they can hide transactions

  • from you, which gets back to the freshness issue

  • that we could discussed.

  • They could also-- this block header

  • could be an header for an invalid block.

  • But remember, that before you accept this tx1,

  • you wait for enough proof of work,

  • you wait for more block headers on top of this guy

  • to sort of get some assurance that no, this

  • was a valid block because a bunch of other miners built

  • on top of it.

  • Right?

  • So as long as you're willing to trust that the miners do

  • the right thing, which they have an incentive

  • to do the right thing, you should be good.

  • But like you said, what's your name?

  • AUDIENCE: Anne.

  • ALIN TOMESCU: Anne?

  • Like Anne said, there are actually bigger problems

  • with SPV clients.

  • And if there is time, we can talk about it.

  • But it's actually easier to trick SPV clients to fork them.

  • And there's something called a generalized vector 76 attack.

  • Have any of your guys heard about this?

  • So it's like a pre-mining attack but it's

  • a bit easier to pull off.

  • Actually, it's a lot easier to pull off on an SPV node

  • than on a full node.

  • And if there's time at the end, we can talk about it.

  • If there isn't, you can read our paper,

  • which is online on my website.

  • And you can read about these pre-mining attacks

  • that work easier for SPV nodes.

  • But anyway, this can keep going, right?

  • You get block headers, 80 bytes each.

  • You ask the log server, hey what's

  • the next statement in the log?

  • You get a Merkle proof in a transaction.

  • And then you verify the Merkle proof.

  • You put this transaction in one of these blocks

  • and you verify that it spends the previous one.

  • Right, and as a result, you implicitly

  • by doing this verification, by checking that hey,

  • this is a transaction and a valid block.

  • This block has enough stuff built on top of it

  • and this transaction spends this guy here,

  • you implicitly prevent equivocation.

  • Right, then you don't have to download anything else.

  • Right, you only have to download these Merkle proofs

  • and transactions in these block headers.

  • Whereas in previous work, you could be missing these s1's,

  • these s2's, they could be hidden away

  • in some other branch of the Merkle tree.

  • And you'd have to do peer to peer bloom

  • filtering on the full nodes.

  • And those full nodes could lie to you.

  • Yeah, so the bandwidth is actually very small.

  • So suppose we have 500k block headers--

  • I think bitcoin has a bit more right now--

  • which are 80 bytes each and we have

  • 10,000 statements in this log, which are 600 bytes each.

  • Then we only need now with 46 megabytes, right?

  • What's the what's the other way of doing it?

  • You have to download hundreds of gigabytes.

  • All right, so let's talk about scalability a little bit.

  • So suppose the system gets deployed widely.

  • Let's say Whatsapp starts to use the system to witness--

  • to publish their public directory in bitcoin, right?

  • And everybody, a lot of you here have Whatsapp.

  • And this is you guys.

  • Let's say there are 200,000 people using Whatsapp.

  • I think there's more like a billion.

  • So what are they going to do?

  • Remember that part of the verification protocol

  • is asking for these block headers

  • from the peer to peer network, right?

  • And in fact, if you're SPV clients,

  • you usually open up around eight connections to the peer

  • to peer network.

  • And if you're a full node in the bitcoin peer to peer network,

  • you usually have around 117 incoming connections.

  • That that's how much you support.

  • You support 117 incoming connections as a full node.

  • So that means in total, you support about a million

  • incoming connections.

  • So you know, this guy supports a million.

  • But we need about 1.6 million connections

  • from these 200,000 clients, right?

  • So it's a bit of a problem if you

  • deploy Catena and it becomes wildly popular.

  • Being a bit optimistic here, but you know,

  • let's say that happened, right?

  • So how can we fix this?

  • How can we avoid this problem because in this case, what

  • we would basically be doing is we

  • would be accidentally DDOSing bitcoin.

  • And we don't want to do that.

  • Does everybody see that there's a problem here, first of all?

  • OK, so the idea is very simple.

  • We just introduced something called a header relay network.

  • And what that means is look, you don't really

  • have to ask for these block headers from the Bitcoin peer

  • to peer network.

  • You could just outsource these block headers anywhere

  • because they're publicly verifiable.

  • Right, the block headers have proof of work on them.

  • So you can use volunteer nodes that sort of push block

  • headers to whoever asks for them.

  • You could use blockchain explorers like blockchain.info,

  • right?

  • You could use Facebook.

  • You could just post block headers on Facebook.

  • Right, like in a Facebook feed.

  • You could use Twitter for that.

  • You could use GitHub gists.

  • You know, so you could--

  • there's a lot of ways to implement this.

  • The simplest way is have servers and have

  • them send these headers to whoever asks for them.

  • So it's easy to scale in that sense

  • because if you now ask these header relay

  • network for the block headers, you

  • know, it's much easier to scale this than to scale the bitcoin

  • peer to peer network, which has to do a bit more than just

  • block headers.

  • They have to verify blocks.

  • They have to verify signatures.

  • Yeah?

  • AUDIENCE: Did you consider having

  • the clients being peer to peer?

  • ALIN TOMESCU: , Yes so another way.

  • And I think we'll talk about that in the paper--

  • is you can implement the header relay network as a peer to peer

  • network on top of the clients.

  • Yeah, so that's another way to do it.

  • There's some subtleties there that you have to get right.

  • But you can do it, I think.

  • Yeah?

  • AUDIENCE: Would you you expect that if a company like Whatsapp

  • decided adopt Catena, they would run their own servers

  • to make sure that there was the capacity for it?

  • ALIN TOMESCU: For the header relay network?

  • AUDIENCE: Yes.

  • ALIN TOMESCU: I mean, I would be just be speculating,

  • wishful thinking.

  • They could.

  • There is some problem with this header relay network as well.

  • And we talk about it in the paper

  • because this had a really network could withhold

  • block headers from you.

  • So you do have to distribute it.

  • Like usually you don't want to just trust

  • Whatsapp who's also doing the statements, who's

  • also pushing the statements in the blockchain.

  • You don't want to trust them to also give you

  • the block headers.

  • You actually want to fetch them from a different source

  • that Whatsapp doesn't collude with.

  • Yeah, Anne, you had a question?

  • AUDIENCE: Are there other header relay networks

  • that are deployed already?

  • ALIN TOMESCU: Yeah, there was actually one on ethereum.

  • There's a smart contract in ethereum,

  • I think, that if you submit bitcoin block headers to it,

  • you get something back.

  • And then you can just query bitcoin block headers

  • from the ethereum blockchain.

  • Is anyone familiar with this?

  • So I guess I didn't include it here.

  • But another way to do it is to just publish the header

  • is in an ethereum smart contract.

  • Yeah.

  • So there's crazy ways you could do this too.

  • Yeah?

  • AUDIENCE: Will that one go out of gas?

  • I don't know, my understanding of ethereum is pretty decent,

  • but would that smart contract eventually run out of gas

  • and not publish anymore?

  • ALIN TOMESCU: So to fetch from it, you don't need to pay gas.

  • But I suspect to push in it, I actually

  • don't know who funds that contract.

  • So I guess you fund that when you push maybe.

  • Maybe not because then you also want something back.

  • Why would you push?

  • I'm not sure.

  • But we can look at it after.

  • Yeah.

  • It's a good question.

  • So anyway, even if this header relay network is compromised,

  • if you implement it in the right way,

  • you've distributed on a sufficient number of parties,

  • you can still get all of the properties that you need to,

  • meaning freshness for the block headers.

  • That's really the only property that you need to.

  • The header relay network should always

  • reply with the latest block headers.

  • So let's look at costs since Alin was mentioning the costs.

  • So to open a statement, you have to issue a transaction, right?

  • And the size of our transactions are around 235 bytes.

  • So and the fee as of December 13 was $16.24 for transactions

  • if you guys remember those great bitcoin times.

  • I think it went up to $40 at some point too.

  • So it was it was really hard for me to talk to people

  • about this research back then.

  • But guess what, the fees are today?

  • So today, this morning I checked.

  • And there were $0.78, right?

  • When we wrote the paper, they were like $0.12.

  • So you know, here I am standing in front

  • of you pitching our work.

  • In two minutes they could be back to $100, but who knows?

  • Yes, you had a question.

  • AUDIENCE: Maybe I'm wrong, but in a transaction,

  • you can have some outputs.

  • Can you have several statements in there?

  • ALIN TOMESCU: So that's a good question.

  • So can you batch statements?

  • And then the answer is yes.

  • You can definitely batch statements.

  • What we've said so far is in a transaction--

  • in a Catena transaction, you have this output.

  • And you have this op return output

  • where you put the statement, right?

  • And you know, it spends a previous transaction.

  • But as a matter of fact, what you can do and some of you

  • may already notice this.

  • There is no reason to put just one statement in here.

  • There is some reason-- so the only reason

  • is that it only fits 80 bytes.

  • So you could put easily, let's say, two or three statements

  • in there if you hashed them with the right hash function.

  • But a better way to do it is why didn't you

  • put here a Merkle root hash?

  • And then you can have as many statements

  • as you want in the leafs of that Merkle tree, right?

  • In fact, here you could have I don't know,

  • billions of statements.

  • So keep in mind, you will only be

  • able to issue billions of statements every 10 minutes.

  • But you can definitely have billions

  • of statements in a single transaction

  • if you just batch them.

  • So now, remember the blockchain will only store the root hash.

  • This Merkle tree will be stored by the log server perhaps

  • or by a different party.

  • They don't have to be the same party.

  • Does that make sense?

  • Does that answer your question?

  • Yeah.

  • Right, that was my next point.

  • Statements can be batched with Merkle trees.

  • OK, so let's talk about the why since so far

  • we've been talking abstractly about these statements.

  • But what could these statements actually be.

  • So let's look at a secure software update.

  • So how do you do secure software update?

  • An example attack on a software update scheme

  • is that somebody compromises the bitcoin.org domain.

  • And they change the bitcoin binary to a malicious binary.

  • And they wait for people to install that malicious binary.

  • And then they steal their coins.

  • They steal their data.

  • They could execute arbitrary code.

  • And an example of this was sort of this binary safety

  • warning on the bitcoin website.

  • At some point, they were very concerned

  • that a state actor is going to mess with the DNS servers

  • and redirect clients to a different server

  • and make them download a bad bitcoin binary.

  • So does the attack make sense?

  • Does everybody see why this is possible?

  • You do need to sort of accept that the DNS service that we

  • currently have on the internet is fundamentally flawed.

  • It's not built for security.

  • So the typical defense the typical defense for this

  • is that the Bitcoin developers-- they sign the bitcoin

  • binaries with some secret key.

  • And they protect that secret key.

  • And then there's a public key associated

  • with the secret key that's posted on the bitcoin website,

  • right?

  • And maybe some of you'll notice that sometimes it's

  • also very easy to change the public key on the website,

  • you know, if you can just redirect

  • the victim to another website.

  • And another problem is that not everyone checks the signature.

  • Even if let's say you have the public key on your computer,

  • you know what the right public key is,

  • only if you're like an expert user

  • and you know how to use GPG, you will check that signature,

  • right?

  • And the other problem that's probably I

  • think a much, much bigger problem

  • is that for the bitcoin devs themselves,

  • it's very hard to detect if someone stole their secret key.

  • Like if I'm a state actor and I break your computer

  • and I steal your secret key, I will sign this bitcoin binary.

  • And I'll give it to let's say, one guy.

  • I'll give it to you.

  • You know, and I'll just target you individually

  • because I'm really--

  • I know you have a lot of bitcoin.

  • Right, and then the bitcoin devs will never find out about it

  • unless you know you kind of realize what happened.

  • Then you take your bitcoin binary

  • and you go with it to the bitcoin devs.

  • And they check the signature on it and they say, oh wow.

  • This is a valid signature and we never signed it.

  • So somebody must have stolen our secret key.

  • So this is really a bad--

  • kind of the core of the problem is

  • that it's hard for whoever publishes software

  • to detect that their secret key has

  • been stolen-- to detect malicious signatures

  • on their binaries.

  • Does that make sense?

  • So the solution, of course, is you know, publish

  • the signatures of bitcoin binaries in a Catena log

  • So now if there's a malicious binary being published

  • by a state actor, people won't accept that binary

  • unless it's in the Catena log, which

  • means people in the bitcoin devs will see the same binary.

  • Right, so let me let me show you what I mean with a picture.

  • So we have this Catena log for Bitcoin binaries.

  • And let's say, the first transaction

  • has a hash of the bitcoin 0.001 tar file, right,

  • the bitcoin binaries.

  • And this hash here is implicitly signed

  • by the signature in this input because it

  • signs the whole transaction.

  • So now if I put this hash in a Catena log,

  • I get a signature on it for free.

  • And now, if let's say, a state actor compromises the log

  • server, gets the secret key, he can

  • publish this second malicious binary in the log, right?

  • But what that malicious state actor will want to do,

  • he will want to hide this from the Bitcoin devs

  • and show it to all of you guys.

  • All right, so he'll want to equivocate.

  • So as a result, he will want to create a different transaction

  • with the right bitcoin binary there,

  • show this to the bitcoin devs while showing this to you guys.

  • All right, so the bitcoin devs would think they're good.

  • This is the binary they wanted to publish while you guys would

  • be using this malicious binary published by the state actor.

  • Of course this cannot happen because in Catena you cannot

  • equivocate.

  • Right?

  • Does everybody see this?

  • Right, any questions about this?

  • There has to be a question on this.

  • No?

  • So this mechanism is called software transparency.

  • It's this idea that rather than just downloading software

  • like a crazy person from the internet and installing it,

  • we should just be publishing these binaries

  • in a log that everybody can see, including the software vendors

  • that created those binaries.

  • So in this way, if somebody compromises a software vendor,

  • that vendor can notice that in the log

  • there's a new version for their software

  • that they didn't publish.

  • So you know, this isn't to say that it'll prevent attacks.

  • You know, what a state actor can do anyway

  • is they can just do this.

  • They can post this H2 prime in here,

  • show it to you guys including the bitcoin devs

  • and still screw everyone over.

  • But at least these attacks then go undetected anymore.

  • All right, so it's a step forward in that sense.

  • Yes, so the idea is that you have

  • to double spend to equivocate.

  • And the other example that really--

  • the reason I wanted to start this research

  • had to do with public key distribution.

  • So let's say we have Alice and we have Bob.

  • And they both have their public keys.

  • And I'm using this letter b to denote

  • Bob and his public key and the letter

  • a to denote Alice and her public key.

  • And they have their corresponding secret keys,

  • right?

  • And Alice and Bob, they want to chat securely, right?

  • So they want to set up a secure channel.

  • And there's this directory which stores their public keys.

  • So this guy stores Alice, pk Alice.

  • This guy stores Bob, pk Bob.

  • All right, and the directory gets updated over time,

  • maybe Karl, Ellen and Dan registered.

  • And if you have non-equivocation,

  • if the attacker wants to impersonate Alice and Bob,

  • he kind of has to put their public keys,

  • the fake public keys in the same directory,

  • which means that when Alice and Bob monitor--

  • they check their own public keys,

  • they both notice they've been impersonated, right?

  • So again, the idea is that you can detect.

  • Now how can this attacker still trick

  • Alice to send an encrypted message to Bob

  • with Bob's fake public key?

  • Is there a way even if you have non-equivocation?

  • So what's the attack?

  • Even I have non-equivocation and I

  • claim that the attacker can still

  • get Alice to send a fake, an encrypted message to Bob

  • that the attacker can decrypt.

  • What should the attacker do?

  • So pretend that we are here without the ability

  • to equivocate.

  • So the attacker cannot equivocate.

  • But I claimed that the attacker can still

  • trick Alice into sending a message to Bob

  • that the attacker can read.

  • So now it's time to see if you guys paid attention.

  • Somebody?

  • Alin?

  • Oh, you?

  • AUDIENCE: Does the attacker have to have the secret key?

  • ALIN TOMESCU: No, no.

  • He does not.

  • Yeah.

  • He does not have to have the secret key.

  • The attacker just creates fake public keys.

  • Here's a hint.

  • AUDIENCE: If you only changed one person to choose,

  • they don't know that it's a fake key so they could send it

  • to a fake key for a bit?

  • ALIN TOMESCU: Yeah, so whose person should they

  • attack or change the key for?

  • AUDIENCE: Like if they change Bob's, Alice

  • will still think Bob's is correct

  • so she'll send it to the fake Bob until Bob checks it.

  • ALIN TOMESCU: Exactly.

  • So that's exactly right.

  • So what's your name?

  • AUDIENCE: Lucas.

  • ALIN TOMESCU: Lucas.

  • So what Lucas is saying is look, even without equivocation,

  • I had this directory at T1.

  • I had another one at T2.

  • But at T3 and both of these had keys for Alice and Bob, right?

  • But at T3, Lucas is saying look, just put the fake key for Bob

  • here.

  • And that's it.

  • Don't put a fake key for Alice there, just for Bob.

  • And now when Alice looks up this public key for Bob here,

  • she sends a query to the directory hey,

  • what's Bob's public key?

  • She gets back b prime, which is equal to Bob pk

  • Bob prime, right?

  • Alice can't tell if that's really Bob's fake public key.

  • That's the reason she's using the directory

  • in the first place.

  • She wants sort of a trustworthy place to get it from.

  • Bob can tell if Bob looks.

  • But by the time Bob looks, it might be too late.

  • Alice might have already encrypted a message, right?

  • So again, what's the point of doing all of this?

  • It's not like you're preventing attacks, right?

  • And the point of doing all of this

  • is that you get transparency.

  • Bob can detect, whereas right now Bob has no hope.

  • In fact, so you said, a lot of you use Whatsapp.

  • So you know in Whatsapp, if you really

  • want to be sure, so I have a conversation here

  • with Alin Dragos.

  • So, Alin, do you what to to bring your phone here?

  • Do you have Whatsapp?

  • So if you really want to be sure that you're

  • talking to the real Alin and not some other guy,

  • you have to go on this encryption tab.

  • Can you tape this?

  • So my phone is black and white.

  • It's going through a depression phase.

  • I apologize.

  • So you have to go here and there's a code here, right?

  • And Alin, can you do the same thing?

  • You know what I'm talking about?

  • I really hope I don't get some weird text message right now

  • with the camera on the phone.

  • OK, so now with Alin's phone, is that the same code?

  • Can somebody tell me?

  • I can't see it.

  • AUDIENCE: It's hard to see.

  • ALIN TOMESCU: OK, so we have 27836 and yeah.

  • So it's the same code.

  • Can you see it on the camera?

  • So now because we have the same code here.

  • With this code here, it really is

  • a hash of my public key and Alin's public key.

  • And if we've got the same hash of both of our public keys,

  • then we know we're talking to one another.

  • But we won't really know that's the case until we actually

  • meet in person and do this exchange, right?

  • So what this system does instead is

  • it allows Alin to check his own public key

  • and it allows me to check my own public key.

  • This way if we check our own public key,

  • we'll always know when we're impersonated even though I

  • might send an encrypted message to the wrong Alin,

  • Alin will eventually find out.

  • It's a bit confusing because we're both called Alin.

  • So does that sort of makes sense?

  • Yeah?

  • AUDIENCE: So what do you do when you realize

  • that your key is the wrong key?

  • ALIN TOMESCU: Good question.

  • So that's really the crucial question.

  • What the hell can you do?

  • Right, so this directory impersonated you.

  • In fact, you can't even--

  • here's the problem.

  • If you're Bob here and you see this fake public key.

  • And you go to the New York Times and you

  • say hey, New York Times, this Whatsapp directory

  • started impersonating me.

  • And the New York Times can go to the directory

  • and say, hey directory, why did you impersonate Bob?

  • And the directory can say, no, I did not impersonate Bob.

  • Bob really just ask for a new public key.

  • And this was the public key that Bob gave me.

  • And it's just a he said, they said, kind of a thing, right?

  • So it's really a sort of an open research area

  • to figure out what's the right way to whistle blow here.

  • So for example, one project that we're trying to work on

  • is there a way to track the directory somehow

  • so that when he does stuff like this,

  • you get a publicly verifiable cryptographic proof that he

  • really misbehaved, right?

  • No, there's no cryptographic proof.

  • The fact that that public key is there

  • could have come from the malicious directory

  • or could have come from an honest Bob who

  • just changed his public key.

  • So yeah.

  • So again, a step forward but we're not there.

  • You know, it's just that there's much more work to do here.

  • And I think you also had a question.

  • AUDIENCE: Can't Alice just ask Bob if this is you?

  • ALIN TOMESCU: So that's a chicken and an egg, right?

  • So we have Alice.

  • We have Bob.

  • And we have the attacker.

  • Alice asks Bob, is this your public key?

  • You know, let's say, b prime.

  • Let me make this more readable.

  • So attacker, right?

  • So Alice asks, hey Bob.

  • Is this b prime your public key?

  • The attacker changes it.

  • Hey Bob, is b your public key?

  • The attacker-- Bob says yes.

  • Attacker forwards yes to Alice, right?

  • Remember, Bob and Alice don't have a secure channel.

  • That's the problem we're trying to solve with this directory,

  • right?

  • So the attacker can always man in the middle people.

  • Well, people like Alice and Bob.

  • If the attacker can man in the middle everything,

  • then there's really no hope.

  • And we're living in a very sad, sad world if that's the case.

  • Yeah, it actually might be the case but we'll see.

  • Anyway, so yeah, so I claim here that this is a step forward.

  • But there's still much work to do.

  • All right, so we get transparency.

  • Bob can detect.

  • He'll know.

  • He won't be able to convince anybody.

  • But if a lot of Bobs get compromised,

  • you're still like in a place where everybody

  • knows that something's off and will all stop using Whatsapp,

  • for example.

  • Right?

  • By the way, Whatsapp is a great tool.

  • You should continue using it.

  • I'm just saying it's difficult to use right

  • like if somebody really wants to target it,

  • they can play a lot of tricks to still trick you.

  • So yeah, so all right, we already talked about this.

  • And yeah, again if the director can equivocate, then you know,

  • all bets are off because now Bob will look in this directory,

  • he'll think he's not impersonated.

  • Alice will look in this directory.

  • She'll think she's not impersonated, right?

  • So the reason we started this research

  • is because I really want to--

  • my thesis is on building these directories that

  • are efficiently auditable and have a hard time impersonating

  • people.

  • So that's why we decided to look at how could you

  • do this with Bitcoin.

  • Yeah, so of course there's one project called KeyChat

  • that we're working on with some high school students.

  • And we're using the key based public key directory.

  • And we're witnessing it in a Catena log

  • so that stuff like that doesn't happen.

  • OK, so now let's talk about the blockchains.

  • In general, people nowadays like to say I

  • need a blockchain for x, right?

  • I need a blockchain for supply chain management.

  • I mean a blockchain for cats, for whatever.

  • I've heard a lot of crazy stories.

  • IOT, self-driving cars, blah, blah, blah.

  • And I think the right way to think about blockchain

  • is to never ever say that word unless you

  • use quotes, first of all.

  • And second of all, to understand what Byzantine state

  • machine replication is.

  • Right, and if you understand what Byzantine state machine

  • replication is or a Byzantine consensus,

  • you understand blockchain.

  • And you understand all the hype.

  • And then you can make some progress in solving problems.

  • In the sense that what is blockchain?

  • So what we're doing here is we're

  • doing a Byzantine consensus algorithm.

  • We're agreeing on a log of operations.

  • Right, by the way, that's what Catena does too

  • by piggybacking on bitcoin.

  • It agrees on a lot on a log of operations.

  • Right, but the other thing that SMR or Byzantine consensus does

  • is that it also allows you to agree

  • on the execution of the ops in that log.

  • So in Catena, you don't agree on the execution,

  • you just agree on the statements.

  • But there is no execution of those statements in the sense

  • that you can't build another bitcoin

  • on top of bitcoin in Catena because you can't prevent

  • double spends of transactions that

  • are Catena statements, right?

  • Like the Catena statements, you have to look in each one

  • and tell if it's correct.

  • So to detect a double spend in a Catena backed cryptocurrency,

  • you would have to download all of the transactions

  • and because you cannot execute it like the bitcoin miners do

  • and build this UTXO set.

  • I'm not sure this is making a lot of sense.

  • But let's put it another way.

  • In bitcoin, you have block one and then

  • you have block two, right?

  • And there's a hash pointer and there's a bunch of transactions

  • here, right?

  • And remember that what prevents me from double spending

  • something here--

  • I can have two transactions in this block

  • that double spend the same one here.

  • What prevents me from doing that is exactly this execution

  • stage, right?

  • Because in the execution stage, when I try to I execute this

  • first transaction and I mark this output as spent,

  • when I execute the second transaction,

  • I cannot spend that output anymore, right?

  • In Catena, you can't do anything like that with the statements.

  • You just agree on the statements.

  • In Catena, you would put this transaction

  • in the log, this one and then that one and someone would

  • have to detect that the second one is a bad one by actually

  • downloading it.

  • That's kind of what I'm trying to say here.

  • So in general, the way should you

  • should be thinking about blockchain

  • is through the lens of Byzantine consensus.

  • And that'll get you ahead of the curve

  • in this overly hyped space, right,

  • because it's really just this.

  • You're agreeing on a log of operations.

  • And then you're agreeing on the execution of those operations

  • according to some rules.

  • The rules in bitcoin are transaction cannot--

  • there cannot be two inputs spending the same output more

  • or less.

  • There's other things too.

  • What that gives you is it allows you

  • to agree on a final state which in bitcoin are

  • the valid transactions.

  • That's the final state right.

  • In ethereum, for example, the final state

  • are the valid transactions, and the account

  • balances of everything, and the smart contract

  • state for everything.

  • And I guess you'll learn about that later.

  • So you can build arbitrarily complex things

  • with Byzantine consensus or with blockchains.

  • And the high level bit, if you want to look at it another way,

  • is that you have a program p, right, which could be anything,

  • could be a cryptocurrency.

  • And then, instead of running this program p

  • on a single server s, what do you do is you

  • distribute it on a bunch of servers, s1, s2, s3, s4, right?

  • And now as a result, to mess with this program p,

  • it's not enough to compromise one server,

  • you have to compromise a bunch of them.

  • right?

  • OK so, and some of you might also

  • be familiar with this term permissioned blockchain.

  • So when you distribute this program o amongst n servers

  • where n is equal let's say, three f plus 1 and f

  • is equal to 1 in this particular case.

  • In a permission blockchain, this n is fixed, right?

  • Once you've set n to 4, it has to stay 4.

  • These servers have to know one another.

  • They need to know each other's public keys.

  • And only one of the servers, f is equal to 1, can fail.

  • If more than one server fails, then all bets are off.

  • Your program can start doing arbitrary things.

  • In particular, if your program is bitcoin,

  • it can start double spending.

  • I'm moving a little bit fast, so I'll take some questions up

  • until this point before I go on.

  • Yes?

  • AUDIENCE: In a permissioned blockchain,

  • do they use proof of work?

  • ALIN TOMESCU: No, you don't have to.

  • And that's kind of what the hype is about.

  • This stuff, there is like--

  • the first interesting paper on this

  • was 1976 or something like that.

  • So this is 40-30, 40-year-old research.

  • We've known how to do permissioned consensus-- we

  • used to call it Byzantine consensus for 30 or 40

  • years, right?

  • So there's nothing new there.

  • It's just that it's very useful nowadays to say blockchain then

  • to say consensus because then you

  • get 10 more million from your venture capitalist folks.

  • AUDIENCE: But if you don't have to do proof of work,

  • do they ever do proof of work?

  • ALIN TOMESCU: It would be such a bad idea

  • technically to do prefer working a permissioned consensus

  • algorithm.

  • It just-- completely unnecessary, plus probably

  • insecure too.

  • Yeah, so now the reason you do proof of work

  • is because in a permissionless blockchain,

  • this n is not fixed.

  • n could go, let's say, n was 4.

  • It could go to 8.

  • Then it could go to 3.

  • Then it could go to 12.

  • In other words, people are joining and leaving

  • as they please.

  • And the reason you need proof of work

  • in bitcoin, one way you can look at it

  • is that you're really turning a permissioned consensus

  • algorithm into a permissionless one.

  • And a consensus algorithm is just voting.

  • These n folks are just voting.

  • And you need 2f plus 1 votes to sort of move on, right?

  • And if this n changes over time, like if the n becomes bigger,

  • it's very easy to take over a majority of the voters.

  • If I can just add fake voters to a permissioned consensus

  • algorithm, I can just take over the consensus algorithm.

  • In other words, I can take over more than f nodes.

  • Right, so the trick there is you have

  • to prevent that from happening.

  • And the only way to prevent that is to say,

  • look if you're going to join and then make my n bigger,

  • you better do some work.

  • So that it's not easy for you to join

  • because if you're a bad guy and you want to join, you know,

  • you can do that very easily unless I

  • require you to do some work.

  • So that's kind of the trick in turning

  • a permissioned consensus algorithm

  • into a permissionless one.

  • And in fact, the way these permissioned animals work

  • is completely different than bitcoin.

  • They are much more complex.

  • Bitcoin is incredibly simple as a consensus algorithm.

  • If you ever read a consensus algorithm paper,

  • you know, it's a bit insane.

  • Also to implement, it's a bit insane.

  • Bitcoin is very simple to implement compared

  • to these other things, I mean, bitcoin is,

  • of course, a complex beast as well.

  • But you should look at let's say, practical Byzantine fault

  • tolerant paper, PBFT, and try and implement that.

  • So anyway, why am I telling you all of this?

  • The reason I'm telling you all of this

  • is because if you want to do a permissioned blockchain

  • for whatever reason, one way to do

  • that is to use your favorite Byzantine consensus algorithm.

  • So that would be--

  • let's say pbft.

  • This was 1999 from MIT.

  • So you could use that.

  • You could have a lot of fun implementing it.

  • Another thing you could do is you could take your program p

  • and just give it to an ethereum smart contract.

  • And you know, that the ethereum smart contract,

  • if the ethereum security assumption holds,

  • it will do the right thing.

  • It will execute your program p correctly, right?

  • But the other thing that you could do actually,

  • is you could use Catena to agree on these logs,

  • on the log of operations for your program.

  • And then you could use another 2f plus 1 servers or replicas

  • to do the execution stuff so that you

  • can agree on the final state.

  • And this gives you a very simple Byzantine consensus algorithm.

  • So remember Catena doesn't give you execution.

  • It allows you to agree on the log of ops.

  • To get the execution, you'd basically take a majority vote.

  • If you see you have 2f plus 1 replica servers

  • and if you see f plus 1 votes on a final state,

  • you know that's the right state because only f of them

  • are malicious.

  • So in fact, if you use Catena with 2f plus 1 replicas,

  • I claim that you can get sort of a permissioned blockchain that

  • sort of leverages the bitcoin blockchain to do the agreement

  • on the log of ops.

  • So in that sense, it's sort of a mix of a permissioned

  • and permissionless.

  • We haven't studied this like we don't know

  • what properties it would have.

  • So that's future work.

  • And if you don't need the execution, for example,

  • if all you're doing is you're agreeing

  • on a public key directory-- like here, there's no execution.

  • This directory just is supposed to stay append-only,

  • we have some research that allows

  • you to prove that every transition is

  • an append-only directory.

  • And if you only need execution, you

  • can just use Catena directly as I already

  • told you guys for the software transparency

  • application for the public key directory application.

  • And if you want to do a permissionless blockchain then,

  • of course, you would have to roll your own.

  • But you have to proceed with caution there, right?

  • It's not an easy thing to do.

  • OK, so let's conclude now.

  • What we did here is that we enabled these applications

  • to efficiently leverage bitcoin's consensus, right?

  • So clients can download transactions selectively

  • rather than full blockchain and prevent equivocation.

  • Right, and you only need to get 46 megabytes instead

  • of gigabytes from the Bitcoin blockchain.

  • So why does this matter?

  • These are just I think the three killer apps--

  • secure software update, public key directories--

  • by the way, the public directories

  • also are applicable to https.

  • So when you go on Facebook, you have

  • to get Facebook's public key.

  • The certificate authorities that sign the public keys

  • are often compromised.

  • So they're often fake search for Google,

  • for big companies like that.

  • And you might use it.

  • But if you have a public key directory,

  • Facebook and Google can immediately

  • notice those fake sorts.

  • It's a step forward.

  • And for more, of course, you can read our paper.

  • It appeared in a IEEE security and privacy 2017.

  • And I'll post the slide on GitHub too.

  • So there are links there.

  • Yeah so, again this is the high level overview of everything

  • that's previous work and our work.

  • The difference is very small.

  • And now we can also talk about other stuff.

  • In fact, I have more stuff to talk.

  • But before we do, I'd like to have a discussion with you guys

  • if you have questions.

  • So?

  • AUDIENCE: So could you implement Catena in the actual bitcoin

  • node?

  • Would that be something that they would want?

  • It seems like it would be a good feature to add?

  • Or is it strictly separate?

  • ALIN TOMESCU: Yeah, I don't think you need to.

  • That's the whole point, right?

  • The whole point of the research is

  • how do we use bitcoin without getting the miners to accept

  • a new version of bitcoin, without changing bitcoin

  • in any way?

  • So no, I don't think-- there's nothing to do really,

  • we're just--

  • we're taking bitcoin as it is and we're

  • piggybacking on top of it.

  • We couldn't change it.

  • I mean, there's a lot of things you can do in some sense.

  • But then you get a very different system.

  • Very different, we can talk about it more if you want.

  • Yeah?

  • AUDIENCE: You were talking about how you can use this system

  • to verify software binaries and how

  • you want this to run in SPV modes on phones So

  • how do you install software on the phones say,

  • through apple and the app store.

  • Is there a way to sign the binary that you actually

  • get from the app store?

  • ALIN TOMESCU: I think your question is really about how

  • do appstore binaries--

  • how do you Verify App store binaries?

  • It's a chicken and an egg in some sense right,

  • is that what you're saying?

  • Yeah, you're right.

  • Eventually, I mean in the best case,

  • wishful thinking would be to say that look,

  • the app store does this already for all of the binaries

  • that they publish, allowing the developers to make sure nobody

  • is posting malicious binaries on the app store for them.

  • Yes?

  • AUDIENCE: Who do you envision running it?

  • ALIN TOMESCU: So I'd really like to see Keybase run Catena,

  • it seems like a missed opportunity

  • that they don't do this.

  • I'm sure they have better stuff to do but it's just really

  • easily allow Keybase--

  • let's say Keybase has a mobile phone app,

  • it would allow that mobile phone app to verify the directory

  • and get much, much, much more security.

  • You know, no equivocation as long as nobody forks bitcoin.

  • Since Keybase is already publishing these digests

  • but they cannot be audited efficiently on a mobile phone.

  • I mean they can but not securely you know,

  • because full nodes can lie.

  • So there's a big problem with everything I said so far.

  • And nobody caught it.

  • So one problem is that what do you

  • do when you run out of funds?

  • Remember I said the log server starts with two bitcoins.

  • Let's say it issues thousands of transactions,

  • starts paying those $40 fees and it runs out of funds.

  • What do you do?

  • Then Yeah?

  • AUDIENCE: You can maybe reload the new transactions

  • with this transaction [INAUDIBLE]..

  • ALIN TOMESCU: What's your name?

  • AUDIENCE: Raul.

  • ALIN TOMESCU: Raul.

  • So Raul is saying you can reload.

  • And that's exactly right.

  • We just have to change the transaction format slightly.

  • We talk about this in the paper as well.

  • But just to demonstrate real quickly.

  • Suppose, let's take a ridiculous example which hopefully

  • will never happen in bitcoin.

  • But suppose that the Bitcoin fee is 1 bitcoin.

  • So now I have one bitcoin here.

  • And I have s1 here.

  • And now I have zero bitcoins here.

  • All right, so zero bitcoins in this output.

  • And maybe s2 here.

  • So that would be terrible.

  • Right, now I can't go on.

  • Does everybody see this as a problem?

  • Right, so what Raul is saying is look at another input

  • here and make it take coins from some other transaction

  • whatever, 20 bitcoins.

  • And now you get 20 bitcoins here.

  • Right, so you can easily refund transactions.

  • There is a bit more subtlety there in the sense

  • that you don't want to join logs--

  • let's say if you have two logs, GTX and GTX prime

  • for different applications.

  • Right, and they start issuing statements-- s1, s2.

  • You don't want to be able to join--

  • I'm sorry, s1, s1 prime--

  • these two locks to a single log for certain reasons right.

  • But this doesn't actually allow you to join them

  • in the sense that--

  • let's say you actually do this and join them.

  • Right, so let's say this transaction here

  • came from GTX prime, right?

  • And there was an s1 prime here.

  • And you did this, right?

  • So the problem is this is no longer a valid Catena

  • transaction for this log because a valid Casino

  • transaction-- the first input spends

  • the previous transactions output.

  • But in this chain, it's the second input that

  • spends the previous output.

  • So I cannot join logs.

  • And this matters for a bunch of reasons

  • that we don't have to go into.

  • Yeah, so we talked about the about batching statements.

  • I want to show you guys some previous work,

  • so how did some previous work do this since there

  • we seem to have a bit of time.

  • OK, so there are some previous work

  • called liar, liar, coins on fire.

  • Have you guys seen this?

  • So the idea here is that it is a really nice piece of work

  • and lots of people in the bitcoin community

  • already know about this.

  • And I think it was an idea before the paper or maybe not,

  • I'm not sure.

  • But Tadge has a similar idea.

  • So for example, suppose we have this authority.

  • Imagine this is a Catena block server

  • and it publishes a transaction which locks to bitcoin

  • and locks those bitcoins to that public key.

  • And this authority sometimes will want

  • to say two different things.

  • It will want to say s and s prime, right?

  • And it will sign the statements with their secret key.

  • But the secret key that the authority

  • uses to sign statements is also a bitcoin secret key.

  • It's the same secret key that the authority

  • used to lock to bitcoins, so $20,000 or something.

  • I'm not sure if bitcoin plummeted since yesterday,

  • can never be sure.

  • Does the setting make sense?

  • So I have an authority.

  • It issues statements just like before.

  • And it numbers them with i, let's say.

  • And we want to prevent this authority from equivocating.

  • We're not actually going to prevent it.

  • We're just going to disincentivize it in the sense

  • that if this authority equivocates like this

  • for the same statement i, what I claim

  • is that anybody can then steal that authority's

  • bitcoin because equivocating like this

  • reveals the secret key.

  • And the reason it reveals the secret key

  • is because the signature shares the same i here.

  • So how many of you guys actually, you

  • did cover Schnorr signatures, right?

  • So did Tadge talk about how to do this with Schnorr?

  • AUDIENCE: This is the [INAUDIBLE]..

  • ALIN TOMESCU: But did Tadge cover it?

  • AUDIENCE: Yes.

  • ALIN TOMESCU: OK, great.

  • So yeah so let's go over that less briefly.

  • So again, the idea is that if someone observes these two

  • signatures on conflicting statements for the same i,

  • there is this box where you can put the two signatures

  • and get back the secret key.

  • And once you have the secret key,

  • we can spend this transaction and get

  • that authority's bitcoins.

  • And then there's a lot of details

  • to get it right because you might notice

  • that if the authority does this, before they do this,

  • they might already be spending this transaction themselves

  • so as to prevent you from taking it.

  • And details on how to prevent the authority from doing that

  • are in those paper.

  • Yeah, and then you know, whoever discovered

  • this can spend those bitcoins.

  • And the idea is that this disincentivizes equivocation

  • by locking these funds under the secret key

  • of the bad authority.

  • But it does not prevent it.

  • Right, so in Catena we actually prevent equivocation.

  • We say, if you want to equivocate,

  • you better fork bitcoin.

  • Here they say, if you want to equivocate,

  • you're going to lose $20,000.

  • Right?

  • But you have to understand like this

  • could be a good authority that locked $20,000 here.

  • But the attackers are going to be-- they're not going

  • to care about those $20,000.

  • They're just going to steal the secret key,

  • equivocate and then the authority

  • is going to be left without money.

  • If the authority is the attacker,

  • then this makes sense.

  • But if the attacker is not the authority,

  • then this makes less sense because the authority sort

  • of risking their bitcoins on the assumption

  • that no attacker can compromise them, which you know,

  • if you could do that in computer science,

  • I wouldn't be sitting here talking to you guys.

  • OK, so now how do you do this?

  • So do you remember Schnorr signatures real quickly?

  • An easy way to do this is using Schnorr signatures.

  • And I think--

  • I could be wrong, but I think this new SegWit

  • update to bitcoin allows Schnorr signatures, right?

  • So with SegWit and with Schnorr signature,

  • as you can definitely do this.

  • And the idea is that Schnorr signature

  • if you recall, is just k plus h of m, g to the k s,

  • where s is the secret key.

  • Right, so this is a Schnorr signature on m, right?

  • How many recall this?

  • Right, and of course, it's not just this.

  • I mean, the signature is really this and this h of m,

  • g to the k.

  • So it's these two things, right.

  • But now I want to show you that if I sign two different things,

  • I can actually get s.

  • But if I sign them in a certain way--

  • so remember what I said before is I would like this authority

  • to sign i m and i m prime.

  • Right, and if the authority does this,

  • I claim that I can get the secret key out.

  • But I have to have the same i.

  • So we relax this in a sense that we're not

  • going to use i here, we're just going to use this g to the k.

  • So if the authority uses the same g to the k to sign,

  • then we can extract the secret key.

  • And the way we can do that is I'll just show an example,

  • sig1 would be k plus h of m1 g to the k.

  • And it'll be sig 1 and I guess the associated hash

  • E1 would be h m1, g to the k.

  • Does everybody see this?

  • And then sig2 would be k plus h of m 2 g to the k.

  • So again, oh, you guys are clearly not paying attention.

  • I forgot the secret key.

  • E2 is hash of m2 g to the k.

  • OK, so I'm using the same g to the k and the same k.

  • So now how can I extract the secret key?

  • Does anybody see a solution to this?

  • AUDIENCE: It's now just system of two equations and two

  • variables where k and s are the unknown variables.

  • ALIN TOMESCU: So I think what Rahul always saying

  • is that s is just sig1 minus sig2 divided by e1 minus e2.

  • Is that right?

  • Yeah.

  • See this, because if I subtract this from this,

  • I just get h m1--

  • I'm not going to have space here.

  • I get-- let's say it here--

  • h of m1, g to the k minus h of m2 g into the k times s.

  • All right?

  • And now I take this here in the denominator

  • and I simplify and I get s.

  • All right.

  • So it turns out that that's kind of the trick

  • that this word leverage is more or less.

  • The only sort of caveat here is that remember I said,

  • there is a position i for the statement.

  • But now I'm saying, there's no longer a position.

  • We have to use this g to the k.

  • And how do we map positions that are g to the k

  • is another trick that you have to do but you can do it.

  • And if you want more details, you can read the paper

  • and I'm sure Tadge will tell you even more details about this.

  • I think the lightning network also leverages

  • this trick in some cases.

  • All right now, let's talk a little bit about some attacks

  • if there is time.

  • The most interesting attack would be the generalized vector

  • 76 attack.

  • So this is a screenshot from a paper.

  • Can everybody see this?

  • So the generalized vector 76 attack is very interesting.

  • So you have you have an attacker, right?

  • And remember, the goal of the attacker is to replace--

  • let's say this TX1 with that TX2.

  • It's going to show this TX1 to a merchant saying hey,

  • I paid you money.

  • And then it's going to show this TX2 to the merchant sending

  • the money back to himself.

  • So the whole trick is to fork the merchant on this side

  • and then to switch him back to that, right.

  • It's a sort of a pre-mining attack and this attack is much

  • easier to pull on SPV notes because what the attacker does

  • is--

  • let's see-- he works on the secret chain with TX1 in it.

  • And at some point, the main chain might take him over,

  • might win.

  • So the attacker kind of gives up and keeps trying.

  • But at some point the attacker gets ahead,

  • right in the second chain.

  • He gets ahead of the main chain.

  • This stuff is not posted yet.

  • And let's see this merchant only for some reason because they're

  • silly, they only need one confirmation to accept the TX1.

  • And for other silly reasons, this merchant

  • is an SPV merchant, right?

  • Let's draw a figure here.

  • So this merchant is an SPV merchant

  • that only needs one confirmation to accept the transaction.

  • So we have the attacker.

  • And we have let's say, the SPV merchant.

  • Right, and now the attacker's sent you know,

  • this was the main block there, let's say, this was bi.

  • And the attacker forked it.

  • He put TX1 here.

  • And then had a confirmation on it, right?

  • So he sends this chain to the merchant.

  • And the other miners haven't found anything yet.

  • Right, so the attacker is a bit ahead.

  • So he's pre-mining.

  • So far, so good.

  • Are you all with me?

  • And remember that he really just is showing block headers.

  • So these are not full blocks.

  • He's just showing block headers.

  • They're much smaller blocks, 80 bytes.

  • And the blocks are missing.

  • All right, so when he shows TX1, he

  • is just showing like a Merkle path to TX1 to the merchant.

  • You guys with me?

  • OK, so now he did this to the merchant.

  • And now what the attacker is going to do,

  • he's going to relax, sit back, and post

  • the TX2 the mines-- give TX2 to the miners.

  • Let's say the miners are here.

  • Hes going to post TX2 to the miners.

  • And he'll stop mining the attacker.

  • He's not going to mine anymore.

  • But he got the merchant to accept the payment.

  • And the merchant shipped the goods.

  • Maybe this is an online purchase.

  • And so now the miners, they will find the next block bi plus 1.

  • They'll put TX2 here.

  • They'll find the next block and then the next block.

  • And they'll take over.

  • Their chain will be the main chain.

  • And eventually this merchant will

  • hear about this main chain.

  • And he'll just see the headers, of course,

  • because he's an SPV merchant.

  • So now the SPV merchant just got double spent.

  • Does everybody see this?

  • That I just double spent the merchant?

  • And sort of the fundamental problem

  • here is that the merchant only received block headers.

  • So he cannot take these block headers and broadcast them

  • to the miners because miners don't mine on top of block

  • headers.

  • Miners mine on top of full blocks.

  • So this merchant cannot has no protection against this

  • if he's doing SPV--

  • if he's accepting SPV payments.

  • If these were full blocks, what the merchant could have done

  • was the following.

  • The merchant would have would have

  • received the full block here with the transaction in it,

  • right.

  • So again the attacker got ahead.

  • But now the merchant because he saw a block,

  • he's going to ship this block with TX1 to the miners

  • because he's a full node.

  • Full nodes do that.

  • When they hear about a block, they broadcast it.

  • So now the miners know about this block.

  • They're going to continue mining on top of it.

  • And in fact, the merchant will send both blocks,

  • right to the miners.

  • So now miners will continue building here.

  • So now the attacker has a bit of a tougher problem on his hands.

  • There is still a way to trick even full nodes,

  • even if this guy is a full node, you

  • can sort of leverage some timing assumptions

  • to still trick the full node.

  • And the details are in that paper over there.

  • But that's one way--

  • somebody was asking, I think you were asking Anne, right--

  • about SPV nodes and how they're less secure.

  • And this is one fundamental way in which they're less secure.

  • If you accept payments with SPV nodes

  • you're really playing with fire.

  • You know, you do need a sufficiently powerful attacker

  • who can get ahead.

  • But yeah.

  • OK, so with that I think that kind of concludes the lecture.

  • Any final questions?

  • All right, cool.

  • Thank you guys.

The following content is provided under a Creative

Subtitles and vocabulary

Click the word to look it up Click the word to find further inforamtion about it