Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Mike Hearn: Lighthouse, Assurance Contracts, bitcoinj, Transaction Fees & Core Dev Team

Episode Date: June 21, 2014

Today out guest is Mike Hearn who many of you are familiar with. He’s one of the first Bitcoin users and the developer of bitcoinj, a Java library used by a number of popular Bitcoin wallets such as the Andoid wallet, Multibit and Hive. Until recently he was working at Google and is now working full-time on Bitcoin, including an interesting crowd-funding platform called Lighthouse. Episode links: Lighthouse Assurance contracts Arianna Simpson - Game Theory, Assurance Contracts, and Crowdfunding with Bitcoin Venumeris Mike Hearn talk at Coinscrum 2014 in London BitcoinJ BitcoinJ on Github This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/025

Hello, everyone. My name is Sipa Senkudu. And I'm Brian Kareemn. And welcome to Epcenter Bitcoin, the show which talks about the technologies, projects, and startups, driving decentralization and the global cryptocurrency revolution. Today's June 21st, 2014. And thanks so much for joining us on episode 25. So today, our guest is Mike Hearn, who I'm sure many of you are familiar with. He's one of the first Bitcoin users and the developer of Bitcoin J. Bitcoin J is a Bitcoin Java, so a library that's used by a number of popular Bitcoin wallet, such as the Android wallet by Andreas Shilpak, multi-bit, and hive. Until recently he was working at Google, and now he's working full-time on Bitcoin and Bitcoin projects, including the Lighthouse, which is a crowdfunding platform.

And we're really excited about having them on today to talk about Lighthouse, Bitcoin J and kind of Bitcoin development in general. So, hey, Mike. Okay. We'd also like to just briefly let you guys know about Coin Summit. Last time we kind of put in a little interview that's set up with Premier. So we want to kind of mention again that CoinSummit is coming up in July 10th and 11th. We'll be there.

So if you'll be there too or if you want to go there, you know, get your tickets. You can do that at Coinsum.it. And I'm sure it will be a great conference. So I guess let's get started. So Mike, I wanted to kind of ask you just before we get started and talk about the different topics that we've got the cover. What's taking up most of your time right now? What are you working on, say, like full time at the moment? I'm spending about half my time working on Bitcoin J and maintaining that, you know, reviewing work as being submitted, improvements, things like that.

And in particular, HD wallets. and the other half of my time is being spent on my company on Lighthouse, doing some consulting work, things like that, but mostly it's split 50-50 between general Bitcoin development, which I've always done and this new crowdfunding platform that I'm working. Well, perhaps we can start with the first topic right with this Lighthouse, which is a topic. I find the crowdfunding thing very interesting also because I'm originally an economist.

And I've for a long time, you know, I saw these crowdfunding things coming up and it didn't really make sense to me why this was such a huge deal. And I think I'm slowly kind of starting to come around that I do think this is really important. And you know, we've, we've been talking with Adam Levine often about this LTV coin. We've had Joe Dietz on last time to talk about Swarm. and I know in the Amsterdam conference you were talking about Lighthouse. Unfortunately, we both missed that talk. We read your blog posts on it and we really are excited to talk with you today about Lighthouse.

So perhaps can you give people an introduction about what Lighthouse is? Yeah, sure. So Lighthouse is a way of building assurance contracts, which are this financial construct that's been popularized by the Sites like Kickstarter. So this is where people pledge money to fund the construction or the creation of something that everyone would benefit from. And then the cost for it is estimated and people pledge, but they only end up paying if enough other people pledge to reach the goal. The original, I mean, although this has sort of been popularized recently, this idea has been around a long time. And the goal was that, you know, it should be, these are a way of funding the creation of public. goods, where a public good is defined as something that once it's been created, it costs money

to create, but once it's been created, you can't stop people from benefiting from it. You can't charge the money for benefiting from it. You know, in traditional economics, public goods are things like clean air, you know, public roads, and indeed lighthouses, which is where the project gets its name. So I talked about how Bitcoin protocols supports this back in 2012, and I gave it as an example of things we could do in future, using the features that Satoshi put into the protocol, but no one was using because we lacked good user interfaces for it. And Lighthouse is my attempt to fix that to build a good user interface for the construction of these projects. So correct me if I'm wrong. Am I correcting assuming that Lighthouse is essentially, a wallet which

implements assurance contracts as it is defined in Bitcoin? Yeah, so Lighthouse is a specialized wallet. So you can send money into it, so you can withdraw money out of it and it makes transactions on the blockchain. It's an SPV wallet.

It's a lightweight wallet that talks directly to the Bitcoin network and uses the blockchain. But it doesn't have features that you would associate with a traditional wallet like a history view so you can see your transactions or contact lists, for example. It has very base features that you would need in a wallet.

But the idea is you put money in and then the bulk of the app is dedicated to allowing you to do things with that money once you put it into the lighthouse. Okay. Now, I'm curious if these features exist in Bitcoin and they are interesting and promising in terms of what we can do and where we can take this new technology, I'm curious as to why none of the other wallets and particularly, the core wallet doesn't have these assurance contracts built in. Well, it's not clear to me that you want this to be integrated into a general purpose

wallet. It's a very specialized sort of thing. Most people aren't going to take part in this kind of contracts. And if you look at the use interface, there's actually, I'm actually in the process of redesigning the user interface at the moment. So what you see on the blog post I made is not the final UI by any means. But, you know, the bulk of the screen. is taken up with management of these contracts. The bulk of the user interface is creating them, allowing you to gather pledges, to create pledges, to revoke your pledge.

Something I didn't mention is if you pledge money and then you decide you want that money back before the contract reached its goal, then you can just take the money back. It's not a commitment that you're forced into. And all of those features, you know, they all require planning and user interface design. They require protocol design.

It's actually a large, amount of work. Even though the core Bitcoin protocol has the core feature that's needed, everything else layered on top. It takes a lot of work and wallet providers are all busy with more basic features. So perhaps before we can get into the economics applications of this, which I think is the really interesting part, can we talk very briefly about how this works on a technical level? So I read the, you know, on assurance contracts. I read Ariana Simpson's post and, you know, there's something, I think, on the Bitcoin Wiki, but perhaps you can run us through briefly about, you know, how these transactions are created.

Yeah, sure. So a red Bitcoin transaction has a slightly funny structure, right? You would imagine, if you didn't know anything about it was designed, you would imagine that a Bitcoin transaction looks a little bit like a bank transaction where it identifies an account to take money from an account. to debit money to and then, you know, the amounts of money that's being moved. That's not actually how it works internally. What actually happens is a transaction has a list of what we call inputs and outputs.

And the inputs effectively identify payments that were made to you. And the outputs identify payments you're creating to someone. So the inputs of the transaction contain the digital signatures and the proof that you can claim those payments. And then the outputs redistribute that money into. a different set of conditions, so different ownership, for example. But nothing really stops you from creating a transaction that just pays yourself. For example, you can do that, that's no problem. Now, the way Bitcoin works is if you have a transaction with, say, three inputs,

then you have three signatures, one to each input normally. And each one of those digital signatures, obviously, just like a real signature, you're signing some kind of document, right? It's not just an abstract signature floating in space, it's actually a signature that covers some document. And what you're covering is a transaction itself. So when you're signing, you sign a transaction in such a way that if that transaction were to be changed,

like for example by a network node that is relaying your transaction for you, the signature would break. Now, Satoshi, he thought ahead quite impressively, I must say. He allowed you to create signatures that only cover parts of the transaction, not the whole thing, if you want to. It's not the default behavior. If you want to, you can create a transaction which it is possible to modify, and the signature will still be valid.

