Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Thomas Voegtlin: Electrum, SPV Wallets and Bitcoin Aliases

Episode Date: March 9, 2015

Powering an estimated 5-10% of all Bitcoin transactions, Electrum is one of the leaders of the Bitcoin wallet space. The open-source walled was started in 2011 and played a key role in the development of the light-weight SPV wallets. Developer Thomas Voegtlin joined us for a discussion of Electrum, their recent 2.0 release and the rapidly evolving Bitcoin wallet space in general. Topics covered in this episode: The evolution of Bitcoin wallets and what motivated him to start Electrum Electrum 2.0 and its new features such as Multi-sig and hardware wallet support The security tradeoffs between using an SPV wallet versus a full node client How Bitcoin aliases could do away with Bitcoin addresses Episode links: Electrum Electrum Github Repo On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients BIP 39 BIP 37 Versum MIT paper This episode is hosted by Brian Fabian Crain and Sébastien Couture. Show notes and listening options: epicenter.tv/069

This episode of Epicenter Bitcoin is brought to you by Shapeshift.I.O. With no account or signup required, it's the easiest way to buy and sell light coin, doge coin, dark coin, and other leading cryptocurrencies. Go to shapeshift.io to instantly convert all coins and to discover the future of cryptocurrency exchanges. Hello, 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 Kutjou. And my name is Brian Fabian Crane. So we're here today with Thomas Falkland. He's actually been working in the same office as I have for a few months now.

And many of you will know him or will know his wallet, the thing he's been working on, which is Electrum. So one of the most popular Bitcoin wallets. So thanks so much for joining us today, Thomas. Thank you for having me. It's a pleasure. What's interesting is that you guys are actually just separated by a wall. Yes, we're actually like five meters apart. I am in the modern room with the white wall whereas Thomas is sitting with an old-fashioned wallpaper which also represents the kind of traditional

values that the lectum has. Well, you may put it like that. Actually, it's the Ethereum office. Yeah, so the Ethereum office where I was actually staying this weekend. I actually just got to Lille about three hours ago. I woke up about 3.30 this morning to come back to Lille from Berlin. I had been there all week and Brian and I attended the Inside Bitcoin's Berlin conference and worked and did all kinds of cool stuff while we were there. So Brian, what did you think of the conference? Yeah, I mean, I enjoyed it.

You know, as Inside Bitcoin guys always do a good job organizing it. You know, they're definitely very professional at it. That being said, one definitely noticed that, you know, this is not like Bitcoin at $1,000 or something. So in terms of attendance, you know, it was pretty dramatic, I think, how much it's gone down from last year to this year. I mean, I mean, let's let's remember last year when we came back from the Berlin conference, we were filled with such energy. Like, you know, things were happening. We were on the cusp of something huge. And this year, there's about half as many people.

there's definitely a different atmosphere. I guess you could say the diehard people that stand behind the blockchain technology were there. So there was sort of filtering out of people that perhaps were not so serious about it

back a year ago. But yeah, it was nice to see everybody. And by the way, you gave a great talk, which we recorded. We may be putting it out sometime. Yeah, well, thanks. Yeah, I mean, I guess I guess to most listeners, they will be familiar with the topic because it's basically the same thing that we did our last episode on.

But yeah, no, I mean, I think one thing this really illustrates is just how much a price is driving attention, you know, people getting involved in the community. I mean, I've been also been noting it with the meetup, we get less people, you know, it's less attendance, and it's just somehow less energy with everything. And hopefully that's going to change, you know. I mean, I hope, hopefully this year it's going to, you know, pick up again. And of course, many people sort of say that the price doesn't matter. And, you know, it's obviously not true. No, it was great to be there anyway. It was really cool to be in the Ethereum office for some late night coding sessions.

I mean, this weekend, what I was saying that, I'd get back around midnight. and I had my laptop set up with a big screen. It's just something about being in that office, it just makes you want to write code. Well, so let's get right into it then. So Electrum's been around for a couple of years, and in fact, you just released a version 2.0, which we can talk about a bit later.

So can you broadly explain what is Electrum? So Electrum is a lightweight Bitcoin client. And it's also a server, it's a client server architecture. I started to write this software in 2011 and at that time there was not so many clients around. Basically you had the choice between running a full node and a hosted wallet. And, well, multi-bit was already around, I guess, but it was also in the beginning. And so in the summer of 2011, there was this Mybitcoin.com fiasco, which was a big theft. So it was a hosted wallet that lost a lot of bitcoins from their users.

