Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Greg Slepak: The Turtle Crawl Towards Internet Decentralization

Episode Date: July 27, 2015

Amidst all the discussion of alternative uses of blockchains, it is often forgotten that the very first fork of Bitcoin, Namecoin, pursued a daring vision for a decentralized, censorship-resistant internet. Greg Slepak, co-founder of the okTurtles Foundation joined us for an interesting discussion of DNS, Namecoin and how blockchains can be used to decentralize the internet. Topics covered in this episode: What DNS is and the role it plays in the architecture of the internet What man-in-the-middle attacks are and why certificate authorities offer poor protection How certificate authorities, SSL, IP routing and VPNs work Why the current model is broken from a privacy and security perspective How Namecoin and the blockchain could enable a decentralized and more secure internet The security risks when online identity is tied to a private key and how they could be mitigated What DNSChain is and what projects okTurtles is working on Episode links: okTurtles Foundation Namecoin Primer Namecoin Website Airplane Wifi is not safe DNSChain demo This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/089

This episode of Epicenter Bitcoin is brought you by Ledger, makers of the Ledger Nano Hardware Wallet. Half piece of mind and knowing your private keys are protected by industry standard physical security. Go to ledgerWallet.com to learn more and use the offer code EB-09 at checkout to get 10% off your first order. And by CoinCap.io. With over 500 altcoin exchange rates updated in real time, CoinCap is the authority for cryptocurrency. market information. Hi, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and startups driving decentralization and the global cryptocurrency revolution.

My name is Sebastian Kutjua. And my name is Brian Fabian Crane. We're here today with Greg Slepac. He is the co-founder of the OkT turtles Foundation, which is a nonprofit that works in the sort of beneficial use of decentralized technology. The thing that sort of comes to mind and that we were recommended to have them on for is is DNS, but they've broadened their focus since then. So I'm really excited to have Greg on to talk about some topics that I don't know that much about.

Thank you for having me. And we've broadened our focus for sure. But we're certainly still focused on DNS as well. So it's not like we've abandoned it. We're definitely still working on that. I'm certainly glad about that. Well, let's get started with that topic of DNS, if that's okay with you. and then maybe later we can talk a bit about the OK Turtles Foundation in general

and also some of the other things that you guys are working on. Sure. So with DNS, can you tell some people who are, you know, technologically illiterate or semi-illiterate, like myself, maybe slightly exaggerating, what exactly DNS is and what its role is in the sort of architecture of the Internet today? Sure. there's so much technology out there for people to try to wrap their heads around.

So not understanding one component is certainly understandable. I'm fairly illiterate to how my car functions today, for example. And DNS is this one part of one central, crucial part that underpins how the Internet works. The purpose of DNS, it stands for a domain name system. It's the system that makes it possible for you to visit websites. That's basically a very rough description of it. So it's specifically the system that is responsible for converting website domains, like, for example, Twitter.com, into the digital address of the actual computers that are running.

It's how your computer is able to find those Twitter servers on the internet. So, I mean, DNS plays such an important role in just how we use the internet every day. Everybody uses DNS all the time without even knowing it every time they attack a URL. So it's my understanding that, so there are multiple DNS servers, sort of high-level servers around the world, and that for every top-level domain, there are also DNSes. And so the top-level servers sort of ping those. So if you go, for example, a doc-TV domain name, you know, the DNS server. that you're connecting to will then go and find the DNS server from the Tuvalu Islands and,

you know, they'll send you back the IP address. Is that? Well, I'm surprised you're going into such depth immediately because maybe we should just describe what an IP address is first. Oh, no, no, no. I think our guests, our listeners know what an IP address is. Yeah. Well, I think it's worth, because I was actually going to ask exactly. So the way you talked about it, right? So what's the role of IP addresses there, which is basically, right, the address of those computers or servers that then either host a domain or that may be host on the other side, the user's computer or some other destination?

Is that correct? So you can think of an IP address as just like the digital internet version of a house address. So when somebody gives you your house address, they are able to, you know, give it to people so that they can drive to your place and meet you. Well, on the Internet, it's very similar. They use numbers. And when you give somebody an IP address, your computer is able to, through a series of networked routers, find the destination that it wants to communicate with.

But IP address, the problem with IP addresses is that they're very difficult for humans to memorize. it's far easier for me to remember Twitter.com than it is to remember the IP address, the numbers that represent Twitter.com. And furthermore, those numbers change. And sometimes they change fairly frequently. So Twitter.com may even, you know, change the IP addresses throughout the day

based on load balancing or from where somebody is trying to contact Twitter. So that's why it's really useful to be able to ask what is the IP address for Twitter.com and then communicate with that address because the number that you get could be different as well. And that question, what is the IP address for Twitter.com? That's the kind of question you would ask to a DNS server. That's right. Okay, so your computer would sort of have hard-coded in it maybe or your router or something. the address of some of these DNS servers

to go there and then ask, where is this domain, where is this domain, where is this domain, and that gives it back the address, the IP address of that domain, and then the computer knows where the ping to get Twitter or something like that. Right, yeah, and they're not hard-coded. Your computer gets the DNS server's IP address from your, usually for most people,