So the way Lighthouse works is it creates an invalid Bitcoin transaction by itself breaks the rules of the system. It has an input that connects to some of your money and claims it with a signature, and it has an output, which is a payment to the purse of the fundraiser, person who's raising money, but the amount of money you're putting in is much less than the amount of money you're trying to send to the project creator, which isn't allowed. If that was allowed, anyone could just invent money out of thin air. So the Bitcoin network won't accept that transaction by itself.

It will be ignored. But now, if the project creator gathers these kinds of partially signed invalid transactions, what they can do is merge them together, because they've been signed in a special way. And by merging together enough of those transactions, you can effectively add enough inputs to meet the goal and eventually create a valid transaction the network will accept. So that's how it works. You submit these invalid transactions. And when the project creator has enough, he combines them together and broadcasts them onto the Bitcoin network where it becomes like a regular payment. Yeah, I mean, this is brilliant.

I wasn't even aware that it's possible to partially sign a transaction in a way. that you can then put them together, you know, to get the required output. So that's, yeah, it's very interesting and I guess very cool how you can essentially replicate something like what Kickstarter does in such an elegant way. Yeah. It's not an exact good for what Kickstarter allows because Kickstarter allows you to raise more money than your goal. And, you know, sometimes you find the projects, you know, they said, well, we'll use, we need at least

$50,000 and any more money that we raised, we will spend on doing something even more awesome, right? But with Bitcoin, you can't do that because it has to be exact. It has to be exact. If any additional money were to be put in, it would end up going to minus fees, actually, because of how the protocols designed. I was actually thinking about that. So if you, let's say, I mean, because you can't control that, right? People will send in different amounts and then let's say you wanted to have 100 Bitcoins, but now it's 107. Would that actually mean that you'll have to throw out some transactions and perhaps make your own contribution to get it to exactly 100?

It depends how you organize things. Yes, you could do that. You could, if you get pledges that don't quite line up, you could post them out and make it the difference yourself. But part of the infrastructure that Lighthouse provides or is in the process of providing is, you know, for example, I've written a server that gathers pledges and it will tell you how much money has been raised. So then, you know, the software, it won't let you accidentally pledge more than when it's allowed.

You can use Lighthouse in other ways where there's no server involved at all, completely decentralized and people are just sending files around. And in that mode, nothing stops anyone from just, you know, creating pledges that don't pack correctly and end up going under, you know, undershooting or overshooting. But you can always just arrange out of bands for people not to do that. But you say, hey, everyone, you know, please pledge, you know, one Bitcoin each or some multiple of one Bitcoin.

And, you know, don't just pick a random number and put that in, please. You know, I will like more pledges that don't follow these rules. And then, you know, you just organize with people who are interested in supporting your project. Yeah, that makes sense. So we talked about. you know, sworn, for example, last time. And their idea, I guess, is that essentially projects are selling coins, and then those coins hopefully will have a value if the project is successful.

But in your case, this is purely a donation-based funding of public goods. Is that correct? Well, I would phrase it as being a donation. The reason, like, if you look at the economics, textbooks and so on, right, The way the assurance contracts are used are the people who are expected to put money in, people who will benefit from the outcome. The classical example is the sailors who would like to see the light from the lighthouse. They all put money in.

It's not a donation exactly. They understand they will get something useful out of it. This construct is designed to resolve the deadlock that can occur when there's no way to charge a small recurring fee for something. So I wouldn't expect this use for donations exactly, but you can imagine lots of different use cases. For example, let's go back to the question of packing the pledges, right? One thing that Lighthouse could be used for, because it's just an app. There's really no setup overhead at all is, you know, you could create a project in and lighthouse, drag it to your Gmail Compose window because the way the app works, you can drag these projects and these pledges in and out of the window.

You just drop it onto an email and then send it to say 50 of your friends and you say, hey, I'm going to organize a house party, right? And there'll be beer and there'll be games and stuff. But I need at least 20 people to come for it to be worth it. And to buy all the stuff, I need at least, you know, 10 bucks each. So I need at least 20 people contribute 10 bucks. Otherwise, it won't go ahead. This is exactly the kind of, this is an assurance contract kind of thing, right?

Like everyone will benefit if the party goes ahead. And so people can just reply to your email and attach the pledge they made with the app. And then when you have enough replies, the party is organized. But you know, you probably don't want to like issue tickets and things, right? Like once it's going ahead, the people who chipped into $10, they're happy. So why bother, you know, trying to prevent other people from coming. Everyone would benefit from a party that's bigger. So this is a kind of thing where, you know, you could use this financial construct.

And maybe you wouldn't really have ever imagined doing it that way because of the limitations of existing platforms. But this doesn't really address the issue of free riders, no? Because you still have the incentive that you'd be the person not paying if there's 20 other people paying the $10. Yeah, right. I mean, it's inherent in the nature of a public good that once it's been created, there will be people who benefit from it for free. The question is, if not, if less than 20 people have chipped in, right, how much do you? care about it happening versus not happening. Maybe you don't care about this party at all,

so you don't put any money in. But maybe you would actually like to see it go ahead, but you don't want to be the sucker who pays for all of it. So in that case, you can make a pledge. And you just accept, yeah, that in some cases, you know, other people benefit and they won't have paid, right? It's inherent. It's happening in things like Kickstarter projects as well.

The same thing when you support your favorite band, you buy their album, you understand that, you know, some people will just pirates. it they will benefit for free. But you know, you buy the album because you want to support your favorite band. Now, I have a question. Can you kind of walk us through how you create an insurance contract with Lighthouse and how you would essentially make it known to others?

So you had two modes. You have the server mode and the self-hosted mode or standalone, rather. So can you kind of just walk us through? Yeah, sure. the experience of creating a contract. Yeah, sure. So it's still in flux a little bit, right? Because I'm actually redesigning the UI a little bit.

But most of it is already, is this already designed and sorted out. So as you mentioned, there's two modes. There's serverless mode and there's server-assisted mode is what I call it. And this is partly because, you know, Lighthouse, it's about a bunch of things. So one is about allowing people to make these contracts and solving that problem.

But it's also about showing people how I, how I think decentralized infrastructure can be built and, you know, demonstrating the way I prefer to build decentralized applications. And so Lighthouse is like a desktop app. You downloaded and you run it. It doesn't have any dependencies on any servers or it shouldn't do in the long run. So it's just, so it's like an HTML5 app? No, no, it's actually not.

It's just a regular desktop app that runs on Windows, Mac and Linux. Okay. And that's, you know, how it can connect directly to the P.S.P. Network and process of blockchain directly and so there's no dependency or in the ideal world, there's no dependency on anything like money. And then you have a choice. You can create a contract in the app, which allows you to do very simple things like typing a title for it, a description, saying how much money you want to raise, saying which addresses, you know, you want the money to be. pay to things like that. And then what it gives you is an icon, which you can then drag to... in serverless mode, it's actually a file.

You can drag it right out of that window into a directory, for example, or into Dropbox, or Google Drive, or to an email, or a chat window, or to, you know, some other websites that you upload the file to, a web forum, for example. Anywhere you can put a file or link to a file, this project can go. And then it's up to you.

And it's entirely up to you to get that project out there for people, you know, to help people discover that. Lighthouse by itself is not a complete replacement. Everything Kickstarter does. It only handles moving money. So it doesn't have... It's not a platform. Right. It's not a, well, it's a platform, but it's not, it's only a platform for the handling of the money.

