Electrum Wallet-Bitcoin seeds, PSBT, Multi sig, Lightning
Speakers: Thomas Voegtlin
Date: November 16, 2019
Transcript By: Stephan Livera
Category: Podcast
Media: https://stephanlivera.com/download-episode/1630/125.mp3
podcast: https://stephanlivera.com/episode/125/
Stephan Livera: Thomas, welcome to the show.
Thomas Voegtlin: Thank you for having me.
Stephan Livera: So Tom I had the pleasure of meeting you at Berlin as part of the lightning conference. And I was really keen to discuss with you and talk about Electrum because obviously it’s one of the longstanding wallets in the space. Thomas, can you give us a little bit of your background and your story on how you came into Bitcoin and how you started Electrum?
Thomas Voegtlin: Yes, sure. The first time I heard about Bitcoin was fairly early. It was at the end of 2010, and at that time I was a researcher in computer science in France. I was working for the inner Inria, it’s a research Institute. So I saw an article that was mentioning that the market cap of Bitcoin has passed $1 million. That was I think in November, 2010. And yeah, so I was immediately interested because I had actually interest in cryptocurrency. That was a quite old, so it was a topic that I was interested in and I had looked into cryptocurrency and how to create a peer to peer currency before Bitcoin. But of course before Satoshi Nakamoto nobody really had a satisfying solution. So when I thought that there was, when I saw that there was something that actually worked, I mean the million dollar cap market cap was a hint that it was actually working in real life. And so I, I was really extremely interested and so I don’t know, did the white paper and I tried to read it. And at first I could not understand what it was because I was reading, I was trying to read it with my own ideas. I mean, I had, I had my own ideas on top of, of what it should be. And so it was kind of obscuring my understanding. It took me like three days to, read these six pages and yeah. Without sleeping actually. Yeah. And, and then I really got interested. Yes.
Stephan Livera: So tell us a little bit then about how Electrum got started. As I understand Electrum started in 2011.
Thomas Voegtlin: Yeah. So during the first, I mean, after I learned about Bitcoin, I did not immediately start to write a wallet. I was just learning how it works. And so I was learning how exchanges work as well. I mean, I was buying, selling this, doing this is how you start. And then I was writing some scripts. I also learned, yeah, I was writing some short scripts because I wanted to experiment with how private keys are stored. I was actually not very happy with the Bitcoin QT wallet that was there at the time because I wanted to have a bit more control and I wanted to store my own keys differently. So then I was learning how to create transactions, what is the format of transactions. And I was using, there was a very early block Explorer called ABE. So actually this block Explorer was used as the ancestor of the first Electrum server.
Thomas Voegtlin: So, yeah, at the beginning it was not a wallet. It was just some scripts that I was writing for myself. And I, I was not publishing anything. But then, yeah, it was in the summer of 2011 there was an online wallet called mybitcoin.com. That was run anonymously and that went bankrupt. So the operator of this wallet announced to the users that 50% of the money has had been stolen. And so it created a big, it created a big crash in the Bitcoin economy because it was really very, very popular at the time. At the time, there was not so many options for, for Bitcoin users. I mean, you could run Bitcoin-QT, which is today known as Bitcoin core. Or you could use this kind of website, like mybitcoin.com and mybitcoin.com was by far the main one.
Thomas Voegtlin: Or you could also use a, maybe an exchange as a wallet, but there are exchanges even were not so popular at the time. So mybitcoin was really holding a lot of money and when they announced that they were bankrupt it created a big crash in the economy. So this is what decided me to actually publish my scripts because I mean I had all the ingredients to publish a wallet. I just had to put the pieces together. And so a few months after that I published Electrum, I mean the reasoning was that I thought it is true that it’s better to own a full node if you can run a full node. But a lot of people in the Bitcoin economy did not want to go on the full node and those people are actually economically relevant. They are a big part of the Bitcoin economy. So you, we cannot just base a Bitcoin economy on people running full nodes or we are going to divide by 100 the size of the economy. So if we want to make bit concerned for, we had to provide the same kind of user experience as a website, but without the dangers of a website. So that that was the reason why I decided to publish Electrum.
Stephan Livera: Right. And as I understand, then it’s part of it was your motivation was to help increase the availability of using Bitcoin while allowing the users to still hold their own keys. I guess was the point of Electrum at that point. At that time,
Thomas Voegtlin: Yes. Holding their own keys and also using a open source wallet.
Stephan Livera: Yes and then can you contrast the different models available as well for, for a Bitcoin wallet because you have SPV and then you have like the Electrum model. Can you just outline some of the differences there?
Thomas Voegtlin: Oh, yes, sure. Okay. I mean, there are different flavors of SPV. So I think these days we don’t hear that anymore. But the very first version of SPV was the one that is outlined actually in Satoshi Nakamoto paper. So this is SPV where you actually don’t know the full blocks. So the wallet actually don’t notice the blocks, but then it verifies, it does not keep them. So it verifies the transactions that are in the block and it parses the block. After that there was the bloom filter that appeared and the bloom filter is a method that allows the wallet to request much less data. So I think, I cannot remember if Electrum was published before or after the bloom filter. I think it was more or less the same time.
Thomas Voegtlin: So Electrum uses a different method than the bloom filter because it uses Electrum servers that actually sent to you the set of transactions that are relevant to your wallet. So during the time where bloom filters were popular I could hear some people say, I mean, some people were equating in bloom filter with SPV and implying Electrum was not SPV because Electrum was not using the same method, but that’s not correct. SPV is about verifying that the transaction is in the chain of block headers. So it’s only about the verification. It does not assume anything about the channel that you use in order to receive this transaction. So in that sense SPV is as secure on Electrum and on a Bloom filter wallet. Yeah, I mean that there was this debates some years ago, but today I think less and less people are using bloom filters.
Thomas Voegtlin: So it’s it’s much less relevant. Yeah. I mean, okay. Maybe I should have started by mentioning that someone wallets are also custodian, I don’t know if that’s part of your question, but here we are talking about a non-custodian wallets where you will have the control of your private keys. And so in that space of non-custodial wallets the question is how do you trust the information that you receive if you are not a full node, if you’re a full node, then it’s easier because you have the block and you can you can be sure that the transaction is in the block. Now, if you are not a full node you can, you can use SPV to verify that whatever transactions you received are in the blockchain. And now I should mention because of lightning that there is another issue which is the proof of completeness. Namely, do you have all the transactions that are relevant to your addresses? So in order to address this, there is a new kind of filter, a BIP 158 and 157 are the BIPs that define the this technology. So let’s call it a reverse filter.
Stephan Livera: Yeah, I was just going to say, yeah, so that also known as a neutrino or one implementation of that is known as neutrino and that’s by lightning labs. I also just wanted to give a bit of an overall comment around Electrum as a wallet. I think for me, I really like using Electrum and I like using the idea of having your own Electrum server. So that’s always what I try to encourage my listeners to do is to get your own Electrum server going. And I think that’s really the best way to do it in a way where you can interact with your own hardware wallet or if you want, you can use paper seeds and you know, you can use multisignature and so on. Can you comment a little bit, Thomas, on the user experience of Electrum? I personally like using it, although I could understand where if somebody was a bit more of a Bitcoin beginner, they might have a little bit more difficulty figuring out how to do things with Electrum.
Thomas Voegtlin: Oh, sorry, I couldn’t hear the last part. Can you repeat?
Stephan Livera: Oh, sure, yeah. So I was just saying the user experience of Electrum it might be considered more like a, like a power user interface. Would you agree with that or do you think it’s something that can be made easier for people? Or is it more like this is, this is the power user tool to use?
Thomas Voegtlin: It’s very difficult. We are trying to make it as simple as possible, but at the same time, we constantly get people who want to have new features. So my goal is really to make it simple, but so I’m trying not to have too many things displayed at the same time in the interface, but sometimes it’s not possible. There is in the end, it’s also a trade off with security because if you simplify things too much, then you might lose some security. But if you make things, if you make security complicated, then you’re losing users. So it’s a very difficult question. I cannot really, I mean I would like Electrum to be as simple as possible, but there are things that take time to at least for example, now we are going to release lightning and I’m fully aware that the user experience in lightning in the first versions will not be as simple as it could be. This is going to become easier with further iterations, but not at the beginning.
Stephan Livera: Yeah, sure. And in my view, I’ve always seen Electrum as one of those wallets, which really shows you everything that’s happening, right? It’s showing you the options around things like RBF and showing you the specific coins. And coin control. It’s different to some of the wallets that hide that away and put that away in the background under the hood, so to speak. But the other part I think that should be brought up is that Electrum as I understand it, has been generally quite quick to implement new features, new address types and so on. What’s been your view on that?
Thomas Voegtlin: Mmm, I’m not sure if we’ve been really so quick [inaudible]
Thomas Voegtlin: Yeah, it depends. I mean okay. The Python language makes it easy to develop things quickly. That’s one thing. But if you look, for example, at multisig we were not the first wallet to have multisig. It was actually Armory and so we delayed the multisig until P2SH was standardized and it actually turned out to be a good thing because the multisig that was offered by Armory has not been used anymore. Now yeah, we have been fast with SegWit actually with SegWit I think we were I don’t know, maybe one of the first wallets to have SegWit. That’s true. And when it comes to lightning, we are not at all.
Stephan Livera: Yeah in my mind, I was thinking more of SegWit but yeah, yeah.
Thomas Voegtlin: But SegWit what kind of what I mean, SegWit was not very difficult to, I mean, it was just,
Thomas Voegtlin: Compare this to lightning, it’s nothing. Yeah.
Stephan Livera: Yeah. I can imagine putting lightning into a wellet is much more of a involved task than implementing SegWit into the wallet. And I think that to me, brings up another question in my mind is setting standards, because sometimes, especially for you being one of the creators of one of the earlier wallets, it might be difficult then dealing with standards that change over the time because you might’ve come out with a certain way and then another standard comes out. And I can appreciate that that would have been difficult for you. Can you comment a little bit on how you’ve tried to face that?
Thomas Voegtlin: Oh, yeah, that’s true. One example of that is the PSBT format, the partially signed Bitcoin transaction. So we had a custom format
Thomas Voegtlin: We have had that for years long before PSBT was standardized. And so actually, not really a waiting for standard to be established is a way to go faster. Yeah. but now we have I mean, the next version of Electrum will actually support the PSBT format and since we do not want to have two formats at the same time, we decided to, remove the Electrum inhouse format for partially signed transactions that we had. So yeah, I mean
Thomas Voegtlin: In that instance it was easy because this this format is not sticky. You know, you can change it. If you happen to have an offline machine and an online machine, of course you need to upgrade both because they need to understand each other. But there is no harm in changing the format. Another example where there is harm is actually the seed format. The mnemonic seed because Electrum was also the first wallet to have 12 English word format representation of the cryptographic seed that is used to generate your private keys. And I was not happy actually with the BIP 39 format that appeared later, so we never used it in Electrum. So yeah, some, sometimes sometimes it’s it’s not a problem to upgrade, but sometimes it is.
Stephan Livera: Yeah. Gotcha. So with the, I guess while we’re talking about that PSBT and BIP39, so for PSBT, are you finding that that is mainly just, that’s the way the industry is going? Most people are starting to talk about PSBT or Coldcard for example, is natively PSBT. Was that the main reason that you decided to sort of change back to going to drive back towards going with PSBT?
Thomas Voegtlin: Yeah, actually I think I looked at the PSBT spec quite late, actually. I started to really look into it only a few weeks ago because we were implementing it. Yeah. I mean, having our own standards was not an incentive to actually use this, but it seems that this format is actually going to be the standard and it’s fairly well designed. I think the, the BIP is reasonable. There are few things that I don’t like or that I don’t understand. I don’t know. Like it seems to me quite annoying that the format is different when you save the transaction in a file or when you use it in the command line because then you cannot use the output of your command line and just move it in a file. I mean, this doesn’t seem, I mean, I don’t know exactly why this choice, but maybe I should ask the author. Yeah.
Stephan Livera: Hmm. Right. Yeah. And just for listeners is interested, check out my earlier episode with Andrew chow, episode 99, so you can get, listeners can get more info on what PSBT is there.
Thomas Voegtlin: There is also this in the PSBT format, there is this fingerprint of, I mean, you’re supposed to, to put the fingerprint of the root, but actually you don’t want to because you want to put the fingerprint of the intermediate key that you’re using in your wallet in order not to disclose the root. So yeah, I mean, maybe the standard should have allowed explicitly this instead of because currently the standard seems to impose that the thing, what you give as the fingerprint of the root is actually a root fingerprint. So it has depth zero the depth is is actually affecting the fingerprint. But if you are using a different depth, then you have to fake it. And so this, this is I don’t know, maybe, I mean, there don’t seem to be a reason for doing that actually, but, okay. These are the details. Yeah.
Stephan Livera: Okay. Gotcha. Yeah, I’m keen to discuss about BIP39 as well. So BIP39 just for listeners, that’s the one of the standards that came out and that is around generating the mnemonic and converting it into your binary seed. And then that can be later used to generate the wallet. Like using BIP 32 or other methods. So BIP 39 is used in a lot of different products like Trezor and Ledger and Coldcard. But Thomas, I understand you have some concerns about BIP39. What were your main concerns around BIP39?
Thomas Voegtlin: Oh I have many. The main one is that it doesn’t have a version number. So okay. When I started Electrum, I had a custom format that was also using 12 words and that also did not have a version number. So I was thinking that other wallets would kind of adopt the same standard, but then these guys came up with something they thought would be superior basically because it had a checksum. And the problem if you don’t have a version number is that there is no specification of how to derive. OK the way to the derive your private keys from your mnemonic seed is not part of the BIP. It’s actually specified in another set of BIPs. So BIP43, 44 and so on. And the problem is that this is not well specified because there might be an, I mean the set of derivations that are allowed is not bounded.
Thomas Voegtlin: You can add new derivations over time for a given seed. Which means that if you have a software that derives certain keys and some years later, other software might use a different standard and derive other keys. So, depending on the software that you use, I mean it doesn’t even have to be years later because even currently with the different BIP39 implementations, apparently they are not able to, to the derive the same keys. So it was especially the problem with MultiBit. So the issue is that if you have a BIP 39 seed and you enter it into a Bitcoin wallet, you have absolutely no guarantee that you will recover your money because it depends on what the wallet implements. So that means that when you save your seed, you should actually also save probably the derivation if you’re technical enough to understand what the derivation is or if you are not, you should actually write down what kind of wallet it was, the software name and the version.
Thomas Voegtlin: And this defeats the purpose of using 12 words because if you have to add technical information in addition to those 12 words, then why do you use 12 words at all? I mean, why did you did this? This representation is supposed to be for non technical users. And here they have completely destroyed this idea by imposing, I mean, they created a system where there is no guarantee that you will recover your money because there is no version number that tells you how to derive your keys. So the only way to work around this is to add technical information to your backup. It’s not safe. Lots of users don’t understand what’s going on with that. And so I think yeah, I think it’s a terrible standard.
Stephan Livera: So with that I guess now we have, and I guess to your point, it is a bit of a hack work around, but now we’ve got websites that Rodolfo Novak and Janine from Blockdigest made, which is walletsrecovery.org, and they literally tried to list out for every wallet, what is the default derivation path, you know what’s the status in terms of BIP 39 and PSBT and you’re right, it is.
Thomas Voegtlin: Yeah good luck with that!
Stephan Livera: We sort of create, it sort of re-injects that technical need for understanding on some of these potentially with something like output descriptors. Maybe that was something that somebody could just back that up. All right. So they could just back up the output descriptor that would show, okay, here’s the extended public key. Here was the derivation path and you just tell the user okay, just back this up. You don’t have to worry about what it is. Just back it up. And then later somebody who knows how to deal with it can re ingest that and then figure out, okay, here’s your BIP 39, 12 words or 24 words and your output descriptor. Okay, now here you go. Here’s your Bitcoins.
Thomas Voegtlin: Yes, sure. If you, if you, but I mean, output descriptors are at least as technical as the derivations. I mean, I think we are still not addressing the need of somebody who wants something simple.
Stephan Livera: Gotcha, yeah, that’s a fair point. And so in terms of how Electrum currently deals with seeds, as I understand in Electrum, you can generate your own seed or using the Electrum way of doing it. But if you want to ingest or import the seed, the BIP39 seed, you’ve got to go into that little it’s like an option you sort of yeah. And tick that BIP 39, I’m recovering a BIP39 seed, although arguably you might be able to say that BIP39, you could identify whether that is a BIP39 seed from a checksum and not need any kind of option there. But I suppose from your point of view
Thomas Voegtlin: No, no you cannot. I mean, okay. When BIP39 was published first actually there was collisions with the existing Electrum seeds.
Stephan Livera: Oh OK, that’s very unfortunate
Thomas Voegtlin: This is one of the things that I complained about, but yeah.
Stephan Livera: Gotcha. And so that can also cause differences or difficulties where the word lists are different as well, right? Because there’s a BIP39 word list and then there’s Electrum word lists. So then that can be difficult as well.
Thomas Voegtlin: No, no we have the same word list or at least okay. Let me, initially the Electrum 1.x Standard had a different word list and after BIP39 was published we published a new version of the Electrum seed that includes a version number. And this this new standard does not require any kind of word list. Actually, it was designed to be independent of the word list so that the word list is not part of the standard. The only thing that matters is the UTF-8 string that you have as your seed. But in practice we use the BIP 39 word list for that. When, I started that I thought we would localize the word list and have one word list per language, but it’s difficult with the Android keyboard for example. So we have stopped doing that and we only have English.
Stephan Livera: I see. So now it is using the same word list but just on a different standard if I understand you correctly.
Thomas Voegtlin: Yeah, it has a different checksum and it uses different derivation depending on the version number, the list of 12 words that you get can be decoded into a version number and this is how you, you know, how to derive your keys.
Stephan Livera: Gotcha. Yeah, I can appreciate this is difficult because there’s always competing standards coming in. There’s always something new, right.
Thomas Voegtlin: Well there’s a new one coming now. There is the aezeed of neutrino.
Stephan Livera: Yeah, that’s right. I was about to mention that because that’s another one. And I understand from the lnd lightning labs team point of view, they wanted something that would have I think the birthday. So they know this wallet was created, so they know when to scan back in the chain rather than scanning back for, you know, five years back in the chain. You just scan back to the exact point and then from then on, and I think it has a version as well.
Thomas Voegtlin: Yes. Yeah. The birthday is interesting because it all depends whether you need to, to scan or whether you index the blockchain. So in Electrum we do not need a birthday. But I’m not sure. Is the birthday encoded in the words in, in that standard or is it something that you store separately?
Stephan Livera: I think it is encoded as part of the words. I’m not an expert on that though. Yeah,
Thomas Voegtlin: No, I believe too, I had to look at that standard and I think you’re right. Yes.
Stephan Livera: Yeah. So, yeah, I guess it’s just, it’s just a difficult situation, but I guess ultimately everyone wants it to be easy for users and to sort of use the standards that everybody else is using. And I guess from my point of view, I can see a lot of, when I’m trying to help a beginner learn about Bitcoin, you know, typically they’re using a hardware wallet, right? Trezor, Ledger, Coldcard, et cetera. And they’re all using BIP39 so then it just, I guess it’s difficult for them to now then take their hardware wallet and then now I use that with Electrum, which I like as a wallet and I think it’s a good product that, you know, people should try and use. But yeah, I guess that’s that. Let’s talk a little bit around multisignature because as I understand Electrum right now is pretty much one of the main ways that if somebody wants to DIY multisig do your own, Electrum is pretty much one of the main ways to achieve that. Can you tell us a little bit about that as a feature? What can the user do with that? What are your thoughts around supporting that going forward as well?
Thomas Voegtlin: Yes, so I think it has to do with the partially signed transaction format that we had before. PSBT was a standard. So we had already a few years of experience with that. Because we had our own standards. So there are two I mean, you can do multisig. There are two ways to do multisig in Electrum. The simple way is a commercial product that we have with a company called trusted coin. So they provide two of three multisig. I mean they provide two factor authentication in a 2 of 3 multisig setup. So it’s very easy because the user experience is very similar to a simple standard wallet. You have a seed. And so the main distinction is that your seed contains two factor out of three. So it is not stored on your computer.
Thomas Voegtlin: You have to only store it on paper and your computer will have only one of the three keys. So the co-signer is this company trusted coin and they will sign issue, provide the correct Google authenticator code. So that’s the easy way to do multisig in Electrum. Now if you want to do it yourself the wallet creation wizard allows you to, to set up an arbitrary type of multisig with xPub. And so you, you just enter your xPub. I mean you enter the xPubs of your co-signers and then you are asked to share your xPub with your co-signers. So that’s yeah, it you need a medium of communication when you want to share the partially signed transaction. So we have implemented two or three of them.
Thomas Voegtlin: I mean QR codes. That’s also what we use for air gapped wallets. We have, so you can have, for example, your computer and your smartphone as a, in a 2 of 2 multi sig. And then the partially signed transaction is shown on one of the screens. The other device scans it and signs it and broadcast. So yeah, you can use your codes. You can also use a USB stick. And we also have a plugin called the co-signer pool where you can actually send your partially signed transaction encrypted via server so you encrypt it so that only your co-signer can decrypt it. And you send it to a server. The server will index it with the hash of the pub key of the co-signer so that the co-signer knows how to request it. And then the co-signer know, I mean, it gets a notification that there is a partially signed transaction for him, so he downloads it from the server and he can co-sign and broadcast. So, yeah, we installed all those ways to to send over partially signed transactions to your co-signers.
Stephan Livera: Awesome. And what are your thoughts around continued support in multisignature for Electrum? Is that something you plan to continue,
Thomas Voegtlin: Sorry, continue to what?
Stephan Livera: Continue support for multisignature. Is that something you’re interested to keep in the wallet?
Thomas Voegtlin: Yes absolutely, the only change is the format now because with PSBT, if you have a multisig now, all the co signers will have to upgrade to the next version because the format is different. But it will keep working the same.
Stephan Livera: And I think this is especially powerful because you can use your own hardware wallet with Electrum, which is difficult to do with other wallets and other pieces of software. But with Electrum, you actually can just, you know, for example, plug in your Trezor, you can use a, the PSBT format with Coldcard or ledger.
Thomas Voegtlin: Yeah. You can, you can actually use, I think Electrum was the first wallet also to offer this, the capability to use a hardware wallet in a multi-sig setup. This is because we have decoupled the wallet from the key store. So the key store is is the component that signs that holds the private keys and the multisig wallet can have I mean, typically a multi-sig, has multiple key stores and those key store can be interchanged. So the, the wallet doesn’t know if it’s a, if it’s a hardware key store or if it’s software, if it’s trezor or ledger or if it’s watching only. I mean from the point of view of the wallet, it’s not releveant that’s the separation between the wallet and the key store.
Stephan Livera: Yeah, that’s great. Has that been difficult for you around interacting with the hardware? So, as I understand if you’re using Electrum with Linux, you’ve got to configure udev rules and you just need to install a couple of different packages. But then once you’ve done that, you’re good to go. Has it been difficult for you to support and maintain support for the different hardware wallets?
Thomas Voegtlin: Oh, yes. It’s not always easy. But I have a coworker who is actually passionated by hardware wallets and he’s doing a wonderful job.
Stephan Livera: Is that Ghost43?
Thomas Voegtlin: Yeah, that’s him initially. The first hardware, what is that we supported were at Trezor and Ledger, and the plugins have been developed by the manufacturers. They no longer support them, so we have to do the support. But they actually, they provided the initial version of the plugins. So they submitted this, typically we get a pull request from the hardware manufacturer whenever they will, there is a new hardware wallet when it’s coming and we, we asked them to provide some samples of course. So that we can test the pull request.
Stephan Livera: Fantastic. Yeah, I like that. It gives an option for people who would like to go fully DIY and that way if they’ve got their own Electrum server, Electrum wallet and then the different hardware wallets, now they can actually do multisignature with that. So I’m mostly interested to talk about lightning Thomas. So obviously you recently made the announcement and you did a talk at the lightning conference. Can you give us just a bit of an overview on Electrum and lightning?
Thomas Voegtlin: Yes, sure. Where should I begin?
Stephan Livera: Yeah, well maybe start with what was it that made you want to get lightning?
Thomas Voegtlin: Oh, the whole scalability debate. When I first read the initial lightning proposal, I really thought it was brilliant. The Tadge Dryja paper that I mean, it’s the spec has changed because now we are implementing, Lighting is easier because, it doesn’t have to be so complicated, but it’s still complicated. But, okay. I mean, what really decided me is the, the whole scalability debate because I think that’s the only way for Bitcoin to really scale. And yeah, I think I think it’s absolutely fantastic. It will, I am confident it will work. So we have not finished implementing lightning. I mean, it’s already available. The announcement that I made is not about a release. It’s about the fact that we have merged this in the master branch of Electrum.
Thomas Voegtlin: So we started developing the lightning version in another branch meaning that users who download Electrum from Github do not instantly have access to this branch. So we do this because it’s not stable enough. And once something is a stable we once we feel more confident that other people can use it, we merge it into the master branch. So this is what we have done about a month ago more than a month now. Yeah and so it also means that the next major release of Electrum will have lightning. We still have a few things to, to fix before the that release so it’s not going to be tomorrow and not next week, but yeah, I mean it’s, it’s clearly getting somewhere and, and now that this branch has been merged into master, we receive feedback from users who actually use it. And I mean we received much more feedback now than when it was in a separate branch of course. So this is very useful. I think if you are listening to this and if you are an Electrum user, you want to try to help us, you should definitely try to use the lightning branch and to share with us, your, feedback.
Stephan Livera: Great. And Thomas, can you give us an overview what it looks like? So users, maybe users who are not familiar with Electrum. There are different tabs. You’ve got history, send, receive addresses, coins and Thomas, can you tell us what it looks now? Looks with lightning?
Thomas Voegtlin: Oh, it’s very similar to what it used to be. You can send and receive using the send and receive types of Electrum whether it’s on chain or lightning. The, those tabs have been generalized, so they support both on chain and lightning. And in your history you will see the the lightning transactions as well as the on chain transactions. The only new tab that you will see is a tab that has your channels and that’s what you use if you want to create a new channel. Yeah, we recently, we recently added coin control to the channel creation so you can actually use a particular coin to open your channel. But so the user interface is very similar to what it used to be. Some things have changed. Of course. For example, if you, in in your receive tab, you have to decide whether you receive on chain or on lighting, so you’re not going to generate the same type of invoice. And in the sense that the fee slider has disappeared because at that point, the what it doesn’t know is you’re sending on chain or not. So it’s going to show you the fees slider only after it knows. So when you press pay, it will show you the fee slider and as for you for the password. So these are, these are changes, a adjustment that we made so that we can handle lightning invoices and the on chain invoices in a homogeneous way.
Stephan Livera: Yeah, that’s really cool. And I like how you mentioned coin control, so you can actually take a very specific UTXO, and open the channel only with that UTXO. So I like that because there are more advanced users out there who might really appreciate that.
Thomas Voegtlin: Yeah. I mean this is a scoop. This is as of today.
Stephan Livera: That’s awesome. Yeah. Well that’s, that’s great because you know, someone might want to do, say someone wants to do a coin join and then they want to open the channel only with this UTXO, well this would be, as I understand it, I don’t think any other lightning wallet has that. So this would be a first. That’s really cool. So can we talk through a little bit around how it would work in terms of if you shut down your Electrum wallet. So in my mind, I’m thinking of the typical, if you’re running lnd or C-lightning, you might have that running on, on some box somewhere and then interact with that using a wallet application such as, you know, zap wallet or spark if you’re using c-lightning. In the case of Electrum lightning, how would that work? Is there like an underlying daemon that’s running in the background or, I guess what I’m trying to say is, imagine the user is using Electrum just on their laptop. And how would that work then with lightning?
Thomas Voegtlin: Are you referring to the issue of watching your channel? When you’re offline, that’s part of it too. Yeah, sure. Yeah. that’s so we have implemented actually a Watchtower, but it’s not really easy to use at the moment regarding, yeah. You can also use Electrum as a daemon. There is a model that allows you to do that, but that implies that your machine is actually always on, which is rarely the case for users. So I think in the long run we will have watched hours. The problem currently with the Watchtower is that we don’t have Eltoo. So it’s a future specification of lightning without eltoo running a watchtower is kind of space intensive.
Thomas Voegtlin: It requires to store a lot of data and you, you have to keep these data until the life cycle of the channel. So, so with what we have done is we have implemented a, a Watchtower that users can actually run themselves. We might start a service, a commercials Watchtower service. But at this point we, I think we will wait until eltoo is available before we do that. Nothing is really clearly decided on that end. But yeah, I mean, the general context is that when you have a lightning channel you should not be offline for too long unless somebody watches your channel. So this depends on the CSV delay that is used to, to set the channel. So a typical, yeah, it depends on the, on the implementations.
Thomas Voegtlin: But yeah, I mean so if the other party closes the channel with an old state and so they can potentially steal your coins. At least they can, they can steal part of your coins. Yeah. Maybe I should explain that in more detail. So if we have a channel and I have one and you have zero, and then at some point I sent you 0.5, so we both have 0.5 and then you go offline. I could broadcast to the previous state where I have one and then you would lose your 0.5. Right? So you can actually prevent that if you check regularly because there is a delay called the CSV delay during which you can punish me. So if I broadcast an old state and you see that before the expiration of the CSV delay, you can actually punish me by broadcasting a transaction that will attribute to you all the funds in the channel.
Thomas Voegtlin: So this is how I mean this is the, the game theory behind lightning. So for this to work you need to either be online all the time or have a Watchtower. A Watchtower is a service that does this for you. So this service checks that your channel has not been closed. And if it has been closed with an old States, then this Watchtower is going to broadcast the punishment transaction. So yeah, we have implemented the watch tower that does that, but we don’t think that we are going to provide this as a service ourselves. So the code is available is open source is actually afraid of come. So you can pretty easily set up your own Watchtower with an Electrum if if you want to do so. But okay. I’m saying pretty easily, but it still requires a bit of technical knowledge. So I hope that in a future iterations of the code, we can make this really a user friendly, but that’s not going to be for the first version of lighting.
Stephan Livera: Gotcha. and I guess one other point is, even just without the Watchtower is even without the justice transaction process as you mentioned, what about just for the point of routing? Unless it’s a Electrum if you’re you’re just like a user with a laptop and you’re not having it permanently on with the demon, then you, I guess that user is not going to be a routing user. That person is more like a, like a retail customer kind of person. And I guess that’s the other question. Yeah, I guess that’s the other question I’ve got as well.
Thomas Voegtlin: We have not really implemented routing I mean we have implemented it, but without all the necessary security checks that should go with it. So by default you will not be routing and your channels are going to be private. So it’s very similar to Eclair. It’s yeah, you have to see it as a client similar to Eclair rather than similar to lnd.
Stephan Livera: Gotcha. Yeah, that makes a lot more sense now in my mind because basically it’s, it’s not for routing. It’s not for a lightning router person. It’s for a like a retail level customer who wants to just use lightning on the lightning network as opposed to,
Thomas Voegtlin: Yeah the, pattern of usage is also, I mean, if you have a light wallet you turn it on and you turn it off, you’re not always online. Yeah.
Stephan Livera: Yup. Yeah, that’s an interesting model as well. For me, I’m, I guess I’m, I’m seeing it more like people will have their, their little node back home and they’ll remote control it. And so I’m, in my mind, I’m thinking of that model where it’s always on lightning and that node is always on and it is doing little bits of routing but different models and different uses are necessary.
Thomas Voegtlin: Well you could have that and connect your Electrum wallet to your own node and that it’s possible to just like you, mentioned earlier that you have, your own Electrum server. So that means you run a full node. Yeah. If you want to have this kind of a security, you can do that. Yeah.
Stephan Livera: That’s awesome.
Thomas Voegtlin: And then, then you don’t need a watchtower if you connect to yourself.
Stephan Livera: Yeah. That’s great. I’ve also got the question around implementation of lightning. So currently, so there’s, you know, the three main implementations of lightning and Electrum is creating its own, the Electrum team is creating its own implementation using Python. Is that going to be difficult to maintain going forward? Or is it something that you’re just committed to that and that’s you’re planning to maintain a Python implementation of lightning?
Thomas Voegtlin: I think there has to be a Python implementation of lightning. Okay. Initially when I decided to integrate lighting into Electrum, I thought we would actually use one of the existing implementations C-lighting or lnd and to run it on a remote node and to have Electrum to be a light client to those. But the security model doesn’t work like that. You would actually need to have the whatever full implementation that you, that you want, you need to have it on your own device. And then so, we started to look into the code of c-lightning and LND and to modify it in order to, to match it to our needs. But it turns out that it’s I mean it’s complicated to implement, but it’s also complicated to read, especially if you have not written it. So, and if it’s written in a language that you don’t know, so it turns out it’s probably easier to, read the BOLTs and it’s actually more motivating to read the BOLTs and to implement them. So that’s why after six months of playing with the existing implementations I decided that we should just implement it in python.
Stephan Livera: Great. and then I suppose as the standard evolves, as things come in, let’s say amp you know, multipath payments and so on, then essentially it just means you’ve got to keep pace with that and then create your own implementation of those.
Thomas Voegtlin: Yeah, sure. But I believe that the, the, the most difficult part is behind us. I mean, maybe I’m too optimistic.
Thomas Voegtlin: But yeah, I mean, AMP doesn’t seem to be too difficult. While there were a few interesting proposals during this lightning conference. So we’ll have to see also, I mean, it’s too early to know what’s, what’s going to be a standard. I’m really looking forward to, eltoo actually. Although, yeah, Al too also has been criticized because of the, of the lack of justice transaction,
Stephan Livera: No punishment, no penalty for cheating aspect which might mean maybe people will be more inclined to close channels. And I guess part of the argument is that with lightning we are taking transactions off the chain. And so theoretically we want to keep channels open longer so that we can remove more from the chain and therefore you know, scale it better in that way. So yeah, I guess there’s different arguments there, but I think on the whole we would say eltoo is obviously a positive. But I think realistically it might be some time off before we actually sometime away before we actually get eltoo. As I understand we need Schnoor. Yeah.
Thomas Voegtlin: It’s, yeah, it’s probably going to take some time, but I’m mentioning it because of the, of the Watchtower context because like I said, without eltoo the economics of a Watchtower are not very clear because it requires a lot of data. You have to, to store those justice transactions that are pre-signed by the user, but they, since they don’t know the field level, they have to pre-sign at different fee levels because they don’t know how, what the fees are going to be in the future. So, and it turns out that every time you do payment, you don’t do just one commitment transactions. You have to try many times because sometimes the payment fails, so that, ends up with a lot of of transactions. So a, I’m saying that because if we want to give this service to our users, we cannot do it for free and we have to set a price on this. And at this point, I have absolutely no idea what can be realistic, how, what will be the cost on our side and what what is the cost that users would be willing to pay. So yeah, that’s a big question.
Stephan Livera: Yeah, that’s yeah. I guess some of these I just unanswered questions we didn’t, we don’t know. And we won’t find out for some time.
Thomas Voegtlin: Well we won’t find out until we try.
Stephan Livera: Yeah. Okay. So I guess that’s lightning. I was also just keen to discuss around the Electrum servers. As I understand, there are three that I know of. So there’s ElectrumX, there is Electrum Rust Server, and then there’s Electrum Personal Server by Chris Belcher. And as I understand, EPS is a bit different because it’s more like a lightweight version where you only scan for your own extended public key. Whereas the ElectrumX and Electrum Rust servers are more like scan the entire chain. And then you’ve got your own server. Well, ideally if you run your if you run that. What are your thoughts on the different Electrum servers?
Thomas Voegtlin: Well, since Bitcoin has decided not to scale by multiplying the block size on a regular interval, I think that it will be possible in the future to index the whole block chain. I mean if you have the blockchain building an index of it is is multiplying your disk requirements by a constant factor. I mean by two or 2.5 that’s it depending on the implementation. So I don’t think it’s really a problem to index the blockchain. And I would really look forward to a Bitcoin core doing that because in that case we would not need an Electrum Server anymore. So yeah, regarding EPS Electrum personal server, it saves some space, some disc space, but it’s often misunderstood. We called because some people think that they have more privacy. What is true is that you have more privacy.
Thomas Voegtlin: Of course, if you run your own Electrum server than if you do not. If you do not, then you disclose your addresses to whoever runs the Electrum server that you’re going to use. But if you decide to use your own server there is a I mean, I think first there is no, there is no real advantage besides disk space to using Electrum personal server. I’ve never used it myself, but because I use ElectrumX. I also never tried to Electrum RS (Rust Server). I use ElectrumX because it’s written in python. So if I need to make some changes to it, then I can do them myself and submit them to the developer of ElectrumX. So yeah, what I wanted to say is that sorry EPS, I’m getting confused.
Thomas Voegtlin: EPS works by scanning the chain and it’s configured with your master public key. So this model is going to break with lightning because lightning imposes that you have to watch addresses that cannot be predicted from your master public key. Of course it’s always possible to make some changes to the software so that you can tell EPS to watch for these particular address after this particular block number. And then then it could keep working. But I don’t know if the developer of the EPS are actually going to do that. So some if you want to test Electrum with the lightning version, you, you cannot use EPS at the moment.
Stephan Livera: Gotcha. Right. So you’ll need to do ElectrumX or Electrum Rust server and this is why I’m a fan of projects such as the myNode or the nodl, which kind of package Electrum server with it as well. So myNode it has the Electrum Rust Server and nodl has ElectrumX built into it. So I like that because then when I’m recommending for a beginner, I normally try to push them down that pathway of getting their own Electrum server running and then they’ve got Electrum on their desktop or their laptops and now they’re connecting with their own server. So that’s always a model that I’m happy to try and recommend for beginners.
Thomas Voegtlin: Yeah, and you could also imagine that these boxes could at some point include the watch tower. So that because a, it’s connected. I mean, it’s supposed to be connected all the time or most of the time. And it has some, disk storage, so it could actually contain your Watchtower and that means it doesn’t have your private keys. So if somebody steals this box, then there is nothing valuable inside.
Stephan Livera: Gotcha. But I suppose at that point then you would need ideally some way of Electrum mobile having lightning as well. Right. So then that way you can connect back to your own, like while you’re out and about on your mobile that you can connect back. So wallets that support this approach right now is spark wallet with c-lightning, zap with your own lnd, Zeus with your own lnd I think blue wallet as well. They’re just a few options that you can do on the mobile while you’re out, but connecting back to your own node, which is an approach I like. Because there’s less trade offs as well. Whereas some of the like mobile node lightning, a little bit more difficult.
Thomas Voegtlin: Oh, you mean a mobile front-end to lnd on your, on your node?
Stephan Livera: Yeah, yeah, exactly. But then would a similar thing like that?
Thomas Voegtlin: Yeah. No that’s a different model. What I was talking about is a model where your mobile has your private keys. So Electrum and then the box that I mean nodl or whatever does not contain any private keys.
Stephan Livera: Yes. Yeah.
Thomas Voegtlin: So, so that’s a, it would have a Watchtower, but no private keys, right?
Stephan Livera: Yeah. So it’s a completely different model. We will we will have Electrum the lighting support is also coming to to it, to the Android version of Electrum actually.
Stephan Livera: Oh, great. Okay. Yeah, there you go. All right. So another question I had was just around this question of software that is purpose-built only for one specific thing versus software that is more of a monolith, let’s say. So in the future, it may be that people will use very specific pieces of software for specific purposes so let’s say they want a multisignature, you know, cold storage. They, maybe they would use a very specific piece of software that only does that. But then on the other hand, there is a benefit there of having everything in one piece of software that everybody knows. How are you thinking about that, that idea? And I guess what I’m trying to get at here is can does Electrum become more like a monolith in that model? Because you’ve got hardware wallets, you’ve got multisignature, you’ve got lightning, it’s kind of all in one what’s your view?
Thomas Voegtlin: There are really advantageous to integrating things because it’s easier to make them interoperate. So yeah, I mean, I see, I see what you mean.
Stephan Livera: I guess let me motivate that in another way. Like someone might think from a security point of view, Oh, I need to minimize my attack surface for my cold storage. And so I want to make sure that this software that I’m doing only does exactly the things that I want so that I’m minimizing the attack surface. But the difficulty then is obviously trying to make that work with different set ups, right? So for example, if you want it to also support hardware wallets, well now you need to have hardware while it’s a bullet. So there’s, there’s a bit of a tension there. I think that some users will face when they’re trying to think of ways to obviously improve their security.
Thomas Voegtlin: Okay. Let, let me go in your direction. Because the first Bitcoin software that came out was monolithic the software, by Satoshi Nakamoto was doing everything. I mean, it was doing the protocol, the blockchain, the wallet, everything. And now we have wallets that to not do the Bitcoin core part. So Electrum actually when I introduced it, it was introduced like that. I mean, it was one of the arguments was that we are only doing a wallet. So we are not, I mean the scope of our project is much smaller than Bitcoin core because Bitcoin core they have to deal with an incredibly difficult task, which is the consensus and the security of the blockchain. So yeah, I mean I think you’re right that when you can we use the scope of your doing of what you’re doing, then then it’s better for safety.
Thomas Voegtlin: Now. that’s also, yeah, talking briefly about hardware wallets. That’s a reason why they are not actually part of the core of Electrum, but they are plugins because then we will let other people develop those plugins. But okay. Now lightning is really a different object. My like I said before, my initial plan was to integrate with an existing implementation of lightning. And then I realized that if this implementation of lightning was running on a remote machine, then this remote machine can actually harm me. It can close my channel without my consent. It can do stuff that they don’t want. So that’s why we concluded that we had to have the lighting implementation of running on the same machine as Electrum and therefore that we wanted to build our own implementation. So, yeah, the, it’s motivated by, by some security considerations.
Stephan Livera: I’m a fan of Electrum. I like using it. But I guess I’m just asking the question just to understand a little bit more about, future direction of Electrum wallet. What way it’s going. But definitely I’m excited to see lightning in the wallet and the next version. Yeah, I suppose they’re the main questions I had. Did you have any final comments or anything else that you wanted to point out to about Electrum or anything else around Bitcoin?
Thomas Voegtlin: Oh yes, sure. Concerning the future developments. I think I want to add to that. We are just at the beginning of lightning and like you said, lightning is not something that can be considered as finished. It’s really it’s going to be huge and I think it’s going to keep us busy. So the future developments are probably going to be mostly on lightning.
Stephan Livera: That’s great. So Thomas, just make sure you let my listeners know where can they find you or follow you online.
Thomas Voegtlin: So the website is Electrum.org and the official announcements and security announcements, they are done on Twitter. So I’m I’m not very active on Twitter, but if there is something important then it’s announced there and whenever there is a new version, it’s also announced there. So the Twitter account is @ElectrumWallet.
Stephan Livera: Fantastic. I’ll include the links in the show notes and thank you again for joining me today, Thomas.
Thomas Voegtlin: Yeah, thank you, Stephan. It was a pleasure.