from your internet service provider. So, for example, if you get your internet from Comcast, you'll be using Comcast DNS servers. But that doesn't mean that you have to. You can go into your computer settings and change the DNS server IP address to anything you want. And so you could use different DNS servers. Right. So, for example, like Google has their own DNS or you have open DNS, which are sometimes faster than some of the DNSes that, or have other, you know, additional features that some of the, the ISBDNES have, you can go in and change those.

Yeah, let's maybe pop the stack a little bit because it's almost like becoming a computer science course or a networking course right now. And maybe our audience is like wondering, well, you know, why are we talking about this? What is sort of the importance and the significance of discussing this internet DNS stuff? I mean, what first comes to mind is censorship and also security. So those two topics play a huge. and significant role in DNS. And it's why we really need to understand these systems and what's going on with them.

Because if I, for example, in many countries, they censor websites. And they can, they do that through the DNS system. So they can block Twitter just by making their DNS servers refuse to give you Twitter's IP address. Okay. So, but what does that mean if you know Twitter's IP address from somewhere else and you don't have to rely

the DNS server to give you that IP address, you can then sell access Twitter? That's right. But not in all circumstances. So I believe in Turkey, they were doing something along these lines, where they were simply preventing their DNS servers from telling people about Twitter's actual IP addresses. But if people, and so you might have seen also images of Google's DNS server IP addresses spray painted onto walls 8.8.8.8. It's a very easy to remember number just eight four times. And so people were simply manually changing the DNS servers they were using and then they were able to access these websites. But in other parts of the world, like in China, they go a step further beyond the DNS system and actually block the IP addresses,

block communication to Twitter's IP addresses. So the issue of censorship, I mean, it is a issue if you're in Turkey, if you're in China or if you're in some part of the world where there may be some insurgency or some sort of protests and the government is trying to regulate and censor information that is coming out. But in most cases for people living in the developed world or even in developing countries where there isn't necessarily like institutions institutionalize internet censorship like in China, for instance. This isn't really an issue day to day. But it can be a problem.

I mean, this is what I want to ask you is how can it be a problem then in terms of being a vulnerability for just regular people being exploited by hackers, for instance? Right. So that's the second major problem that can occur with. the DNS system. Maybe can I just, so I think Sebastian's question is great, but I just wanted to sort of circle back here, because the flip side of what Sebastian just said, does that mean that, you know, for me living in Germany, spending time in Europe, et cetera, does that mean that that first

question of censorship is really something that personally I don't have to care about and maybe more from a sort of moral perspective or because of, of, of, you know, other people of political reasons I may want to care about, but like practically, it doesn't affect me? Well, if it doesn't affect you, it doesn't affect you. If you care about the fact that it affects other people, then there are steps that you can take to help those other people to get around the censorship that they're experiencing. And that's actually something that we were working on as well, this subfeature of DNS chain

called Unblock, which we can get to. But to go back to what Sebastian was saying, the second big problem that is, you know, can occur with DNS that has nothing to do with censorship is simply security issues. And these are actually, you know, fairly significant where people in developed countries or, you know, in the so-called first world, they can, the DNS system can be used against them to make them visit malicious websites or simply as a form of surveillance. So that's, that's probably a third issue that we should bring up as well that every website that you visit, you know, that the fact that you visited that website is being recorded somewhere. So does that happen because like let's say I'm at home,

I'm using my ISP, I'm asking them, can you give me the IP address of Twitter? They give me the IP address of Twitter. So now my ISP knows I went to Twitter and they record that and they can give that to the NSA or something. Is that what you're talking about? Yeah. Yeah. And then there's the problem where your ISP or somebody between you and your ISP could give you the wrong IP address to a website that looks like Twitter, but isn't Twitter.com. And they can perform attacks based on that. So for that, we have a different system called HCTPS to try and protect against those kinds of attacks. And so those attacks are just man in the middle attacks, essentially where you have you and your ISP or you and the ISP and the server you're connecting to and someone is sitting in

middle and is pretending to be the website you're going to, but in fact, they're just passing the data through their own system and potentially manipulating it or collecting it. Right, right. So just to clarify that, so how, if I, if I was now the ISP or someone, someone like that, how would I go about doing that? Because I mean, I don't, I'm not Twitter, right? I don't have, for example, their server code or something. So does that mean I would, let's say Sabancia, you wanted to access Twitter

and I wanted to do a manual and middle attack? I would get your user request and I would go to Twitter and just get their HTML and JavaScript and show that to Sebastian. So it looks like Twitter, but it's actually my code and I can change it. And then I feed his responses back to Twitter. Is that how it would work? Essentially, well, yeah, so let me try to give some more details to what you're saying. So for the purpose of this example, let's just forget about HTTP

and pretend that Twitter was being served just over HTTP. And what does that mean? That means that the connections are not encrypted and they're not authenticated. These are, for the purpose of, I guess, this conversation, these are probably two of the most important themes that we should be kind of discussing in and periodically revisiting. The two concepts of encryption and authentication. So let me just quickly cover that. Encryption is when you take information that a human can read and understand and make it unreadable to them without some kind of a secret.