So this happened with a hosted wallet that was run by a person who was completely anonymous, which of course feels weird. And so I thought, okay, there will always be a demand for a wallet that gives you access to your coins instantly because people don't want to wait to synchronize with the network. And we have to address this demand in a way that protects the users. So this is how I decided to write this client by creating a client where the private keys never leave your computer, but that can connect to the server with the speed of a web wallet. And another aspect that was very important is that it was deterministic.

a mini-stick. So instead of having to do backups of your private keys every 10 days or so, you had a unique seed phrase that you could write on paper and this would save your wallet once and for all. So what's the idea of this kind of wallet of a light wallet that provided security in where you'd control your own private keys? Was that a new idea at the time? or isn't it mentioned in the white paper even? No, of course it's mentioned in the white paper. This SPV proof checking is mentioned in the Satushinakamoto white paper. And at that time Electrum was not the only one.

There was also already another client that is deterministic, which is the ancestor of mycelium. At that time it was called Bitcoin Spinner. spinner. So we were already having this client for smartphones called Bitcoin Spinner. And the multi-bit was also in its early stages. So Bitcoin J was already being developed. And when we talk about the seed and the HD part, I know I think isn't it BIP 32, I think the sort of standard way of doing that, but then I know some people also do it a different way. I think Armory has another system is, how does it Electrum do it?

Does it use PIP 32? Yes, it does use BIP 32, but it's not using BIP 39, which is another standard. BIP 32 is about how you derive addresses in a hierarchy. And BIP 39 is about how do you convert a seed phrase made of words, mnemonic, into the private key or the root of your hierarchy. So I have decided not to follow BIP 39. So when we talk about HD wallets, then a lot of times we'll mention, you know, we'll mention. in BIP 32. So there's actually another component to that, which is BIP 39.

So the Bip 32 is how you derive the addresses. So it's like the chains, et cetera. And the Bip 39 is actually like implementing the seed from which you derive those addresses. The seed phrase, yes. How do you take words from nature and language and you convert them into a set of addresses? And why did you do. not to use the BIP 39 implementation?

Because I had the feeling that it was reproducing the same mistake as I did with Electrum when I started Electrum. When you give this sit phrase to your users, you have an obligation to support it in the future forever. You cannot tell them, oh look, this is a new version, so we're not going to see it. support the old seeds, okay? You have to support the seats that you give to your users in the future. There's no way you're going to tell them, look, we have decided to change and we do not support the old seed phrases you have to switch, because lots of users would lose their money if you did that. So when I started Electrum, I did not include a version number in the seed,

which means that the seeds that have been distributed, we have to still support them, but some collisions are possible with BIP 39 seats already. So in the first place, it was not possible to fully support BIP 39. And in addition, BIP 39 is not including any version number either. It's just doing the same as I did before. So there's no way of tracking the evolution of BIP-3. So what you're saying is since it doesn't have a version number, if there's a new version of BIP 39 comes out later,

Wallace wouldn't have a way to differentiate one version from another. I guess they might use the checksome that they have currently in BIP 39 as a version number, but it's not in the BIP currently. Another thing that I don't like about this BIP 39 idea is that when you define a new standard, you have to have a clear idea about what the goal is, and you have to see how to achieve this goal with the standard that is as minimal as possible. BIP 39 includes the word list in the BIP. That means that in the future, if you want to support BIP39 seeds because you have given them to your users,

you will have to include this word list forever. And I will have to do the same with the old Electrum seeds because the word list was included in the standard. So that's another mistake that I will not do twice. Can you explain why? So it's a problem because... Because it's very big. I mean, it's a dictionary, and if you want to have it in many languages, you have to write these dictionaries in many languages and put it in the BIP. And it's also a problem once you start to have collisions between those languages because they have words in common. So the first arrived can use the word, and then another language that arrives later has to check what are the words that are already used by the previous ones.

Now, does this mean that the seeds that you use in your wallet would not be compatible with another wallet? No, they are not. But if another wallet wants to support the seeds used in Electrum, it's very easy because they do not need a word list. It's just 10 lines of code and they can support it much easier. The seeds that we use do not require a word list. and we can actually change the world list in the future, the old seeds will remain compatible because we only use the hash of the seed phrase.