It doesn't provide discovery, for example. It's not like a single place where everyone, where people just say, I have some money and I want to do something cool with it. But I don't know what. The idea is that people can be. build such platforms on top of Lighthouse, but the Lighthouse app itself is not such a platform. So basically, a serverless mode, you're just moving files from out, right? So someone gets hold of this file, they click a link in a web forum or whatever. They open it in the app or they drag it into the app.

It works both ways. And then they can use it like a regular wallet. They can send money from their phone or from their regular wallet, from Hive, from multi-bit, whatever. can make pledges, of course. They can take the pledges back after a while if they don't think the project is really going to make it. And once they make a pledge, again, what they get back is an icon, which they can then, you

know, again, drag it out of the app and get it back to the project creator. So this is a little bit like sort of moving documents around with office or whatever. It works. You don't need any infrastructure. You're effectively using the infrastructure that already exists. maybe it's not as convenient as you would want, especially not when the number of people taking part gets high. The advantage of this is, like, if you already have a system that is managing access, control,

and identity, and so on, then you can just reuse that. Like, you know, if there's some reason why inside a company or inside a collection of companies, you would want to have one of these contracts, then, you know, you can use your private work spaces and so on, right? There's no dependency on any other service. On the other hand, if you do want to do a larger scale crowdfunding, you know, you've made a little website or you've got to, you want to build one of these platforms like Kickstarter for Discovery.

Then Lighthouse also has a server that just sits there. And in this case, you know, you can actually basically just tell Lighthouse, you know, open up this server and show me the projects it has. You can pledge. And then when you click pledge, it just uploads directly to the service. So there's no, there's no moving the files around or dragging and dropping when used in that mode, but obviously someone has to run that server.

So if I understand correctly, then if you're on standalone mode, and so I created a cause and an insurance contract, I send that file, let's say in the example of the party, I send that file to all my friends, they have to have the lighthouse app on their computer, they open the file with the lighthouse app, they pledge money to it,

and then they have to export that file again and then send it back to me in order for the, pledges to go through? Right, because you don't have any system in place it collects files. Now, to export this file, you know, like I said, you can actually, all you have to do is drag the icon onto your Gmail reply window. That will work. So it's not a particularly complicated operation. But yes, you do have to take some explicit action to get it back to the user. Right. And then as the host, I have to get those files back into my house app. And then

all together they will construct the they will sign the transactions so actually the way it works is when you create a project you give lighthouse a directory somewhere or a folder somewhere in your computer and then it watches this folder for pledges so for example what you can also do if you don't they use email is you can create a shared directory a shared folder on google drive or slotbox exactly right and if you've got the app installed you just save the project there and then when people you know when people create a pledge, they just drop it back onto the web app, the Dropbox web page, right, in the web browser uploads, it gets synced down to your computer, and then you just, you just have Lighthouse in the background, and you can see the pledges, like, stack up, right? There's no requirement

that you do anything, just as the files appear in the shared directory, then the pledges stack up, and eventually you can claim the contract. And is there, are there any plans to make mobile apps as well as desktop? Well, I've thought about it, but my gut sense is that, You know, for the early use cases, it's a somewhat serious step to make a pledge and make a contract. So probably a desktop computer is appropriate. But if we do want to move into things like, yeah, using it to organize parties or, you know, small things like these micro contracts, right? If people do want to do that kind of thing, then a mobile app would make a lot of sense, sure. And in that case, like, it probably would be somewhat integrated with, you know, an Android wallet or something like that.

because moving files around and dragging and dropping on mobile platforms doesn't work, so you need to design the user interface in some other way. Right. And so I suppose it would then have to be built on top of the server-assisted mode. Well, yeah, probably. I mean, you can do things with mobile phones that, you know, you can't do with desktop so easily or laptops. So, you know, you could have the files be made available to the people in the room via

Wi-Fi Direct or whatever. But there's other interesting things you can do there, especially if you have physical proximity. But yeah, probably in the mobile use case, some method of sharing files and moving files around would have to be adopted. And most likely, given the way these platforms work, that would be some Apple or Google service.

So it's possible, of course, in this case, to revoke your contribution, right, by essentially double spending it before the threshold is reached. Now, I understand why this is technically, you know, that's just how it works the way this is constructed. Do you think this is a good thing or it's just a thing that, you know, is a consequence of how insurance contracts work in Bitcoin? Well, I mean, it's fundamental to the definition of an insurance contract, right? The whole point of a contract like this is that you're pledging that you will give money. That's why it's called a pledge.

But if not enough other people pledge, you don't lose that money. It's still your money. You could spend it on something else if you wanted to. Otherwise, you're just giving the guy the money. But the issue here is, right? You can take your money back even if it went over. If you, I mean, if you do it before, it reached it. Right.

So once enough pledges have been gathered that, you know, the contract is claimable. Once, you know, at that point, the guy, all the guy has to do is click the button and the money becomes his. But you can revoke your pledge before. do that sure if you don't want to take part of them so because I was thinking like here would be a possible attack scenario right so let's say I I want to fund the projects and I want to raise a thousand big points now if somebody doesn't like my project and you know I say let's say I put in a 30-day window if somebody doesn't like my project you know they could put in 500

bitcoins perhaps from different accounts you know so it would look like 200 different people and then you know maybe as it approaches 80, 90%, you start revoking payments. And you start, you know, and then the project like as a potentially... You mean like just to mess with them psychologically? Yeah, I mean, right then, you know, like, you look 25 days in. And from like maybe 80%, it goes down to 30%, you know, gradually because people, I think this would be dramatically...

Well, I mean, you know, first of all... Yeah, you know, it's in, like I said, it's inherent in your arrangement that you can say you will pay and then you actually don't. You know, Lighthouse prevents things getting jammed where people claim they will pay and then you try and collect the money and you can't collect it, right? You don't have to do any manual work to collect this money. Now, if you're in a position where someone really hates you and they just want to like just mess with you by pretending you've got the money when really you haven't,

well, firstly, that's kind of risky for them, right? Because if someone did make a big contribution at the last minute, then they can still take their money. So it's a potentially expensive attack for them. But also, like I said, Lighthouse is solving one very specific problem, and it tries to solve that problem well. But nothing stops you from having a platform on top that, you know, has ID verification or, you know, verifies that people really are different people in some ways and watches out for, you know, people engaging in abuse of some kind. You could effectively go and find some additional service on top of it, you know, in the case where that was an issue for your project, which I would hope mostly it isn't.

Could you maybe talk about some of these services that could emerge from Lighthouse? Sure. So actually, that's a good segue into my company. So I've created, I left Google and I created this company, Venuous, and the goal of this company is to fund decentralized infrastructure, which is a wider remit than just Bitcoin. Well, actually, the goal of the company is just to earn me a living when it boils down to it. And I would like to do that by building the centralized infrastructure. So one of the things that I'm developing in and around the time I have and I'm not doing these other tasks is Venumerous will be one of these platforms.

It will be a platform where I post projects and maybe I post projects on the behalf of other people, which are about upgrades to Bitcoin. So if you're interested in, if you have some Bitcoins and you're interested in investing in the Bitcoin system itself, you can go tovenoros.com. You'll be able to find, you know, projects where there are like new features for wallets, privacy upgrades, security upgrades, scalability upgrades, decentralization upgrades, you know, cool new apps, all kinds of projects you can pledge towards. And then this will be effectively how I decide what to spend my time on.