That's unknown to them. And authentication is when you... ensure both the integrity of the data and that you're actually talking with who you think you're talking to. So I can be having an encrypted conversation with somebody, but I might not know who that person is. I might think there's somebody else. And that's, and that basically makes the conversation not secure. So for a conversation to actually be secure, it has to be both encrypted and strongly authenticated. So, but to go to the example where you were talking, about man in the middling Sebastian's connection to Twitter. Let's just consider what would happen

if Twitter wasn't using HTTP. They weren't encrypting the connections to their servers. All you would have to do is pretend to be Twitter. So you could have a server running somewhere that serves a website that looks just like Twitter.com. You could even be passing traffic back and forth between Twitter.com and Sebastian without even having to necessarily copy Twitter's interface or anything like that. And then just reading what's the conversation, you know, you would be able to steal Sebastian's password and then hack into his account. Or you could modify, or you could inject like little pieces of JavaScript or something into Sebastian's version of Twitter.com that could also do various malicious things. And to do that, you would have to be

somewhere on the network in between Sebastian and Twitter.com. And so if we're bringing HTTPS into this mix, I mean, I have a pretty good understanding of how this works and what you're, so if I just rephrase that, so basically when you're on a non-secured connection, even within your own house, or when you're at a cafe, for instance, if you're using non-HGTP, yes,

just plain HTTP, everything that's going out of your computer is in plain text, so that includes logins, passwords, etc. And then in that case, it's really simple and pretty trivial to do a man in the middle attack. Forget copying the interface and feeding it back to the person. You can just grab usernames and passwords from the traffic.

Now, when you start having HTTP connections, that's where I start to not understand how it works. So can you explain how in an HTTP scenario, let's say Brian and I are in a cafe, Brian's met in the middleling me, and I'm using Twitter on HTTP. How would that work? I'm going to actually explain how that would work. I would have to talk about public private key cryptography and do my best to keep it simple, basically, to actually answer your question in other words.

So I apologize if this gets a little too technical, but I'm going to try to keep it as simple possible. There are two kinds of cryptography. One is called symmetric cryptography and the other is kind asymmetric cryptography. Or rather, I should say, there are two kinds of encryption. I think we can assume that people do know, you know, this is a Bitcoin podcast and a podcast of a cryptocurrency. So, you know, with public and private keys and with Bitcoin, I think people are familiar with public and private key cryptography. Right, right. So the kind that's used, in HTTP is asymmetric encryption. And here's what that makes possible. In asymmetric encryption, there are two keys. These are two pieces of data. One of them is kept secret,

and it's called a private key for that reason. The other one, you tell anybody, anyone who you want to be able to send you a message securely so that nobody except you can read. And that one is called the public key. So you give your public key, which is just a piece of data, to the people that you want to be able to communicate with you securely. So in this case, Twitter.com would send you their public key. And then using their public key, you can pass all of the messages you want to send to Twitter.

You can encrypt them with that key and then send them to Twitter. And that encrypted information can only be decrypted read by Twitter because only they have the private key. That's the basic idea. but in reality that's not entirely how things actually end up working or rather that that is how things end up working but there is a problem in HTTP and this is kind of the same problem that happens

in all secure communication applications which is how do we get the public key to the user securely without that key being switched on its way there and that's the basic attack so if I wanted Sebastian to be able to send me a secure message, I would have to send him my public key. If I send him my public key over the internet, then somebody in between us can receive my public key and send Sebastian their public key instead without him knowing that.

So when Sebastian communicates, thinking he's communicating with me, he's first communicating with this man in the middle. And so as he sends his message on its way to me, he's encrypting that message with the public key that belongs to the man in the middle. And then the man in the middle decrypts it using his private key and re-encrypts it using my key. And so the man in the middle is, again, it's as if we were still talking in plain text. The man in the middle is able to read everything and he's able to manipulate any of the

data. Right. So neither Twitter realizes that they're encrypting the stuff with the wrong public key, nor does Sebastian realize that he's encrypting stuff with the wrong public key. and so it may look like a perfectly fine interaction where nobody realizes that they're being attacked. Effectively. Well, so HTTP is, that whole system

tries to address this problem, but it doesn't do it very well. Here's how it tries to address this problem. It says we're going to trust these authority figures who are going to vouch for public keys, basically. everybody on the internet is going to trust these people. These people are called certificate authorities. They're not really people.

They're more like entities, organizations, which can have many people working for them. And so web browsers actually ship with the public keys of these organizations built in. So a web browser might ship with, say, 200 of these public keys. Like when you download a web browser, it comes with those keys packaged into it. This technique is referred to as public key pinning.

When you pin something, you basically ship it with the software so that you have that key already known beforehand. And these 200 organizations or so, they can actually allow other organizations called intermediate certificate authorities to have the same power, which is vouch for the authenticity of some website. So when Sebastian visits Twitter.com, he'll see this little lock icon in the main. menu bar. And if he clicks on that lock icon, he can read about all of the information that I'm talking about. He'll see the name of the certificate authority there. It'll show that information there. If you click on the lock icon and view more, different browsers do it different ways, but they'll all give you some way of seeing what certificate authority said that this connection was secure. And how did they do that? The way that a certificate authority vouches for the