BIP 39 also, I mean, BIP 39, the first version was not doing that, and then they decided to do this. So they also use the hash of the seed phrase, which in principle would allow them to do that. But the problem is that they did not do it for the checksome, which is not consistent. I just don't understand why they did it for the... for the seed derivation and not for the checksum.

I mean, if you decide to go for a hash of the phrase, then you should do it for both, not just for once. It doesn't make sense to me. So coming back to Electrum in a broader sense, so you just came out with version 2.0. Can you talk about some of the new features in this latest release? Oh. Which there are a lot of new features, I know.

I mean, you can look at the change log on the... Yeah. What do you want me to start? Well, which ones are the most important? Which ones are the most important to you, I guess? I think BIP-70 is very important in my view. So that's payment requests. The payment protocol, yes.

And it's something that we are going to develop further. For the moment, the management of these invoices is not very well advanced, but we are going to develop this further. I think it's very important for in terms of customer protection because without this payment request, sorry, without payment request, you have to, a merchant will give you an address. but then you can feel uncomfortable sending Bitcoins to this address because you're not sure it really belongs to them. With a payment request, they actually give you a proof that they asked you to send money to this address.

So because there is a signature in this payment request, then the signature is linked to a domain name. So in terms of consumer protection, I think it's much better. So how does feel like when, so will the election wallet, I mean, I guess most of us know the payment requests from, for example, when they pay something with bid pay, right? And bid pay, yes. Since an invoice and you see the address, you know, it's basically like a certificate authority with a website can authenticate that, well, this is from them in the same way, right? BitPay basically certifies that yes, this address comes from them. How will this feel for a user?

So if then you go to website, you try to buy something with BitPay and you click a pay with that, will you display, for example, that invoice in the Electrum wallet? Yes. Will you save those invoices for future reference? Yes. Okay. Yeah, this is what we do. I did not post screenshots on the website, but basically it's a little bit like in a Bitcoin core client.

It displays the domain name that you're paying to. It puts a green color if the signature verification has passed. And it will not let you pay if this verification has failed or if the payment request has expired. I know there are a lot of other exciting features that you have. I mean, I know one of the key ones is multi-sig. And I think Electrum is after Armory, I guess, was the first wallet that had, you know, multi-sick, not in a web way, right? Because there are a lot of web wallets that have some sort of multi-sick features like BitGo,

for example. But with Armory, you could actually, know, each has your own local wallet running a full node and you could do our multisic. I think that was the first one, if I'm correct, with their lockboxes thing. And now, I don't know, is this the second like implementation of multisic for in this way? Or can you explain a little bit maybe how this compares to other ways of doing multisic that are more a web-based? I think the very first one was just the Bitcoin core client, even though it was not in the user interface, but it was with the command line. Yeah.

Armory was the first and maybe the only one to have Multisig without pay to script hash. Correct me if I'm wrong, but I think that their lock service is using multisic even from before. for this pay to script hash system. Yeah, I believe that's true. And this allows them to put an arbitrary number of the cosigners. Electrum uses pay to script hash. And so out of the box with this new version,

we can do two of two multi-sig and two of three multi-sig. Yeah, we're going to add more in the future, guess okay now can you just talk about how that works so for instance say I have a wallet here in France and and Brian has a wallet in Berlin on his computer and we want to do multi-sig how do we set that up and how do we let the other person know that there's a transaction so that he can sign you guys have to change master public keys and unfortunately for that part we we do not have a way to do it within Electrum.

But you can transfer a master public key either with a file or with a QR code. So then can you run us through a transaction? Let's say we have funds in a multi-sac address and we want to pay something. And I have one signature. Let's say it's a two out of two.

one signature and Sebastian has one signature. Yeah. How would that then go? Would I for example initialize the payment and it shows up in his address and he has to co-sign it? Or is there some way I have to send him the incomplete or partially signed transaction? That's right. So you have multiple ways to do this. You can send him the partially signed transaction. We also have a new plugin in this new release that uses a centralized server and this server is a channel of communication for multi-seq wallets so it's called cosigner pool it's like a memory pool but for transactions that are not signed yet and so you sign your I mean you sign the transaction with your signature and then this transaction is