I'll look at what the market is interested in effectively. AndvenorS.com will be one of these special, crowdfunding platforms, which brings people together who have a very specific niche interest, which is the development of decentralized digital infrastructure. So basically your funding feature requests and bug reports? Yeah, so all of this got started because, you know, I've been very worried for a long time. The Bitcoin, the core Bitcoin system is radically underfunded, underdeveloped compared to where it needs to be. So a ton of work is being done in the Bitcoin space around startups.

They're developing services. This is great. But the core system itself still has, you know, glaring problems that we've known about for years. And they don't get fixed because basically the only people who are working on Bitcoin core at this point are paid by the foundation and occasional volunteers. You know, volunteers who contribute, you know, fixes here and there for small things. But the big upgrades of protocol needs are not getting done. And, you know, a part of this is obvious.

Bitcoin itself is a public good. If you upgrade the core infrastructure, if you design a new protocol, you can't really stop anyone from using that. It's not like a Bitcoin ATM or an exchange or a wallet provider where you could charge people for access to it. The core system is open to everyone. So this is a public good and way to fund public goods is assurance contracts and what better ways to fund Bitcoin development itself than with Bitcoin insurance contracts. Now that's interesting. So you say that there's obviously,

obviously there's a lot more investment and time being spent building on these other things or these services and Bitcoin 2.0, Ethereum and all this stuff. And in the end, not a whole lot of time and effort and resources being allocated or being spent on the Bitcoin protocol itself. Why do you think that is? Why do you think not more people aren't investing their time and resources in the Bitcoin protocol? Well, I think there are a bunch of reasons.

So one is obviously this money reason, right? How do you make money? How do you even pay for yourself if you're going to upgrade the Bitcoin protocol? Yeah, but I mean, there's lots of open source projects out there with lots of people contributing and not making any money. Well, you know, you'd be surprised, right? Like the big projects like the Linux kernel and so on, actually most people are paid. You know, volunteers still make up a really important role in the open source world,

of course, right? They're doing a lot of things. There are volunteers contributing to Bitcoin J as well for example. That's great. But, you know, if you scratch the surface, you'll discover that a lot of people who look superficially like their volunteers, they're actually doing the heavy lifting during work hours because their employer benefits from that software in some way, right? Sometimes they make it explicit and sometimes they don't.

Now, in the Bitcoin world, basically we solve this problem. Today, this funding issue, this public good issue actually to the Bitcoin Foundation, which is sort of another way of solving the public good problem, right? You have like a charitable foundation. Companies that want to benefit the core system, they all donate. There's kind of a social expectation that if you're a big company and you're building on top of Bitcoin, that you will take part of the Bitcoin Foundation

to help fund Gavin and Corey and Vladimir and these guys. But the problem is, you know, I mean, progress on the core protocol has slowed down for a lot of reasons. funding is one, but there's a lot of problems within the core development community as well, which are social problems. You know, my plan with Lighthouse and Ben Urius is only to tackle the funding issue. People should be able to quit their job and upgrade Bitcoin in some way and not have to work for the foundation. They should be able to do other things.

So it seems to me like the best way this would have happened, and this is kind of a theoretical point, I don't think it was possible at the time. But if, you know, Satoshi in the beginning had said, you know, from the transaction fees, part of all that transaction fees go in this kind of bounty fund and then, you know, Bitcoin holders can use a proof of stake to vote on, you know, which projects should get funding. Do you agree with that? Do you think that would, that could have been at least theoretical if the means had been

I mean, there the time. No, I don't. I mean, I think, you know, if you look at the feature that Lighthouse is built on, the sick hash any one can paddy, there were not that many uses for it outside of assurance contracts. So I think maybe he did think about this. But to say to put aside some fraction of transaction fees for some fund, you know, the obvious question then is who decides who gets the money from that fund.

And you say, well, maybe everyone can decide through proof of stake. But the issue with, with bounties and so on is, they are first come first. Bounties have been tried a lot of times in Bitcoin developments. People have often tried to incentivize development with bounties. But there are a couple of problems. One is that they often are too small. So, you know, you find people saying,

oh, I've put like, there's a bounty of $500 and I want, you know, a complete upgrade of Bitcoin to some new thing and it'll take a year. It's like, well, you're not going to get, you know, you'll get like a few hours of work out of a skilled guy for $500, right? You're not going to get like a massive upgrade. grid. So that's one problem. And the second problem is that it creates a race where the first person to, you know, technically meet the criteria of the bounty gets all the money. And anyone else who is a little slower but did a better job, it gets nothing. So this incentivizes people

to cut corners as aggressively as possible and to produce something that's, you know, really atrocious in many cases or has, you know, yes, it's a program that does what the bounty requires, but it doesn't have a user interface. It's only usable by geeks or whatever. So bounties, largely been a failure. Assurance contracts resolve this problem because, you know, you can stand up and say, I will, you know, I will solve problem X and it will cost Y amount of money. And what you can even do what I'm hopefully intending to mostly do, which is actually already create the solution, and then stand up to say, this is what it costs me, is it's what I'm going to charge, like, this is my price. And then you know what you're going to get.

There's no danger of, you know, someone nipping in early and you get a terrible product out, because you're pledging towards a very specific outcome. Now, I don't know how you could integrate that with some kind of, you know, like who even decides what fraction of the fees get sent to developers. Developers, I think it's very hard. Yeah. It seems like your approach is economically, though, a bit irrational, though, because in a sense, if you developed something, then this is a sunk cost

and you're probably not going to not want to release it. Well, right, so that's something I'm going to be exploring. Is it, how easy is it to sit on my hands and not give stuff away for free? Yeah. You know, when I came up with this idea and I decided, I thought this was a solution. I looked around for other companies with this business model and couldn't find any. I didn't spend my months looking, so maybe there are some companies out there, but it's not a common business model.

So this is an experiment just as much as Bitcoin is an experiment. Will it work? That's the question. If it doesn't, I have backup plans. Backup plans, my backup plans, you know, in other cases, I just won't do Bitcoin stuff anymore. I'll just go work on some other unrelated piece of software. But I'm hoping...

Don't do that. Well, I'm hoping I don't have to do that, but we'll see. Bitcoin is not guaranteed to be a success, and everyone involved in it must bear that in mind. Now, my plan is that on this... on my company website, which is primarily going to be this kind of, you know,

platform finding projects just like Kickstarter is that there will be an ability to pre-pledge so people can say this solves two problems people can say you know I agree to put $200 towards this $500 but no actual

money is moving there's no credit cards there's no Bitcoins there's no lighthouse out at this point it's just a promise effectively and then the idea there is this act as a hint about what people would be interested in funding right so the idea is that it's just a promise, right, people could go back on that promise, but the goal is that by just taking a few basic precautions,

collecting email addresses and things like that, should be able to get a rough feel for what people are interested in funding. And then also people have pledged in stable currencies. So, you know, if people pre-pledge to a certain project, and then I go and write that project and say, okay, it's available now, then, you know, obviously once the contract is fixed in Bitcoins, then you're kind of stuck with it until the project closes. So at that point, you would hope that, you know, you could actually get most people

who promised to actually pledge for real with real bitcoins within the space of a week or two. So you're not too affected by volatility. Now, are you the only person that's going to be working on these sort of pledged upgrades or are there other people who will be joining you to? be paid in effect for upgrading the corporate call. Well, a lot of people, like, so a lot of people have expressed interest in this funding model, a lot of people who would like to work on Bitcoin full time or they already are, but they don't really have a business model yet.