security of an internet connection, is they basically sign a message using their private key. And they're able to sign website public keys. So Twitter.com can go to a certificate authority and say, please sign my public key. And then they'll be given a document called a certificate that proves cryptographically that that certificate authority said that their public key is legitimate. So the implications of that would then be if you want to do that man in the middle attack, but now we have HTTP in the fold, right? If I'm the attacker between you and Sebastian, I would need to get some certificate authority to sign my public key so I can pretend that I am Twitter to both of you. Exactly. Yeah, that's exactly it. Because I guess there are a thousand of them.

well, you know, it's not it's totally not unfeasible that some of them or at some point some of them will be corrupted and particularly if you are a government authority then you'll be able to force them to sign your public keys.

Yeah, and you don't even have to force them necessarily. You could hack into them and without their knowledge, sign a certificate. In terms of protecting yourself against this, there are different ways that you can do that, I believe. So we'll talk about DNS chain, et cetera, in a minute. But using a VPN, you know, most people think, so I personally use a VPN when I connect on a public Wi-Fi or something like that.

And I'm pretty confident that gives me a good level of security. But now I'm putting, I'm sort of questioning that because if I'm using a VPN, and I'm using DNS to connect to that VPN, that is now a potential, vulnerability in that connection. Well, DNS, so this is something that we should make super clear, which is that DNS in the face of HTTP

actually does absolutely nothing for security. It plays no role, is what I'm trying to say. So once you add HTTPS to the picture, DNS becomes totally irrelevant, at least when you're connecting to a website over HTTP.

Because a malicious, DNS server could give you the wrong IP address of some malicious server. But ultimately, if that server wants to be able to man in the middle of you, they're going to have to get this certificate from a certificate authority that's signed by that certificate authority and show that to you. And your browser will be able to verify whether one of the certificate authorities that it trusts signed that certificate. So DNS doesn't play a role there.

And in terms of VPN, oftentimes the configuration for VPNs will have, actually contain the public key of the VPN that you want to connect to. So that doesn't even depend on the certificate authority system. And that will secure your connection between you and the VPN. But then when you connect to a website over HTTP, over that VPN connection, from the VPN to the website, it could be man in the middle by a rogue certificate. And here's the crucial point that people need to understand.

when you collect all of the root certificate, all of the root certificate authorities, these are those 200 or so that web browsers trust. And both web browsers and operating systems ship with these lists. When you aggregate all of them, and then when you aggregate all of the intermediate certificate authorities that those certificate authorities vouched for, according to some research that some people did,

you get a number that's over 1,200 organizations. and you are trusting every single one of those, which means that you're actually trusting the rotten apple in that group, the least trustworthy person. And most people have never met these people. Most people can't pronounce most of the names of the certificate authorities because many of them are in foreign languages that they don't speak. And any single one of those, if there's any kind of a problem with any one of those,

if any one of them gets hacked, if any one of them gets coerced, that certificate authority has the power to create a certificate that can be used to man in the middle, any website on the entire internet. So each one of those, that's too much power to give to so many entities that people have absolutely no reason to trust. And if people are wondering, has this happened? Yes, this has happened. Yeah, this does sound like an awful security model, no? Like, I think any system where you have to trust 1,200 entities that they're all honest,

that is obviously not very secure. Yeah, not only that they're all honest, but that they're all competent. I think another really important takeaway from this. And what I tell people constantly is that, I mean, just forget HTTP and these certificate authorities perhaps being corrupted or coerced or hacked.

I mean, when it comes down to it, but people need to realize is anytime they use public Wi-Fi, which is all the time, they might as well assume their data as being manipulated, red. I mean, most people have no idea. You know, they log into Facebook when they go to a cafe or their email or whatever, completely unaware that I think someone may have said sometime at some point that, like, in the US, you have two out of three chances of being hacked on a public Wi-Fi.

But if it's with HTTPS, then you may still be secure, right? So HTTP reduces the likelihood that you'll be hacked, but it doesn't eliminate it. Exactly, yeah. And in fact, they can give like a false sense of security to people because they will see a lock icon, a green lock icon in their menu bar, and they'll think that they're on a secure connection. But as we've just discussed, that might not necessarily be the case. And there was an interesting article in Venture Beat this week that mentioned the proliferation of Wi-Fi and airplanes and how that's just a hot mess, because now,

Now you have the situation where potentially for like five, six, seven, maybe ten hours, you have hundreds of people connected to this public Wi-Fi network and, you know, one malicious person in that airplane could be men in the middle thing or attempting to men in the middle them for, you know, that, having that extended window essentially to try to attack those people. Yeah, be very careful when you're on an airplane. I recommend against using the public Wi-Fi, at least if you're doing anything important. Let's take a short break so I can take you to Paris. I dropped into La Maison du Bitcoin, the House of Bitcoin,

in the heart of Silicon Centrier, home to many startups, including Ledger. And I spoke with Eric Larchevec, Ledger's CEO, about the company's product philosophy. We are tackling a very important problem, which is the security of the Bitcoin. And we really want that all this hardware wallet and security solutions are available for everyone. Our objective is that our solutions are running

in all the Bitcoin softwares, and in the future, we really see ourselves as the leading company in securing all the Bitcoin solutions for customers, but also for enterprises. We want to be the Cisco of the Bitcoin. With the technologies such as the trusted execution environment, which is some kind of trusted zone inside the Android phone, a lot of the hardware wallets will be in fact virtualized and available immediately inside your mobile phones. I'm pretty sure that we will see this hardware wallet. In fact, distributed mainstream has some kind of software secure package for Android phones.