going to be encrypted with the public key of your cosiner and is going to go on the server with this encryption. And the cosiner is going to put it in a table indexed by not the public key of the cosiner, but a hash of this public key. So the server does not even have access to the public key of the cosina. And when the cosiner starts their wallet, they just get a pop-up that tells them, oh, you have received a partially signed transaction from the cosigner pool, please type your password to decrypted, assuming they have an encryption of their seed. And once they do

that, they see this transaction that is decrypted and they can decide to co-sign it and then to broadcast it. So at no point, you just said something that we probably lost about half the people that were watching. You said centralized server. Yeah. Now, so the, what's important to realize those is that the transaction is encrypted and the server never has access to the contents of that transaction. Yeah, we can also mention that there is a currently going effort to do the same thing in a decentralized way.

I think the author of Bitcoin Authenticator, Chris Pachia, is working on that project. But for the moment, it's not ready. Okay. So this is a plugin that is developed on top of Electrum. There's another interesting plugin that I, so for instance, if we were using the same, we were using a multi-sig wallet and from the same seed, so let's say for instance, well, in our case we're a business, we have one wallet and we want to have access to the same wallet on two computers.

and be able to sign transactions with multi-sig. One thing that might be important to share is labels of addresses. So we could send invoices and receive payments, and we want to make sure that those labels are synced across both wallets. So you also have a plugin that enables that. You asked me last week about that, and in the meantime, it has been fixed. I saw that. You saw that? Okay, that's fine.

I'm looking at the chains released right now. So yeah, I just realized that. So if you have two cosina that have this labels plugin, their labels will synchronize. That's great. So I guess in that case, then, that solves the issue of, well, what a lot of web wallets solve as a problem, which is synchronizing of labels. But we can, so Electrum can do that on the desktop. Yeah. So we'll come back to Electrum in just a minute.

We want to talk about SPV as well as the Bitcoin alias initiative that Tuma is standing behind. And also just sort of talk about the wallet space in general. But before we do that, we'd like to talk about our good friends over at Shafshift. Shapeshift is the fast and easy way to buy and sell alt coins. I just checked their website and they now support 25 alt coins, including Unoptanium. So if you thought that you couldn't get your hands on some unobtainium, you can even get unantanium with ShapeShift. So ShapeShift is basically a currency converter. I consider it to be sort of Google translated for cryptocurrencies.

On one side, you have the currency you want to convert. On the other side, you have the currency you want to convert to. And you just send the, so for instance, you send Bitcoin and you want a dogecoin. you put your Doidscrow and address in their conversion tool and it'll send those going to your wallet. Zero transactions takes about 30 seconds to do and they don't even need an account. So you can do it completely transparently protecting your privacy without having to create an account.

So one thing that we've been doing recently is tipping interesting things that are related to the show. and well perhaps we could use ShapeShift to tip Electrum. Tomah, is there a tipping address? No, there is no tipping address for Electrum itself. Oh, that's too bad. I think we could probably tip one of the servers, though. Yeah, this is what I answer to people when they ask me

if they can donate to Electrum. They can donate to the people who are operating Electrum servers. Okay, so in that case, then, let's do that. So where do we find the server address? Well, I found one. You found one? I went on my Electrum wallet and I looked at one of the tips here. So there's a server over in California and we'll use ShapeShift the tip in Dogecoin.

So if I go to Shapeshift.io, so here I've got my currency conversion tool and once I've got BTC and on the other side I've got Lightcoin. So I'm going to send Dogecoin and I send that to Bitcoin, put the address in, I hit start. and using my doge coin wallet, I will simply send some doge coin over to that address. So we'll say $1. There you go. So I've just sent $1 to that address, and in just a few seconds,

they'll get Bitcoin in their tipping pool. So ShapeShift.I.O. Give it a try. Tell us what you think. Which server was that? I think it's the Electrum. H-Smiths.com in California.

Okay. So yeah, go to shape,shift.io, give it a try, tell us what you think, and we'd like to thank them for those support of Epicenter Bitcoin. Absolutely. So let's dive into the SPV topic a bit, because it's an interesting topic. It's also kind of a complicated topic, and maybe it also gives us a chance to come back a bit about the thing,