They've been talking to me and say, hey, I would love to be able to use this app. Let me know when it's ready. Now, to start with, it would just be me. I want to see if I can actually make a living this way. Obviously, if I'm successful and there's a bit of a bit of, backlog of projects, you know, more people have pre-pledged, more people are pledging money to these projects than I can actually get through myself, then it would make total sense to open this up and allow other people to be taking part in this platform as well. Like,

because there's plenty of work to do. That's not, running out of work is not an issue. The question is to what extent will the Bitcoin community step up and funded? Because the companies have the funding, they've got the profit, they've got the venture capital, and they are they need Bitcoin to work well. So my plan is to mostly try and get these companies to pledge. And this results a problem that you know, BitPay or Coinbase or, you know, whoever, none of these companies want to become the sucker who is always paying for the upgrades to Bitcoin and the other companies sort of get away Scott free, right? So it's a way of breaking the deadline between Bitcoin startups as well as individual people.

I guess there would be one issue. I mean, if say, for instance, you're the only one who ends up working on these protocol upgrades on this platform that in effect we're kind of centralizing the development of the Bitcoin protocol. Do you know what I mean? Well, you know, it's already centralized, right? Basically, only people doing any heavy. But even more centralized.

Right. Well, the only people doing any kind of heavy lifting on the protocol today are people paid by the Bitcoin Foundation. And when I say people, all I mean is Gavin because actually there's only three people paid by the foundation to work on Bitcoin code-wise. And of those, Vladimir and Corey both refused to work on the protocol, partly because of these social issues that have come up, right? Basically, progress on the Bitcoin Protocol is ground to a halt, complete halt. So this is a crisis period for Bitcoin in that sense. So if I was to be working on it and I had a sustainable income stream, this could only decentralize things further, even if it's just me, because now you've got the Bitcoin Foundation and the numerous. And especially if I'm working on things that people are pledging money towards and I'm kind of being pulled around by the market, right?

I see. This is free market-driven development. It wouldn't be like I say, this is the next project, you know, take it or leave it, right? I have lots of projects that I could do. And which things get done will depend partly on where the money is. So this is a way that the regular Bitcoin community can also influence development hours as well. I'm hoping to create a marketplace where, you know, people who can put money up can help direct things within reason. Right.

Obviously, you don't want, you don't want Bitcoin to be just controlled by rich people. There has to be some reason to it. But they can certainly help funded. I think that could also be a great way to just get more people involved in the development process. Because I guess most people, even working on Bitcoin startups, et cetera, you don't really know too well what exactly the core developers are working on. So perhaps this would be a way to change that someone. Well, I mean, what these developers are working on is open and you can just go look at GitHub or the mailing lists. The real problem we have now is that people at these startups, they're sending.

me and Gavin feedback saying they're not willing to take part because of these social problems that have accrued in the project. So that's obviously a concern. There could be people working on this stuff, but the environment has become so toxic, they're not willing to. And partly, you know, if you feel like you don't know what the core developers are doing, the brutal reality is that most of them do not much. There's almost nothing happening, actually, on Bitcoin core development. Only Gavin is working on any major. upgrades and he can only tackle one at a time. So last year, a lot of time was spent on, you know, payment protocol. I did a lot of work on that as well. A lot of time I spent on random

misc things that crop up like, you know, change forks and performance and, you know, transaction malleability stuff. But if you look at, you know, new features and other improvements, then only Gavin is doing that. So he's just one guy. So that's the problem I'm trying to help us. That is very worrying, though. I wasn't aware. is quite as bad. Yes, I'm afraid it is. I mean, if you, there's a sort of group of people who, I've never seen this in any other open source project, by the way.

This notion of a core developer is something that's unique to Bitcoin as far as I know. And I've been involved in open source projects for 15 years. So, you know, I'm not a newbie when it comes to open source. But yeah, no, it worries me too, right? But two of the three people, I've talked to them about it, two of the three people paid by the foundation, they're not willing to think about protocol upgrades at all. Is that because they're just too busy, like the bug fixes and sort of keeping things running?

Or is there another reason for that? Well, you know, there is a fair amount of work involved in just keeping sticking over. But no, I mean, the core problem is that basically any change to the protocol gets, well, any proposed change that's non-trivial, tends to devolve into giant arguments. And historically, Bitcoin has had a consensus space. development approach. So proposals be changed and reasonable people would discuss them and some consensus would arise. And in recent times that process has broken down completely, such as now even quite simple changes, can't get consensus anymore. So, and people see this and

they see these giant flame wars effectively and they say, I don't want to, you know, it's not fun to work on this stuff. I don't want to go anywhere near that. You know, I'm not interested in doing work that then gets rejected. or ignored because, you know, this ever larger group of people, they all wield veto power overchanges. So there's a structural problem there. The chain of command has become less clear and less asserted effectively. And the problem is that it makes it difficult to get things done. So that's the reason that a lot of this stuff is moving very slowly, right? Improvements that have been talked about for years, no one even starts work on them now.

And so you said Gavin is sort of the only one working on upgrades to the, the protocol. Can you talk about some, what those upgrades are? Yeah. So Gavin, last year, me and him tag teamed on the payment protocol, of course, which was rolled out. I started to roll out at the start of this year. Now he's working on floating fees, which I know you mentioned earlier. This is, you know, this is attempting to fix the problem that fees are pretty broken in Bitcoin. There's no fee market to speak of. it means that as Bitcoin gets more valuable in dollar terms, the effective fee we're paying in dollar terms per transaction goes up

for no real reason. It's not like an transaction actually got more expensive to process. It's just because of the way the software works. So he's been working for a while now trying to fix that. But, you know, like I said, he's just one guy in and progress is slow and upgrade. A lot of these things are upgrades to the entire ecosystem, right? Everyone has to opt in and upgrade to floating fees for that to work. So it's a very difficult sort of change.

So can he tell us how he's thinking about going about that? Well, so what he's been working on in recent times is changes to Bitcoin core that will it effectively watches the behavior of the network and uses data it records to estimate what fees have paid to confirm in what amount of time. So I worked on this with him over Christmas as well. We modify the algorithm. And the idea is that Bitcoin core, the wallet, you'll be able to specify, I want my transaction to confirm, you know, within one block, within 10 blocks.

I don't care if I weighed 100 blocks. And the outcome of this is that, you know, when you send a payment in Bitcoin, you'll be able to actually drag a slider from left to right, you know, from slows or fast. faster slope and the wallet apps will estimate the fees they have to pay in order to get confirmed within that time. This is the first part of like establishing a fee market where miners compete with each other on their fee policies. But as a minor you kind of have an incentive to just include you know whatever transactions pay higher fee than your you know marginal cost or your cost of including the transaction. I actually ask guys

Gavin about that because I thought like, well, you know, the cost of including transactions is basically going to be zero. And he said it wasn't the case because of a because it makes you a block bigger and then it takes longer to propagate so you have a higher risk of an orphan block. So that this would sort of define the lower bound of the fees, which seems like a very strange way of determining the fees? It's not. I mean, so a lot of the things you realize is a lot of these issues were flashed out in various forums, you know, as way back as 2010. You're correct. The establishment of a fee market should drive fees close to zero, not actually to zero,