Ledger is building an infrastructure which will provide the best level of security for the Bitcoin industry. You too can benefit from this technology and get an affordable secure setup for storing your Bitcoins with the Ledger Nano. So go to ledgerWallet.com and use the offer code EB09 to get 10% percent. off your first order. That offer code is valid until September 30th of 2015. We'd like to thank Ledger for the continued support of Epicenter Bitcoin. So let's move on to Namecoin and DNS chain. Can you talk about how these new technologies using blockchain can help solve some of these issues? Sure. So when the blockchain came around, this was when Bitcoin was introduced back around circa 2009, 2010 or so. Some people noticed that this technology can be used to create a secure

version of DNS and also fix the problem that we just discussed with HTTP. This one system would be able to solve all of these problems that we've just discussed and these two other systems. It could be used to in fact supplant both systems and it's I think far more elegant. And what it makes possible is ownership of digital information. It makes it possible for the owner of a domain name to directly give you their public key in a secure way without relying on some untrusted third party. Can you explain how this works? Sure. So I think you guys have mentioned that your audience is somewhat familiar with Bitcoin. Is that true? Yeah, it's more than trivial. I think that could be considered an understatement, so yes.

Okay, well, if they're familiar with Bitcoin, then they've probably heard the term blockchain before, which is effectively kind of how the name suggests a chain of blocks. These blocks are chained cryptographically to each other, and they are generated using this random stochastic process around the world, which is based on proof of work. So you can think of a blockchain as a secure, decentralized distributed database.

And when we talk about it, we should avoid making strong statements to the effect that there are no third parties involved at all because in fact there are third parties involved in the Bitcoin blockchain that people are relying on. But these third parties called miners actually don't have all that much power necessarily.

There are some attachment. attacks that are difficult to pull off and are detectable called 51% attacks. They, well, they're semi-detectable, most likely. There is at least a chance of detecting it that can actually reverse history in the blockchain. So if they start doing that, that becomes a serious problem, because if they can reverse enough blocks, they can kind of rewrite history. But what they cannot, they can, for example, in Bitcoin, say if a 51% of

attack was to occur, they can say that a transaction to somebody never happened by reversing blocks. This would most likely be noticed because people would see what are called orphan blocks. Their own Bitcoin clients would tell them that, oh, this long chain that I had is suddenly being replaced. Greg, where how does that relate to the discussion about the issue? Sorry, sorry. I should relate it to I mean, I think the I think people are familiar roughly with 51% attack. I think that's, but I'm... Sure. Okay, so the way that it relates to DNS and HTTP and everything that we've been talking about before is some folks noticed that you can take Bitcoin and modify it slightly and introduce a new transaction type. And this transaction simply says, I'm registering a name using this public key fingerprint.

And so somebody sends this transaction to the blockchain. And this was actually the very first, this feature was the very first fork of Bitcoin. and it was called Namecoin, which allowed people to create these transactions that included names in them. So you could say, for example, I'm going to register OKTurtles.bit, and then your client sends this transaction out to the blockchain, and that transaction is spread throughout the Bitcoin network, or sorry, the Namecoin network, and eventually it will make its way into a block. The miners will look through the previous history and see, has anyone else registered okay turtles.bit so far? Is there an existing owner?

If there isn't, then whoever just sent this transaction owns it. It's made its way into a block, and now nobody else can register it for some period of days until it expires, basically. So does that mean you would put in the block the information, for example, okay turtles.bit, and then you would put in there an IP address as well, so that if somebody wants to go to that website,

they don't have to rely on a certificate authority or a DNS server or something like that, but they can ask the blockchain. Yeah, they can put in more than just the IP address. They can replace both of those systems that we just discussed. Putting in the IP address into that transaction replaces DNS. And putting in the hash of a public key replaces HTTP. And I might not in a much more efficient way than DNS,

because if you can mine a block every 10 minutes and have the new transaction with your updated IP address, that's much faster than what most DNS servers will take to update when you do a DNS change. That's right. DNS traditional, like today's DNS, whenever you change your DNS information, there's something called a propagation delay. In other words, how long it takes for that change to spread through all of the DNS servers on the internet. And that change can often take upwards of 24, sometimes even longer, 48 hours. It depends on this thing called a, TTL, but yes, basically it's very, very efficient.

Okay, that sounds great, but I presume one of the challenges is going to be, how do you get people to use that? Can you expand a little bit more on that? So this sounds like a superior design, I agree. But what's, where does DNS chain come in here? So that's a very good question. the problem with Namecoin is that is kind of the same problem with Bitcoin. Running one of these nodes where you store the entire blockchain is very resource intensive.

And most people aren't going to be able to do that on their laptops or on their cell phones or, you know, various mobile devices. So that's where projects like DNS chain come in. And what we started out with DNS chain was doing something very simple. we said DNS chain will act as a secure proxy to an existing name coin node. And what it will do is simply relay information back and forth between the name coin node and any clients that ask it. And the way we're going to secure it is we're going to say people have to run these DNS chain nodes themselves or have a friend who runs one of them. And then tell people what the public key is of that DNS chain server. In other words, it's a different model from how HTTP works today.