Sebastian I just raised before, the issue of Electrum using a server, and what kind of the tradeoffs are there? of using a server or not. So we mentioned a little bit before, you mentioned that the sort of idea, right, that people don't want to sync the whole blockchain. It's a pain.

I mean, personally, I've used Aramory, and it's just, it's really kind of a nightmare, I find it, because having the Bitcoin blockchain updated, you know, it's a pain when you have to wait hours each time you use it. So perhaps to get started with the SPV thing, can he tell us what are the kind of compromises and security trade-offs one makes when one chooses to use an SPV wallet versus using running a full node client like

Army or maybe the Bitcoin QT? So with an SPV client, your client can't change. check that the transactions it receives from the network are actually in the Bitcoin blockchain. But it is not a proof that you received all the information. It's a proof of correctness, but not the proof of completeness. So this is one of the trade-offs that you are making. So what's the worst thing that could happen because you don't have a, you don't have that proof of completeness? Nothing really bad, actually, but still, you could think that if you are in a non-secure environment and someone is controlling your connection, they can make you believe that you are talking to the Bitcoin network, but you are not.

And they can hide some transactions that actually landed in your wallet. So the worst thing that would happen would be that your wallet gives you incorrect balances? Yes, but they cannot make you believe that you have received some Bitcoins, which is the, because SPV protects you against that. they could make you believe that you failed to send some bitcoins. And actually being a deterministic client also protects you against that, because if you want to, if the network tells you that a transaction did not go through, and you try to send it again, you're going to send exactly the same transactions with the same coins.

So, yeah, so it wouldn't be that somebody tries to get you to pay an invoice. and you use an SPV wallet and then they, I guess, control your network. And somehow they make you believe you didn't pay and then you pay twice with some other inputs. But that couldn't happen there. Well, you would pay twice with the same inputs. So you would pay your new ones. Yeah. Okay. So that's interesting, no, because we often have this idea.

I mean, there is this idea that SPV wallets are somehow insecure or at least somewhat insecure. but that's, I mean, those seem like fairly minor things. Plus they, I mean, it also seems that an attacker would need a lot of skill and control your network. I mean, these are pretty... An attacker can also make you believe that you have not been paid. Yeah. They cannot make you believe that you have been paid. And that's important if you're a merchant because you are going to send some goods.

But they can make you believe that. you have not been paid. Yeah, so but still I mean I'm trying to think of some scenario where this would be like some some terrible situation and maybe someone can come up with one but it's it's it's a very good protection actually but if we can do better we have to do better and one of the things that I want to do for for Electrum is to add also this other proof this proof of completeness to the electron protocol.

So there is this idea that was mentioned some time ago in the Bitcoin Forum. It is called blockchain commitments. And it requires the miners to put in every block the root hash of a tree, a tree of all the unspens. So this is probably never going to happen because it would be a hard work and it would be complicated. And the miners, yeah, well, so there would be another way to do this without requiring the miners' collaboration. It's been described in a paper that was published last year. It's called Versum, V-E-R-S-U-M.

It's an MIT paper. And so this is a protocol that allows you to connect to a bunch of servers. And actually, you need only one of them to be honest, and you can't find which one is honest, just because the server is going to send you a proof. And so you request a proof of your balance for each block, and you can go from one block to the next one. check the transition between blocks. So you can do, I mean if you need to know, if you have

this proof for a block in the past and you want to have it for a block in the future, you can do a dichotomy very quickly and find out if two servers disagree which one is the liar. So this is something that we want to add to Electrum in the future. Cool. So one of the things we also mentioned was that Electrum uses a server, right? So with normal SBV wallets, they just talk to the Bitcoin network, Electrum wallets talk to Electrum servers and you operate one of them and there are other people operating one of them. Why did you choose to go that way and not just talk to the Bitcoin network? Because it allows to have a synchronization that is almost instant.

Okay. And the trade-off, I guess, is that you do lose. some privacy or is that is that true it depends you do expose your wallet addresses to the server that you are talking to in that sense you lose some privacy now if you look at the other technique that is around with which is the Bloom filter the Bloom filter also leaks some information actually you have to to to if you want speed or privacy, but you can't have both. And so you can make your Bloom filter more or less specific. And if it's very specific, it's very fast,