because, you know, there is some cost associated with including a transaction. But in theory, in a healthy mining market, you know, miners should prefer to take the fees rather than leave money on the table. And this means the fees should drop to what it actually costs to include a Bitcoin transaction, ignoring without the cost of mining itself being considered, which for now is being funded by inflation. This is, this might seem useless or reckless in some way, but it's actually by design. So transaction fees in Bitcoin, it doesn't work as a way to fund mining, actually, which is how Satoshi originally. envisioned it and it doesn't work for exactly the reason you specified.

If miners are genuinely competing with each other and we don't have a cartel, then the fees should spiral downwards to the marginal cost of inclusion in the block. And so for now, we don't care because, you know, miners are getting 25 bitcoins per block anyway, and in future they'll still be getting money per block, even if they include no transactions at all. And in the long run, we need some other way of funding this. And this resulted in huge flame wars a long time ago.

I say a long time ago. It's not really a long time ago. 2010, 2011, 2011, I think is when most of these debates happened. And people came up with all kinds of interesting solutions to this problem. The most annoying of which was, you know, hey, we should just limit Bitcoin so it can hardly process any transactions. Because it's so amazing, you know, people will attach huge fees to their transaction. just because they want to use Bitcoin, and this will, this artificial throttling of supply, of block space supply, will force fees to be as high as we need to protect the system.

This was not a very convincing argument. For example, Peter Todd made this argument a lot. The problem being, of course, that, you know, we don't want a system that's kind of useless and only rich people can afford. That's not really a very inspiring thing to work on. We want a system that is accessible to everyone, including poor people. So I proposed an alternative which is, hey, guess what? Assurance contracts, right?

You can actually, you wouldn't do it with Lighthouse because Lighthouse is a GOO app that's designed for end users, but you could have a different kind of app that forms what I call network assurance contracts. And this is what are people who benefit from hash power, people who benefit from difficult to construct blockchains. They form like rapid micro assurance contracts. So they can have a peer-to-peer network where they're actually forming transactions that spend, all the money to fees and which effectively force people to chip in and help pay for mining cash power because effectively mining is a public good right because this because miners have this incentive to include every transaction no matter what the fee you can't really stop someone

from getting their transactions like yeah so this is this is not hugely well thought out because it's a problem that will occur, you know, along the way in the future we think. But at least in theory, you know, we recognize mining as a public good, maybe some kind of assurance contract contains a solution. You're still going to have the free rider problem in that case, though. Yes. Yeah, I mean, I've been thinking about that as well. And I agree, it's a very strange thing that, you know, in a sense you have the, essentially

all the Bitcoin holders are paying for the security of network through the inflation. now and that's going down and there seems to be no clear way, you know, to solve this problem with the transaction fees. I mean, I think you described it extremely well. The idea is interesting. I guess if you could sort of include this insurance contract automatically in wallet software and maybe it would be cheap enough. Yeah, sure.

So, I mean, you can imagine everything from, you know, payment processes like BitPay doing this. So, you know, everybody being integrated. into wallets and everyone's wallets, you know, taking part through some big peer-to-peer network. You can imagine lots of scenarios. That's super interesting. I've never heard about that, but yeah, that's a very interesting idea, I think. Speaking of fees, you mentioned in one of the talks, I forget which one it was, but

when speaking about the payment protocol, that the payment protocol should allow the receiver to pay the fees. Can you talk a bit more about that? Yeah, right. So, I mean, the funny thing about the way Bitcoin is to cycle, is senders pay fees, but it's a receiver who cares about double spending this. So, you know, it became obvious while we were thinking about these questions around the economics of mining and so on. And I remember actually giving presentations to management inside Google back in 2011. And, you know, these are smart guys, right? So I gave a presentation to the head of Google research.

And he immediately, like, seized on this question of how does the economics of mining work? Does it work, you know? Does it turn into a race to the bottom where there's no one is. mining because no one is paying for it. And, you know, these are very challenging questions. For example, how much mining does the blockchain really need at all? I think we're in this really terrible situation at the moment. Bitcoin has got itself into this really terrible situation

where there's huge amounts of energy being put into mining, and yet the chain is extremely insecure because of, you know, g-hash.io, because of mining pools, mining centralization. We've got this absurd scenario where people are building an entire data center farms, just to mine Bitcoins, yet we are still insecure, very insecure, right? The whole system could be overridden and people would double spend just one guy deciding it effectively at this point. You know, Jeffrey Smith at G-Hadio could double spend. But even if he didn't have the majority that he seems to have more close to it, you know,

he could team up with another guy and two guys could double spend. So right now we've got too much mining and yet somehow we're still insecure. So this question of, you know, how much money does, do the receivers of transactions want to spend in order to secure their transactions against double spending is a very complex question. Not everyone cares about double spending equally. But especially the people who don't care about double spending and the people sending people money because they know they're honest. Or they know they're malicious and they don't want to attach any fee because they want to be able to double spend. So it's always a receiver that cares about fees. And, you know, we need to fix this.

So the payment, currently we scrape on by with everyone just attaching a kind of a hard-coded fee by convention. But ultimately, what we need is receivers to be able to say through the payment protocol. I think, you know, you're a double spending risk. So I'm not going to accept this payment unless you attach a reasonably high fee. Or they could say the opposite. You know, you're a trusted value customer. I don't care if this payment takes two weeks to confirm. You know, don't attach any fee at all.

for example. And then the payment protocol is the ideal way to communicate that. I see. Okay. Well, maybe we should move on to Bitcoin J. So you developed Bitcoin J in 2011? No, I started in 2010. No.

But it wasn't released until 2011. Okay. And so Bitcoin J is this library, Java library, which allows you to create an app essentially or a program and interact with the blockchain. It's used by the Android wallet by Andreas Schilkbach. It's used by multi-bit by Hive. Now, recently it's been talked about that you want to include Tor in Bitcoin J, where all traffic essentially moving in and out of a wallet would,

Transact through Tor. Is that already implemented? Or is that in the process of being implemented? No, it's actually been merged into the master branch of Bitcoin J. So that's the version of the code that's being developed. It's not been released yet. But yes, it works. And, you know, I have an example Bitcoin wallet on my desktop that connects through Tor.

And it works fine. There are a couple of things we're going to need to do before. That's usable by everyone. One is that the tour library we use is quite new. It seems to work pretty well, but we know it has a couple of bugs. And if we know the bugs exists, it can break it, we should probably fix it. So there's a bit of maturing that needs to happen with that library that we're using for Tor. And the second one is it does slow down startup a little bit, or it can do.

And you know, not everyone cares about additional privacy or the additional security. So, you know, for example, if you're at home, it doesn't really make a whole lot of sense to use Torp because we probably trust your cable company, for example, your home Wi-Fi is private to you. So, you know, we need to figure out how to deal with that. Probably what we'll see in the next generation of that, next sort of generation of wallets built on Bitcoin J, you know, the next versions of Hyde and the mobile wallets and so on. It's like a tick box, right, in the preferences that say, do you want additional privacy and security at a trade-off that the app will take longer to start up? And then we can get feedback and testing and maybe find a few more bugs.

from the people who are, you know, willing to opt in. With the eventual goal being that maybe all traffic should be rooted this way by default, but, you know, we need to make sure it's not going to harm stability. So the idea of integrating Tor into Bitcoin J was primarily to stop man in the middle attacks, for instance, on a public Wi-Fi network, or are there other risks? Well, there are a couple of reasons. You know, one is this issue of, yeah, if your internet connection, is not trustworthy, or I should say if your internet connection is less trustworthy, if you've