Instead of trusting the least trustworthy out of over 1,000 entities, you're trusting somebody you know, somebody you actually have some reason to trust, and only that person. And for people who can run their own DNS chain servers or people who have tech-savvy friends who can do that, this works fairly well. But it doesn't work well for people who don't have that. for people without a friend who can, you know, a trustworthy friend that runs a DNS chain server,

they're going to have to similarly, like an HTTP, trust someone that they have no reason to trust. And you can improve upon this. You can say basically, instead of trusting the least trustworthy of 1,000 entities, you can query two separate DNS chain servers and make sure that the responses match. And that improves the security. But we can do even better than that. and that's kind of like our future direction with this project, is the development of something called thin client protocols. So this is something that Bitcoin has as well.

In Bitcoin, the best wallets that you can find on mobile devices will be wallets that support something called SPV, which is a kind of a thin client. SPV stands for simplified payment verification. It was introduced in the original Bitcoin white paper that written by Satoshi. And the difference between a thin client and a full node is that a thin client, in fact, you can think of these things on a spectrum with a full node being on one end of the

spectrum, which has all of the information, kind of like you can think of it as long-term memory. It stores all of the history of a blockchain. And then a trusted proxy like DNS chain on the other end of the spectrum, which is not a thin client. And it just basically, you know, you have to trust that it's giving you the accurate information, the accurate current information in a blockchain. A thin client is somewhere in between those two endpoints. A thin client has not all, but some of the information of a blockchain. So it's kind of, you can think of it as short-term memory.

So what you are working on, and that makes a lot of sense, and I think people have an idea of what SPV wallets are, is that in the future people could have this light client, which isn't too resource intensive, that they run themselves, that then queries, the name coin or create a DN, well, do you query a DNS chain server or do you query then directly the name coin blockchain so you can have reasonably secure in retrieve information from there? Is that how it works? It could work either way. And that's why our next step is to focus not on an implementation specifically, but to focus

on a protocol that can be used at any kind of like, you know, either a protocol. that the DNS chain server speaks, or a protocol that full nodes of namecoin or other blockchains speak themselves, because you can do a name coin-like system on top of Bitcoin. And in fact, there is one called Blockstore that the folks at one name are working on. And there are other blockchains that support name registration systems as well. So what we're interested is working on a generalized protocol that can be used with almost any blockchain and various different kinds of thin client techniques. Today's magic word is Turtle, T-U-R-T-L-E.

Head over to let's-stockbitcoin.com to sign in, enter the magic word, and claim your part of the listener reward. Again, I think this makes a lot of sense, right? So this is a compelling vision for an internet that would be more secure and more decentralized and where we wouldn't have some of these vulnerabilities and so. avails and stuff. What about the issue of handling private keys here, right? Because one of the big challenges, and I think we even see that with Bitcoin, is that people aren't very good at taking care of their private keys. That's why people use a lot of hosted wallets such as Coinbase or Circle.

And because if you get your private key hacked, well, people can steal your Bitcoin. And what happened, it seems like here as well, it would be a very bad thing if you get your private key hacked. or let's say a site like Google, would they have like one private key and if it gets hacked? What happens then? Right. This is a phrase that I've used previously to describe this situation, which is that with real ownership comes the possibility of real loss. So if somebody steals your car, like you really own your car, let's say you bought it. If somebody steals it, well, you know, now it's no longer your car.

It's theirs for as long as they're able to hold on to it. Similarly, with this ownership of digital information, which is based on public private key encryption, if somebody steals your private key, they now own your information just as much as you do, and they can transfer it to a key that they own. And then you've suddenly lost your domain name. So this is a double-edged sort, which is why sometimes people rely on third parties for the security of their keys. Could we not have a scenario where there would be certificate authorities that perhaps could act as a second signer in a multi-signature signing setup where even if you lose your keys? Yeah, this is kind of the answer to this problem and the direction that many companies are moving toward is whether or not it's another company.

I've also heard some people trying to develop systems where it's other people. it really doesn't matter what the entity is, whether it's a single person or it's an organization of people, the idea is splitting up your identity or, you know, your... I mean, I get that multisig is, of course, a help here, right?

And if you split your key and you have cosign use and they verify you, et cetera, of course that reduces to risk, but it doesn't remove it. And if we now imagine a world where domains that are a secured doubt, way and you know Google has their domain secured by some private key and let's say somebody stole that domain and there's no way of getting it back. I mean that that seems to be a hugely disastrous

scenario and it seems like if it could happen even if maybe some people would be able to prevent it, maybe most people would be able to prevent it with these kind of multi-sig and cosigner setups. isn't that so big of a risk to essentially prevent that from happening? I don't think it's such a big risk that it could prevent it from happening because there's this counter huge significant risk, which is that whole scenario that we described before, which is basically that if somebody can pretend to be you, did you really own your identity in the first place?

The answer is no, you didn't. So, you know, just as Google could lose their identity in this blockchain world, they can and sometimes do lose their identity in today's world as well. It's kind of a trade-off. I think that we will see different technologies coming about to try and address these problems, things like key revocation. So it's possible to create a system where if Google were to lose its keys, they can still recover them because they created some. piece of information, a sign transaction beforehand that they keep in some sort of secure locked vault somewhere, that they can then broadcast to the network and override whatever changes were made recently. That's one possible system. And they can even reintroduce trust back on top