but then it's also going to leak some information about your addresses. But in this case, you're leaking this information to the entire world, not just to a single server, because the communication is not encrypted. So what is a Bloom? a bloom filter? Can you explain that briefly? A bloom filter is a reduced vector that does not reveal your addresses, but it tells the node that you are talking to what is the set of addresses that you might be interested in. So there might be some false positives in the answer that you get because the node actually doesn't know your addresses.

They just run this bloom filter against each block, and they can filter the block, and a few transactions will be remaining. These are the transactions that you might be interested in. So if you synchronize with the blockchain using a bloom filter, you do not download the full blocks, but a very, very reduced version of the blocks. And so when you query the network about these transactions, the node will return back more transactions.

Is that understanding right? The node will return more transactions than you need. And so therefore it doesn't know exactly what your addresses are. Or am I completely getting there on? That's the idea. Then it depends how the bloom feels. is set. It can be very, very specific or not specific at all. If it's not specific at all, basically you're downloading the full blog. And if it's very specific, then you're much less private.

Okay. And so how does that relate to how differently your implementation of SPV is from, say, a BitcoinJ based wallet? It makes no difference for SPV. SPV is about the verification of the information that you get. Electrum and BitcoinJ have a different way of querying your history, but then SPV is the same. SPV doesn't care if you use a server or not. Okay, so that's clear. But I guess one question comes up here, especially if one is very concerned about privacy. and if you sort of take, you know, put on the NSA hat, like, assuming the NSA is trying to get, for example, some sort of surveillance of what's going on with a blockchain, where would one be more secure here?

I mean, I guess one thing they could do is would be operate directly on an electrician server. The other thing they could do would be maybe operate some Bitcoin nodes or try to get some visibility into the transactions that are going on. and maybe which IP addresses are doing certain transactions that way. Where would you be more comfortable here? And how do you see those risks there? Well, if you really want to be anonymous, I think it's better to roll a full node. If you want to use Electrum, you can also use your own private server

and then you have a full node and you're anonymous. Or you have to trust the server that you are using, that they are not going to leak information about you. Now, my target is not really people who are already using full nodes and who wants to be very anonymous. I am more interested in two users that currently use web wallets like blockchain.info. And this kind of wallet does not do SPV and they use JavaScript. So this is the kind of people that I am targeting. But if you are highly concerned about your privacy, there are two ways you can use Electrum. You can run your own server and talk only to that server.

Or you can decide that you trust one of them and stick to this one. but yeah that's all. Like I said, if you're really concerned about privacy, it's better to use a full node because neither Electrum nor the Bloom filter will really make you very private. Yeah, okay, no, so that makes sense, right? Because of course, when you receive the transactions,

but then still the question is when you run a full node, run a full note, I mean, it makes sense to me that, you know, the receiving the transactions would work, you know, if you get all the transactions in, obviously nobody would know anything about you based on you looking for specific transactions to specific addresses. But then when you send the transactions, wouldn't you still leak information when you run a full note? You can use Electrum over 2. and you don't leak your IP.

So the information that you are leaking is only your addresses and you are disclosing it only to one person, which is the server, the person who is operating this server. You're not leaking it to the entire world because the connection between you and this server is authenticated and is encrypted. This authentication is also a good protection in case of a man in the middle attack, by the only.

the middle attack by the way yeah I mean in this case I meant to the if you're running a full node actually that then if you send a transaction well I mean you must send it to some node right so that node will will know you're sending a transaction right so you will leak information about your addresses in that way no if you're running a full node you just know you don't really leak information about your addresses only if people around you can tell that you the very first one to relay that transaction yeah yeah but this is difficult yeah okay yeah because it could always be that that transaction that signed transaction you're sending on to some other note the other node doesn't know whether it originated

from you or where they came from somewhere else right they can they can try to measure this, but I don't know how reliable that is. If you look at blockchain.info, they actually have a map where you can see where the transaction originates from, and it's not reliable to. So, Thomas, recently you gave a talk at the meetup in Berlin about an idea that has been on the mind of many people for many years. I think it's sort of an obvious idea, which is to make sending the... Bitcoin's really easily and to allow people to send

Bitcoins to email addresses or to some sort of a human readable format. Of course some people have done that right like Circle and Coinbase and stuff but you know it's in a very lousy centralized way where essentially you're sending you know I can send bitcoins to some email address and they get a notification essentially to create a Coinbase account for example and of course that's not really what we want because it centralization it doesn't really work and way Bitcoin is supposed to work.