even Tor, then obviously you can use Tor to upgrade. The other reason is, you know, to try and just raise the bar a bit for snooping by national governments and other people who are doing bulk intercepts on the wire. It's not completely clear to me how successful Tor can be at that when using Bitcoin because of the details of how it works. But, you know, it can't really make me easier. it can only really make them harder. So that's another reason to do it. Now, you mentioned in this talk, so the talk I was referring to earlier

was the one you did at the CoinSrum earlier this year. So you mentioned that there are some other issues with using Torr, which is that the peers that you connect to are now hidden, or at least their IP addresses are hidden. So there's a problem of trust of the peers that you're actually connecting to and sending transactions to from your wallet. And so you mentioned some possible ways of solving this.

So there's a proof of sacrifice, which is essentially miners-only trusting nodes that would sacrifice a small amount of Bitcoin, so it would make it expensive for someone to run a large amount of nodes. And also this other kind of really this thing that I had never really heard about, which is a proof of passport, which is to prove that you're in fact a real person because you have a passport. Now, can you kind of go into detail about how this would work? Because, I mean, not all passports have.

Of course, this is a proposal. I mean, I understand it's something that you propose in theory if all past, if everybody had a passport or if all passports had an if she chips in them. Can you just talk about how this would work and how you, how you, you can verify that somebody has a passport? Yeah, sure. So actually, let me just correct something you said a bit earlier. The way that we've implemented Tor in Bitcoin J currently, that's not a risk, actually, because we're not connecting to Tor hidden services.

We're connecting to Bitcoin nodes on the regular internet through Tor. So just like you would if you browsed a website through Tor. Okay, so the Bitcoin nodes themselves are not. Right. So Bitcoin nodes themselves are not hidden services. So you can still pick a collection of IP addresses, and as long as you trust that your internet connection is not being interfered with...

Well, no, let me rephrase that. Without Tor, you assume that if you connect to 10 IP addresses chosen randomly from a set of 8,000, 9,000, you probably got like 10 nodes that are not collaborating against you, right? If there's someone sitting on your internet connection and giving you a false view of the internet, then maybe that assumption is violated.

Now, you know, if you connect to hidden services with Tor, you don't even have that, you know, that issue of the IP addresses and, you know, most Bitcoin notes are not run on Tor either, so you have much smaller set, which is why we don't do it. So I'm not worried about this risk for the way we're using Bitcoin J and Tor together today. This is really future thinking. Now, the proof of passport thing is it's highly theoretical, as you say, partly because the software needed to do it. is not available. In fact, it doesn't even exist yet, right? So this is theory based on academic literature. It's not something you could implement or I could implement today.

It's just an idea of the future based on recent science. So it's still science fiction, effectively, but just quite close to not being. And yeah, so like you said, you know, there are other issues. Not everyone has a passport. Not everyone has an NFC passport. The point of this is really to solve the underlying. problem that Bitcoin is trying to solve, which is how do you obtain consensus amongst a group of people on the internet? And this is, this turns out to be really hard because online there's no

strict definition of what a person is, right? So you can sign up for multiple email accounts, you can have multiple devices, you can have multiple IP addresses, you know, there's nothing really that ties these things together. So creating fake identities is really easy. A mining is an attempt to solve that by saying one CPU, one vote. Each person has a computer with a CPU in it. Of course, we saw how badly this works. The original idea of mining was that everyone would mine, actually.

That's why it was integrated into the original Bitcoin software. You could click a button in the GUI and would mine. And proof of work has failed in that sense, because in reality what we have now is a handful of pools. And the entire system boils down to votes by like five to ten people. So Bitcoin mining is an attempt to solve this problem. So far it hasn't been working. Maybe it's fixable.

So far it wasn't working. Proof the passport takes a really direct approach. It says, you know, if you look at the details on your passport, you know, everyone has a name and birth date and some kind of other attributes that, you know, they will collide occasionally, but we can claim this as your identity and you have only one of them. And then if you could somehow digest this into some kind of anonymous cryptogrammed, credential, you would only be able to have one of them.

And then you could use it for things like voting and you could actually get 10 of these votes and know they came from 10 different people, or at least 10 different passports. And the underlying maths that makes this possible, this is a very uninsuitive concept. So when I first explained it, I got a lot of feedback saying, why do you want to make everyone reveal their passport to take part of Bitcoin? I was like, no, no, no, that's not how it works. We're talking about zero knowledge proofs. So you don't reveal your passport data.

You reveal some mathematical derivative of it that's actually a solution to a set of very complicated equations. These equations prove that you are a unique individual with some cryptographic identifier, some big number, which is your number, and you only have one of those numbers, but it's still an opaque number, right?

You can't see through that number to figure out who really owns it behind the scenes. So, you know, in theory, you wouldn't even need mining or the blockchain in some ways if you could build such a system because you could go back to this world that Satoshi wanted actually, which was one person, one vote, actually. But he lacked the technology to do it. And that's what the proof of passport idea is all about. The reason, by the way, you hadn't heard about it before is I invented it for the purpose of that talk. You mentioned some interesting research that allowed this proof of passport to exist. which was ZK snacks.

Snacks. Yeah. So some really long and complex acronym. But I just thought it was very interesting because, I mean, like you said, this unlocks the potential for other applications as well, you know, like voting or things like that. You know, not identity verification, but I mean, the proof of being one person and not being multiple people.

Now, what about in the event that you have two passports? Like if you have a dual citizenship, for instance. Yeah. Well, that's up to the designers of the system, how they handle that right. Like if you're a dual citizen, you can select. So the interesting thing about these zero knowledge proofs is you decide what data to expose the passport. So what the proof does is it proves that the passport data was valid. And then it allows you to selectively reveal some of that data or none of it or a derivative of it, like a hash of that data.

So, for example, you could say, I'm not going to include the issuing country in the output. And then it wouldn't matter if you had two passports if the names and the birth dates and other things were the same. Now, in reality, of course, names collide. Birth days collide, right? So you can get passports, which are two different people, but they have the same details inside. You can also have the photo, of course, but photos change. So none of these things are perfect, right? You've got an approximate.

Yeah, so it depends. Passport numbers are not supposed to collide, but I mean, this is a huge system, right? It's certainly not perfect, right? You get forged passports, you get fake passports. The digital signatures, theory, you're not forgeable, right? But I'm sure there are some governments that don't take care of their keys properly and so on. Now, it's not a perfect approximation of a person by any means. Some people would be able to get two or three identities.

Some people, you know, would be able to steal passports and generate a stream of identities from them. You know, if you convince people to give up your passports, other people would sell their passports, right? They wouldn't care about your weird cryptocurrency or whatever. They would just say, hey, if I could get 10 bucks and show this guy my passport and let him scan out with his phone, why would I not do that? So it's free money for me and I don't care what my identity is used for. So there are all kinds of interesting questions raised by this. And if someone were to try it, it would be an experimental side Bitcoin.

It's right, you don't know if it would work or not. It might be like mining, it might end up not working because people were just too many people would sell their vote, for example. But yeah, you're right, it allows, it's not only about voting in cryptocurrency, but you know, you could use this. For example, if you expose all of it or your name and your photo, then you can solve the problem of encrypting, of encrypted email. Like if you think about PGP, it really sucks and no one really uses it. And the main reason no one really uses it is because getting people's keys and verifying you actually got. the correct key is really, really hard. The PKI tries to solve this by, you know, having companies which verify people's identities

and issue certificates. And that's almost like a proof of passport, you know, maybe sometimes you have to submit ID verification to get your key. But it's kind of inconvenient and it relies on these trusted third parties who, you know, they can be corrupted and so on. So, you know, if you could just create your own certificate that people could trust, then, you know, you could just watch a video of me talking on your. YouTube and then go look me up in some directory of keys and you could see the key that I created