of the blockchain. So it's possible, I'm fairly certain, it's possible to reintroduce today's existing system in the blockchain. You could probably devise a system like that. And if that's the case, then the blockchain becomes kind of like a super set of today's system. Can you explain how that would look like? I think I'd have to put a lot more thought into it than kind of this conversation allows me. Okay. So it would probably involve some kind of trusted permission blockchain thinking.

So that's really hand-wavy, and I don't like that. But I'm guessing that it's probably possible. Now, I'm curious what your thoughts are on hardware security. So the idea of trusted execution environments being introduced now in mobile phones, the idea of chip cryptography, like these little ledger wallets that we have. And the ability that these technologies, particularly the trusted execution environments, the potential for introducing really good UX around, public, private key cryptography for just sort of everyone to have access to.

Do you see that as a trend towards people being more sensitized to the fact that they need to encrypt their data and potentially, you know, sort of inversing this trend that we've had where people just get their data stolen and read by the NSA, et cetera? Well, I think on this topic, I am definitely in the Open Whisper Systems camp. They are a company, a nonprofit, that specializes in secure communication applications. They've created probably what I think is the most secure, secure messenger on iOS called Signal. And on Android, the corresponding applications are, there are actually signals on Android is two applications. One is called Red Phone and the other one is called TechSecure.

And their philosophy is basically don't talk about keys, don't mention keys at all. Users don't want to hear that word. They don't want to deal with it. They don't want to think about it. And I think that that's kind of where things have to go. And that, in fact, is one of the great virtues of Namecoin and the blockchain, is that it can help do that. Using this technology, using Namecoin, you can build user experiences that don't talk about keys.

That's one of the great things about it. Because one of our interests in Namecoin was developing a secure messenger, which we called the OKT turtles browser extension, which would allow you to securely communicate in a man-in-the-middle-proof way with your friends over any website. It doesn't matter if the website was malicious. You could chat with your friends over Facebook in a way that Facebook could not read. And you could do it in a way that didn't involve you messing with any keys.

The software would automate all of that stuff for you. That's because Namecoin, in effect, solves this thing called Zucco's Triangle, which is this conjecture that in a naming system you can only have two out of three properties. The three properties are the naming system can be secure, decentralized, or human readable. Two of those. Pick two, but not three. Well, Namecoin came along and it showed that you can have a system, a naming system that has all three properties. It can be secure, decentralized, and human readable.

So prior to Namecoin, we kind of had to deal with things like GPG, where you had to go and find somebody's public key, and then somehow verify and make sure that you got the right public key for that person and not a mistaken one. With Namecoin, you can simply know the person's handle, their identifier. Like, I'm Greg on Namecoin, and that's all the information that you need, literally, to be able to send me a secure message.

So again, I think this is compelling, but I would like to talk a little bit about sort of the reality of where is this and how is this going to go and how is this going to happen. Because what we're talking about here is this big vision of an internet that looks different and of communication that works in a different way. And even if I agree that that is compelling and it would be a better internet, is there a roadmap for that to happen? Is that going to happen on a big scale or on a small scale? And do we need, is that the sort of thing where you need this huge network effect? So we need everybody to switch that new system, otherwise it's not going to work. And if not, a huge majority in Chrome and Firefox and everybody starts supporting that, then it's just, yeah, it's not going to work.

What does that look like? The beautiful thing about it is that it can work on kind of an individual level. You don't need Chrome to switch to the system, to have a secure messenger that uses this system. Ultimately, what will end up driving adoption are the applications that people end up creating. And if those applications use this system, well, then it will start spreading if they are actually very good from a user experience point of view. And the blockchain can result in a very, in a much, much improved user experience. So does that mean you see the first sort of avenue where this can actually get used and get some traction in the kind of messaging apps and not on the domain level side?

I think that's one area. I think that there are many other groups that have a need for this technology. This includes big businesses, enterprises that need to secure their systems in a way that's simple for them to manage or simpler than whatever they're currently. doing. And it includes governments as well. It could very well be the case that one of the biggest proponents of this technology could be the U.S. government or some other government, because as we know, they are not very good at securing their information from recent news. Let's move on to the foundation that you co-founded OK Turtles. Why did you call it OK Turtles? The truth is that I just really liked the word turtle for the period of 2012.

I have no idea where it came from, but I like the word turtle in both Russian, which is the language that I was born speaking, which is a chiripacha. And I liked it in English as well. And for some reason, that word just wouldn't go out of my head. But other people have kind of put different stories on top of that. I know that a receptionist, my orthodontist, when she heard the name OK Turtles, and heard about the project, it made complete sense to her

because to her, the turtle is the spirit animal representing security. And if you look at our logo, it's a turtle with a shell that looks like the world. And a shell is kind of symbolic of security. So these are turtles that are okay because they're secure.

So you could make a story along those lines as well. But you know, that's actually the way that I interpreted it when I first went on the website and saw the logo, et cetera. Yeah, I prefer that story. If you could not tell the truth in this case, it would probably be here for a row.