But your proposal is trying to accomplish that. So can you talk a bit about how this is supposed to happen? Yes. Well, in the current Electrum 2.0, we have an open alias plugin that lets users send bitcoins to an alias that reads like an email address. Now, what I want to do is something a little bit different. I would like to have a user experience where you do not see a Bitcoin address at all. And for that, I think that the payment protocol has to be extended.

Currently, the payment protocol is very nice, but if you want to sign a payment request, you need the SSL certificate. So the payment request is signed by domain name. What I would like to have is a payment request that can be signed by a user at domain name. So this signature would not be a signature that is coming from the private key of SSL certificate, but a Bitcoin, a CDSA signature. So I think in order to do that, we need to extend this payment protocol just to have a final step where the person who has the certificate for a domain would issue, let's call it new certificates,

but for Bitcoin users, so that each user can sign a payment request with a their wallet address, dedicated key in the wallet would do that. So we were talking about the payment request at here. Would this also allow me to for example send Bitcoins, let's say to Sebastian, if I, you know, I don't know any Bitcoin address from him and I know maybe he uses Bitcoin. Could I just send one, send some bitcoins to his email address? No, he could send the payment request to your email address. Okay, yeah.

You would pay. But the requester has to initiate the process. Okay. So I was curious if there's any other projects or anybody else trying to attempting to do this. So there's like one name.org and keybase that sort of trying to remove the Bitcoin address. Yeah, yeah, there is a lot of projects around there. But I do like the idea of this payment protocol because it feels more safer to send to send Bitcoins only when someone requests them from you.

Now, is there a way, so this is a way for someone to initiate a payment request and then someone to send the money. So it is receiver controlled, which is ideal in some cases. In other cases, it may be ideal for the payment to be sender controlled. So like Brian was mentioning, I want to send money to this person. I know they use Bitcoin. Maybe they've set up something that allows me to send them money using the domain name. Well, this would be working with the current Open Alias plugin. we can

we already have that in electron so in that case it's a different process because the verification of the earliest is not using SSL certificates at all it's using DNS and DNS sec but in terms of user experience it's what you are describing

you you do not request payment but you want to send Bitcoins to someone and you suspect that they have a notorious somewhere. Now, so I've been reading about open alias and I actually, I set it up on our, on our domain name. It's pretty easy. I just had to set up a text, DNS record. Do you know if that could also work with XPUBS so that any time I put, so for example,

I want to send money to this domain name, they would generate, it would find sort of the last address that where a payment has not been sent. No, I don't know. I'm sorry. No, but so, yeah, I also think this is sort of needed because we really need to get rid of these addresses. But there seems to be a lot of challenges with this because, I mean, like, would this still work if you changed,

if you had like a new wallet or if you changed wallet or if you changed wallet providers or perhaps started a new seed, like you'd have to set that up again, even what you're describing? Yes, you would have to revoke a certificate or buy a new one. Today's magic word is seed, S-E-E-D. Head over to let's talkbidcom to sign in,

enter the magic word, and claim you're part of the listener reward. So moving on just before we wrap up, we'd like to end on sort of a, Exploring the wallet space. What are your thoughts on the current sort of offering of Bitcoin wallets out there right now? So last year there's been like a proliferation of wallets coming out. It seems like a lot of people are focusing on this.

Why do you think that is? I started this because I found it was interesting. And I think lots of people, when they discover Bitcoin, they want to play with it. So it's very natural to tinker with addresses and to why not then to start to write a wallet. It's yeah, it's there might be more and more in the future. So do you also think, I know this ties into Sebastian's question, that the wallet will be, will be key to building the sort of Bitcoin, I don't know, businesses of the future. I know there's certainly the viewpoint that I guess because, you know, in a sense,

it's like it's a central point, right, where people control their funds and maybe where you'd use other services from. And if you look at the big fundraising runs in last year, right, there was coin risk, Zappos, blockchain, Bitcoin. So many of these companies are all focusing on wallets. So is that also your point of view that the wallet, because of that central position, will be sort of essential to building significant businesses in this space? I do not know.