associated with my passport and you could have a very strong assurance that it really is me, right? It's not just an impersonator. So it can be solved all kinds of problems. I think, I mean, I've been thinking about this whole idea of like how do you verify somebody is a person and somebody is unique for a while and I think there is a tremendous amount of applications for that. And one that I find the most fascinating is, you know, remember something sort of similar was done, or I actually don't know to what extent it was done, but at least they announced they would do it, which was an aurora coin in Iceland where they wanted to give, you know, a certain amount of their currency to every person. Now, I think what would be really fascinating is if you did something like a global basic income that, you know, your monthly, you would give like, let's say, a

thousand of your world coins to every person in the world. And, you know, it doesn't have to be any approval by any government. It doesn't have to be legal tender anywhere. It will just establish its value in the free market. You know, some people will like it. Some people will ignore it. I think that would be extremely interesting. Yeah, sure.

I mean, a lot of what we do in computing and cryptography and so on is working around this fact that identity on the internet. So it's not ideal for what we want. You know, sometimes it's not private enough and sometimes it's too private. And if you think about even very basic things like spam filtering, you know, why does so many people use Gmail? I used to work on Gmail.

It's a great product. I'm very proud of what we accomplished. But, you know, we've got to be blunt, right? A big part of the reason that Gmail is the biggest email network on the planet is because it's got the best spam filter. And people don't want to run their own spam filters because it's so hard. And why is spam filtering hard? well because you can't really ban anyone from sending you email, right?

Because IP addresses can be sold with your botnets and all kinds of things. There's no real way of stopping someone to sending you money, send you email if they are really determined. But, you know, with such a system, in theory, if we had had this right from day one, you know, maybe anyone could have a really excellent spam filter. And people would not be centralizing around the hands of a big email networks. As Jeff Jarvis puts it, emails broken because it's sender controlled. Yeah, right. Well, email is broken because, you know, it doesn't have any real way of banning people who abuse it and it's free. So you get a lot of abuse, it's dominated by abuse.

Now, just coming back to Bitcoin J, we talked to Wendell Davis a few weeks ago about Hive. And so Hive uses Bitcoin J. So when I installed Hive, I was surprised to find out that I had to install Java in order to work and later found out that it was using Bitcoin J in the background. although the app is developed in Coco. Now, do you have any plans or are there any ways to port Bitcoin J to another language that maybe may be less resource intensive or like work better in a native platform? Well, I hope that all you have to do is press the button to install Java. Like it's a bit annoying that you have to do this, but it's actually Apple made it pretty easy.

What we're working on is bundling a stripped down version of Java into Hive. I've been looking at that. It's one of these million things on my platefront, so it makes a little bit of slow progress. The hive guys want me to do that. And then, you know, you wouldn't see this pop-up message the first time you use it. In terms of resource usage, I mean,

we haven't encountered any problems with that right. There my Bitcoin J was written to work on old Android smartphones. Back when gingerbread was the most common, and the most you're going to get there is like 16 or 32 megs of round. So by the standards of modern apps, you know, the fact the whole thing connects to the period network it down as a blockchain, it runs a wallet, all in, you know, it can actually do that in 16 megs of RAM is not that bad. We're going back to like the mid-90s the last time computers

had that much memory. So I'm not worried about that as a language. The way language design is going as a trend is that people who design new languages, by and large, they don't design native languages anymore. And the reason is that you don't get access to any good libraries if you do that. You can only use libraries written in C effectively. Apple are kind of breaking that trend a little bit with Swift because they have this big legacy of Objective C stuff and they want to like evolve that platform. But you know, like you can't easily use Objective C libraries from Python, for example, you would need a lot of complicated binding to do that. So what new languages tend to be developed on is either dot net or the JVM because that way they can try out all kinds of new

ideas and language design. But still, access to all of those great libraries because the type system is a lot more well defined. So Bitcoin J, there are people using it from LISP, from Scala, from JavaScript, from Python, even, and they're doing that through the JVM. I would love to expand it out more to cover even more languages. It's not going to be rewritten any time soon. It's a big code base by now, but we can do things like automatically transpiling into C++ and stuff like that. So I think most people should not be building one as in C++ because it's too risky but if you know people want to do that

then it would be possible cool well um i think we're kind of at the end of the show is if there people want to learn more about your projects so is you can sign up i think for your blog updates is that right yeah if you go to veneumeris.com there's an email list and there's a blog as well so if you're interested you can just sign up there it's very low i haven't even sent any emails yet So it's very low traffic. Talking about spam and things, you know, I'm not intending on sending lots of updates, but you can sign up that.

Yeah, but I guess once Lighthouse is out, or perhaps if the talk, I would love to see the talk you gave at the Amsterdam conference. So if those are out, perhaps you'll send an email. When the video is available, I will email them out. Okay, perfect. Do you have any idea of when that video is coming out? Are you waiting for a record foundation to put out?

Yes, yes. I don't know what the delay is. Okay. I think they haven't put out anything. except maybe the keynote. No, they've put on a few talks, I think. But yeah, yeah, we're still waiting for it. I want to watch it.

Now, when's Lighthouse coming out, do you have any idea of when we'll see a first beta? Well, to some extent, it's done when it's done, but I'm aiming, you know, I want to push myself to try and get some kind of beta out by the end of July. We'll see how that goes. The initial versions will almost certainly be locked down

or crippled in some way or proprietary. You know, they won't be open source, because I want to raise the money to release Lighthouse with Lighthouse. So by definition, it can't be given away, can't be given away for free. So the first version, maybe it will only be usable with projects that come from me, for example. But I'm still figuring out the exact details of how to raise the money for Lighthouse itself. And are you looking for any open source developers to join you on this project? You know, right now what's happened in recent months is a Bitcoin J has really taken off.

We've been getting a ton of new contributors, a ton of big major feature upgrades going in there. Like one guy now is working on multi-sig wallets. So, you know, you can have a third-party risk analysis provider with your multi-sig wallet. And if you want to help out, you know, right now, lighthouse is not open source, right? I will have to wait to raise the money before this. But if you want to help out on these kind of ideas, then working on Bitcoin J is a very easy and very straightforward way to do that. Okay, great.

And that's, I guess, on GitHub. You just go GitHub.com slash BitcoinJ, Bitcoin. Yeah, you can go to BitcoinJ.org, and that's our website. And yes, the code is on GitHub. And there's a mailing list. It's friendly. It's got a lot of people on it. You know, if you're looking for work, you can just ask them.

And people will give you ideas for what to do. Cool. Well, thanks so much for joining us. It was really lots of fun to talk to you. And extremely interesting to hear both about Lighthouse, about, you know, the fees and sort of the future of Bitcoin J. Bitcoin development. So thanks so much for joining us today. Thanks. It's been a pleasure. So a few things. If as we come kind of the annual show, if you want to support

Epcenter Bitcoin, you know, you can leave tips. It's episode of Bitcoin.com slash tips. You can also follow us on Twitter at Epicenter BTC. And if you like to show if you want to leave some feedback, if you feel like you can do something better, you can also leave a review on iTunes, which also helps new people find a show. And finally, every Friday I send out a newsletter. It kind of goes through the most important news and developments, some links to blog posts. So you can sign up for that at episode of Bitcoin.com slash newsletter.

So thanks so much for listening and we'll be blacked next week. See you. Bye-bye.