So can you talk about the mission statement and what you're trying to accomplish? I mean, not the mission statement. I mean, what is the mission of the foundation and what you're trying to accomplish? So the mission statement of the foundation evolved. We were first very much focused on the secure messenger that used name coin. And to develop that, we had to develop this other project called DNS chain. And in exploring DNS chain, we started looking at decentralization in general, because Namecoin is all about decentralization.

And it turns out that decentralization as a concept is a great solution to many of the challenges that humanity is facing today in many different diverse fields. Because what happens with centralization is that the more centralization you have in a system, the more it tends towards abuse of power and cronyism. And the answer to that is to decentralize such systems. So our new mission statement is supporting beneficial decentralization technologies. And we throw in the word beneficial because we know that nothing is a panacea, and we want people to challenge us in the things that we support.

We want people to actually view this from kind of an egalitarian point of view. if we end up supporting something that isn't beneficial, we want people to point that out to us. So that kind of, that word beneficial is an almost opinionated term that's thrown there precisely for the purpose of stimulating discussion about whether in fact these systems are beneficial. Are you working full-time on this? Is there a team that's working full-time on the OKTurdles project? I have been working fairly full-time. I mean, mostly I volunteer for the OKT turtles Foundation.

And so for the past many months, even over a year, I started working on DNS chain back in 2013 while I was at the University of Florida as part of my senior project. And so the answer to your question is effectively, yes. I am working kind of or volunteering, so to speak, full time for it. And there is a team, but they're not working full time. But so far we've managed to accomplish quite a lot with very few reasons. sources. Yeah, I mean, to be really honest, I think it's a really, it's a really compelling vision in the long run. And, you know, I was being a bit critical before regarding the private key security.

Of course, that's a problem Bitcoin also has, right? And I think it's a problem that will be solved, right? Because there are so many ways of solving that and it's not easy to solve. And sometimes things will go wrong, but it will be solved. And, and yeah, I think it's a really, really compelling vision. it's exciting what you guys are working on here. Thank you. So is there a roadmap? I mean, I know you guys are working on this browser extension. What can we expect to see in the next months and maybe years?

Well, the next big thing coming is a crowd fund for work to finance us to be able to work on this generalized thin client protocol that I was talking about. We worked on DNS chain. and it's a very important piece of software, but now we kind of want to almost start removing it from the picture, from a security point of view. We want people to not have to entirely trust these DNS chain servers out there because we don't want to repeat mistakes of the past.

So that's the importance of thin client protocols. And thin client protocols are important not just to name coin, but they're critical to Bitcoin. If you're using a, if you're trusting a company to store your keys for you, you're making a huge mistake because we know that the bigger, the more successful a company gets, the more likely, in fact, it is that it will be attacked. It doesn't even matter in some sense how much security they throw at it. Because the prize, it's ultimately up to economics. The more successful they get, the bigger the payoff is for actually hacking them. And you have

more and more hackers trying to find vulnerabilities in their armor, and then you have a Mount Gux. and you don't want that situation to happen. In terms of securing your Bitcoins, the best thing to do is to do it yourself, if you can, in a secure way. And thin clients are a great way to do that. Can you tell us what's the role that Aaron Schwartz played in the OkT turtles in the beginning? Yeah, Aaron Schwartz was one of the first to recognize the significance of the blockchain and the role that it could play in naming systems.

He wrote a fantastic blog post called Squaring Zucose Triangle. And that blog post was the reason that I got interested in this entire field. That blog post was the reason that eventually DNS chain was developed. And it was because of that blog post that I got a chance to actually communicate with Aaron Schwartz. I sent him an email shortly after reading that post, asking if you needed help with it. And we exchanged a few emails, and eventually I got to see. and kind of went off, did some other things. But in 2013, in fact, that was the, at the start of that year, that was one he committed suicide

because he was being pursued by a prosecutor, coincidentally the same prosecutor who had pursued a close friend of mine, John James, who also committed suicide because of that whole process. And perhaps because of that event, I don't. know, my memory is not that good, but maybe that played a role in kind of getting me back on this track and deciding to really devote a lot of time to this cause. Cool. Well, Greg, thanks so much for coming on. I think you did a great job explaining this topic and I think it's an extremely exciting project you work on and I really hope you'll make

a lot of progress and a lot of progress towards realizing that vision. Thank you, Brian. Thank you, Sebastian. And yeah, so we will of course put links into the OkTurtals Foundation so people, if people are interested, they can check it out, they can support it or they can get in touch with you and perhaps help in some way. We can also put, I know you've given a few talks that go into more depth so we can put those in the show notes as well if people want to get a bit deeper in the technical aspects of this. Yeah, please follow OKT turtles on Twitter. Okay, we'll do that. So yeah, thanks so much for coming on, Greg. And thanks to the listeners for joining us.

So we put out new episodes of Episand Bitcoin every Monday. You can subscribe to the show in iTunes or in your favorite podcast app. And you can also watch the videos on YouTube. And yeah, so if you're loyal listener, then, you know, do us a favor and leave us an iTunes review. We would totally appreciate that. And it helps new users find the show. if you want to, you can also donate to us. And our tip address is in the show notes.

So thanks so much and we'll be back next week.