I believe that there is some monetization possibilities, but it's also a very competitive domain. Now, I guess there will be two kinds of wallets. I mean, wallets that also provide financial services that let you exchange actually buy by Bitcoins with euros. And there will be wallets like software wallet that actually manage your keys. And this is what desktop applications are doing. But I don't know if these two different worlds are going to mix and if we are going to see some hybrid products.

So in your case, what are some of the monetization opportunities that you perhaps see in the future of Electrum? In the present, we have started to provide these two-factor authentication service, which is a collaboration between Electrum and a company called TrustedCoin.com. And it's a unique way to do two-factor authentication because it's fully deterministic. So that means that you can recover your funds from your seed even in the event where this company, TrustedCoin, disappears. because it's a two-of-three wallet. You have two keys.

They have the third key. So that already gives you the control over your coins. But it's important to understand that the third key, the public key, is also deterministic and you can regenerate it on your side without them. So if you have a whole bunch of addresses in this wallet, it can be restored like a normal electron wallet. without this company without their servers. So you are perfectly safe if you use trusted coin.

So and then is there a model that with each transaction you pay, for example, a small fee to a trusted coin or is it a... Yeah. Okay. You can choose either you pay on each transaction or you can buy some prepaid transaction and then it's 50% less. Yeah, I think that's an interesting thing. I remember that's a long,

long, long time ago when we had Johann Barbie of 37 coins on. And they had sort of a similar model where, you know, they would essentially provide a second factor and they would sign transactions. And in this way, in this way, it provides like advantages of both worlds. On the one hand, you don't hold people's funds. So they still control them. you only have one key you can't steal them but at the same time you're like essential in every transaction so it can offer a good business model possible you know because uh you can sort of by default

include a fee to yourself um and yeah i think that that sounds like a very reasonable way or but if we think you know long term where do you see a lecture in uh in three years or in five years uh in five years oh my god i know i know No, this is a crazy question in Bitcoin terms, but maybe as far as you can see, let's say three years. Okay, I think that this idea of using email-like aliases to send payment requests will be implemented in the coming year. The other thing that will be important for us is to be more present on the Android platform. For the moment we do have an Android version of Electron, but it's not very user-friendly because it's using a deprecated API from Google.

We have currently under development a new Android application that is using in a Android application. is using Kiwi, which is an Android development framework, which is much better. So yeah, I don't know how much time it's going to take, but maybe one year for those two things. And then there is this proof of completeness which requires a change in the protocol. This is probably going to take a bit more time. It depends how I set my priorities. For the moment, my priority will be this aliases. And what about Electrum as a company?

Do you anticipate hiring people and building this into a larger project or do you hope to just monetize the open source software in a way that you can support yourself and keep working on providing sort of great open source free because software? Yes, for the moment it's an experiment. I'm going to see how much revenue I can generate. And of course, if I can pay more than one person, then I will hire someone. It's we need actually someone to be full-time on this Android development. Okay, cool. Now in terms of business model, we do have this product that is out now. I think it's time to look for other kind of services that we can provide. And there is a lot of things that we can do inside a wallet. But one thing that I did not mention is this idea of auditing Bitcoin exchanges in order to check

that they actually have your funds in their reserves. This is something that could be done by software. And this is a service for which we are looking to find some collaboration with Bitcoin exchanges. cool excellent well thanks so much for coming on today Thomas yeah thank you for thank you for having me yeah so if you want to learn more about the lectum the domain is electrum.org of course we will have to link in the show notes also I guess we can link to the GitHub page so if people you know I don't know when I look at

the code or maybe get involved even in contributing to the projects you know they'll be able to do that as well is there something else or some other place you want to appoint people to? Yeah, they can also contribute to the documentation. Actually, now that we have released 2.0 in the next month, our main effort will be to write documentation because we have a lot of new features and they are not properly documented. I can write some documentation, but it's much better if it's written by someone else who does not have the view of a developer.

So I can write like a first version of this documentation and then I hope some people will rephrase what I write in a better way. Okay, well fantastic. So yeah, thanks so much for coming on, Thomas and to a listener, thanks very much for listening. We will, so you can do a few things to support us. You can follow us on Twitter at Epicenter BTC and you can also donate to us. We do appreciate that and you can do that episode of Bitcoin.com slash tips. So thanks so much for listening and we look forward to being back next week.