Ledger’s New Bitcoin App- PSBT, Taproot, Descriptors, Multi-Sig
Speakers: Salvatore Ingala
Date: January 11, 2022
Transcript By: Stephan Livera
Media: https://www.youtube.com/watch?v=pi64CNFu8h4
podcast: https://stephanlivera.com/episode/337/
Stephan Livera:
Salvatore, welcome to the show.
Salvatore Ingala:
Thank you, Stephan. I learned a lot from your past shows, so I hope I can bring contributions as well.
Stephan Livera:
Fantastic. Well, Salvatore, for people who don’t know you, can you tell us a little bit about yourself and what you’re doing and where you’re working?
Salvatore Ingala:
Yeah. So I have a background from academia. I did a PhD in algorithms before switching my attention to cryptocurrencies. And yeah, I joined Ledger about one year ago now. And I’ve been lucky to work almost exclusively on Bitcoin-related work. The first project that I started working on when I joined Ledger—because it was clear, if I wanted to work on Bitcoin—was to implement PSBT support in the app at the time. I didn’t even know what PSBT was, but it was Bitcoin, so I was like, Okay, perfect. I’ll take it. And so I started learning about PSBT, what it is, why it relates to multisignature, and so on. And so after studying a bit the matter of the issue, the scope of the project got a bit bigger because I figured that to have a proper integration with the app, rather than just incrementally adding new features, it would’ve been better to start from scratch and try to get a new app. And that’s how we started this project. That was quite long. Like, the scope for developing this was a bit expanding when you estimate the time. Always, you tend to overestimate how quickly you can do things, but then you discover a lot more things that you didn’t consider before. But yeah, that was an interesting project to work on. And we launched it in September together with the Taproot support, and now we are still working on it for the future features like the scripts and multisignature and so on.
Stephan Livera:
I see. And so at the time you joined, what were the main aims of the new app? Or was it—it just kind of evolved and then became to this point where, Okay, actually it makes sense to now relaunch the app or have a new version?
Salvatore Ingala:
Yeah, I mean the initial scope was just to improve on the existing app that we had. And so to add a feature that basically is becoming necessary—like any hardware wallet or any software wallet has to support PSBT, right? But because the previous app was written a long time ago—like it was designed when a lot of the technologies that we have today in Bitcoin didn’t even exist—the initial version of the app was maybe developed in 2013, I think. So that was even before SegWit. And so there was no PSBT at the time, there were no descriptors. And so decisions that were made back then now are not optimal anymore. And so it just became not possible to incrementally improve on the previous app. And so it was just even less work to actually come with a new app, a new design, so that we had the chance of completely trying to remove the tech debt and get some completely clean new architecture—more simple and more structured and more organic.
Stephan Livera:
I see. Yeah. And so we’ll try to keep it accessible for listeners as well. So if you’re new and you’re trying to learn about Bitcoin, the way Ledger typically works is you might have received it and you might install the software. So the default software is Ledger Live, so you can use it with other software or with other providers. And so what we’re talking about here is: when you install and when you set that wallet up, you actually have to download and install a Bitcoin app, essentially. And so what we’re talking about here is version 2.0 of that app, correct?
Salvatore Ingala:
Yep. So yeah, in particular in Ledger, there is a distinction between like the firmware and the operating system and the apps that you can install, while other hardware wallets might be more monolithic—and so you install everything altogether. And so yeah, my work is specifically on the Bitcoin app in Ledger.
Stephan Livera:
Gotcha. And so now just to explain a little bit further for listeners who might not be familiar: can you explain what is a PSBT?
Salvatore Ingala:
Yeah. So a PSBT stands for Partially Signed Bitcoin Transaction. And it’s been a format basically to represent—in a standard way—all the information that is necessary when you want to sign a transaction. So that’s a format that has been developed over the last few years by Andrew Chow—Bitcoin Core developer. And the problem it solves is basically that when you have more complex transactions than typical ones—you might have different parties involved, right? So for a simple transaction, you’re the only person signing, so you just send a request to your hardware wallet, the hardware wallet signs it. That’s it—you can produce the final transaction. But for more complex situations, you might have different parties that are in the same wallet. For example, a typical example is the multisignature wallet where you have, for example, three signers, and maybe you have two signers that have to sign to approve the transaction, right? And so there is the problem of how you coordinate different parties that perhaps might even use different software. So before PSBT, there were some working multisignature solutions like Electrum, but each of them will use their own way of exchanging this information, their own format, and so on. And so it was difficult to do things when you don’t use the same software in all the machines, or maybe you use different hardware wallets, and so on. So with PSBT, basically what it does is that it embeds some generic information about the transaction, plus for each of the inputs and for each of the outputs of the transaction it also has all the information that is required for the hardware wallet to sign the transaction. So for example, one of the things that—before Taproot—was necessary to do when you sign a transaction is to make sure that the output you’re spending (the prev_out) is the one that is being declared, because let’s not forget that in the security model for the hardware wallet, we are assuming that your computer could be completely compromised. So there could be a hacker completely controlling what’s happening in your computer. And so you might think that you are sending some request for a transaction, but someone might change the data before it reaches your hardware wallet, right? And so even in this situation, we want it not to be possible for you to sign something you don’t want to sign. So the hardware wallet has to verify a number of things to make sure that it’s signing the correct thing. And so even this information that is accessory information that the hardware wallet needs is also embedded in PSBT. And there are a lot of other fields that could be relevant for different types of scripts, different types of transactions, and so on, and by standardizing this it becomes a lot easier to integrate with different softwares and also to abstract the complexity from the software wallet writer. Like you can have some libraries that work with PSBTs and then you don’t care in detail the inner workings, how all these things work—you just use these libraries and you can write software wallets for multisignature much more easily.
Stephan Livera:
I see. And so, again, I’ll just give a quick summary for listeners who might be thinking, Whoa, whoa, that’s a lot of technical stuff. So the short version—PSBT, Partially Signed Bitcoin Transactions, are like a special format that is used to make it more interoperable between different pieces of software and hardware. And so previously each different piece of hardware wallets, or each different software, might have had their own way of doing things. Whereas PSBT we can think of it like a standardized way to send that information back and forth. And so what’s happening in the background—for listeners out there—when your Bitcoin wallet is spending money, it has to look at, Okay, what are the available inputs I have in my wallet? And then I’m gonna select, Okay, this one, this one, and this one to be the inputs to my transaction. And then I’m going to put that into this PSBT and I can send that out to the various hardware wallets for them to be able to sign that transaction. So people might have incorrectly—for example, they might have thought, Oh, the PSBT is only like, say, if you’re using a micro SD card. But actually it’s more like at a very—more data-level—it’s happening at this way of the wallets sharing that information so that they know the right way to sign that transaction and get it ready, so that then once it’s finalized and ready for broadcasting then it goes out to the network. And so that’s just a little bit of information there. And of course, I’ve got an episode with Andrew Chow Episode SLP99, if I recall correctly. So stephanlivera.com/337, you’ll find all the show notes for this one. And so, Salvatore, can you tell us a little bit about PSBT and how that’s being implemented now into the Ledger hardware wallet, and also Ledger software—Ledger Live?
Salvatore Ingala:
Yeah, so in the new design of the app I was thinking like, How do we go into using the PSBT format in the new signing flow for the new app? So there are a number of issues that had to be solved. One of them is that the PSBT format is typically meant to represent things that can be pretty large, like it’s not difficult to construct PSBTs that are several hundreds of kilobytes. And so one issue is that you cannot think of sending the whole thing to the device. Ledger Nano S has something like 4 or 4.5 kilobytes of RAM available to the app. And so it has to work with little pieces of the information at a time, right? And in terms of architecture, when I thought of what it means to sign a PSBT, what I figured is that we need to tell the hardware wallet how do we want to sign this PSBT, because when you sign a transaction in the typical case, it’s one of the standard type of transactions that are already known to everybody. But then when you have complex scripts, then you need to tell the hardware wallets how is this script constructed, right? So if you’re a multisignature wallet, the hardware wallet needs to be aware of who are the other co-signers, or what kind of script specifically you are using. And the reason that’s important is that all this information about what kind of policy you’re using to sign the transaction needs to be also validated from the user, otherwise there are possible attacks there. Because, for example, if someone replaces one of the co-signers, then they might put a different co-signer than the one you’re expecting. And now you don’t know, but you’re sending your transaction to a different wallet than the one you’re expecting. And maybe one of the signers is the attacker. And now the attacker can ransom you, can tell you like, Oh, unless you give me half of the Bitcoin, that Bitcoin is lost—you can never retrieve it. And so together with supporting PSBT natively on the app, what we did was to develop this framework to register a policy on the device, where a policy is basically the description of the kind of script you’re using. So in the case of multisignature, is slightly more than just the list of the co-signers. But we designed this already with more complex future scripts in mind. So the goal will be to support things like miniscript that can add more complex policies. And maybe we’ll go into this little bit more later.
Stephan Livera:
Excellent. So one other question I had just around the amount of RAM on the device. Now, of course in Bitcoin, part of the way things are being built—especially at the protocol level—is to sort of allow backwards compatibility as much as possible. But I wonder at what point does it actually make sense to say, Well, okay, we need to upgrade and move to newer hardware wallets that actually do have more RAM. So could you just outline a little bit of your thinking there? Like at what point would you have to sort of say, Okay, look, we are going to have to stop support for some of the newer features, because let’s say the older hardware wallet devices just simply cannot support it. And you’re going to have to upgrade to the new hardware wallets that let’s say have a bigger CPU or more RAM, et cetera.
Salvatore Ingala:
That’s a great question because it kind of resonates with a lot of the thinking I was doing on this new protocol in the app I was working on in the early stages. And so the thing is: what is a hardware wallet? A hardware wallet—even the term wallet is not exactly a very good description because it’s not really a wallet. A hardware wallet is just a device that is able to store keys. And in Bitcoin, actually you just need to store one key which is the master key and thanks to something called BIP32 you can derive all the other keys that you might ever need. So in terms of what the hardware wallet needs to really store to work with Bitcoin—it’s very little. And the thing is: having very little RAM or very slow CPUs make your programming life a lot harder. And so while some things can be possible even on simple machines, the reason you want to extend is just to be able to develop some more complex features, right? But the thing that I was trying to work on with PSBT was that apart from the keys—that is, the private keys that you need to sign the transactions—everything else doesn’t necessarily need to fit in the RAM of the device at the same time. And so the solution we came up with was to use something called Merkle trees. It’s difficult to explain Merkle trees without getting a little bit technical so this might scare some people, but the general idea is that it allows us to work with some data, that instead of it being kept on the device, is kept outside of the device. But the client library that is talking to the device is able to prove the correctness of the data it’s working on. So this is how we use Merkle trees. And so we designed a whole protocol around Merkle trees to be able to work with these large data structures. For example, in particular the PSBTs are represented with a series of Merkle trees, combining other Merkle trees and so on. And this allows us to make some complex protocols where we ask the client library to provide the information that we need on demand, yet thanks to the properties of Merkle trees, the client is not able to cheat. So even if the client is malicious and is hacked and it’s compromised, it cannot lie on the content of these Merkle trees. It cannot lie on the content of the PSBT that was provided when the process was started, basically.
Stephan Livera:
Right. Yeah. So just one question at this point: when you say client, are you referring here to let’s say the desktop wallet app that somebody is using to coordinate with let’s say the Ledger in this case? So, I mean, hypothetically, if someone had a malicious Ledger Live software, or if they were to use a malicious version of Electrum or Sparrow or Specter, or one of these software wallet applications that we use to coordinate with our hardware wallet, or maybe signing device or whatever we want to call that—is that what you’re referring to with client?
Salvatore Ingala:
Yeah, exactly. Everything that sits on your desktop computer is what I call the client. And like, basically, even if your Ledger Live is not malicious, you might have some malware, you might have some virus installed on your computer that tampers with Ledger Live and it makes it do things that it shouldn’t do. So from the point of view of me developing the hardware wallet applications, I have to not trust anything that the client-side does. So I’m assuming I’m talking to a compromised Ledger Live, because that’s the only way to make sure that we respect this security model where even a compromised client cannot do bad things.
Stephan Livera:
I see. So let me just offer a quick explanation for newer listeners: so part of the security advice and tips over the years has generally been that it’s easier to compromise let’s say the computer—the online connected PC or laptop—than it is to compromise the hardware device. And so the argument has been, if the screen on your computer is saying, Send 0.01 BTC to this address, don’t just trust that—actually look at what your physical hardware wallet device is saying and use that. So in practice, it would say, Do you want to send 0.01 Bitcoin to BC1-blah, blah, blah, whatever address. And so I guess bringing that now into Ledger’s new Bitcoin 2.0 app, what would that actually look like? What is the customer—when they’re physically holding the device—what does it look like for them to verify now?
Salvatore Ingala:
So for traditional transactions like the normal singlesig transaction, nothing will change—meaning like the user interface will stay the same way that users are used to. So when you send, you are always going to verify everything about the transaction. So the amount, the fees that you’re spending, and who you’re sending to. So the addresses of the people that you are supposed to send to so that you can check if what you see on the device screen is the same that you see on the screen of the computer. And the same thing you want to do also when you verify transactions, when you want to receive some Bitcoins because you want to send your address to someone. But again, if there is some malware on your computer, you might copy something from Ledger, Live, you paste it somewhere else and what you paste could be different because the malware already changed it, or even the malware will show you something different inside Ledger Live if it’s smart enough. And so even when you want to send to someone else an address that you produce from Ledger Live, by verifying the receive address on the device, you are much safer because you verified it—it matches. And what was missing in the previous app was to be able to do this kind of verification, both for receive addresses but also to have a proper signing flow for more complex script language, the signature that was able to correctly verify and identify what is the change address and all these things. So now the new app basically can do the same things that people are used to for simple transactions, for more complex cases. So the user interface, when you send a multisignature transaction from the hardware wallet, is very similar to the usual one. We can go a little bit more about how it looks like and the policy registration and so on, but really the goal was to give the same UX that people are used to, with the only difference that the hardware wallet also tells you from which multisignature wallets you are spending, basically.
Stephan Livera:
Got it. Okay. Well, this is probably a natural point to go into that. So let me just offer a quick, basic explanation for people who are a bit newer. So typically with multisignature setup creation—so let’s say you use Specter desktop or Sparrow or something. As part of that multisignature setup, one of the cool features we’re seeing with some hardware wallets is that they are able to—I guess there’s different terminology used—but you could say register the quorum or sort of understand what is the public key of the other devices in the quorum. So let’s say I have device A, and it’s a 2-of-3, and you’ve got device A, B and C, device A would actually have the public keys of device B and C as part of that. And it might have been fed some of that information to help—as you’re saying—verify and understand, Ah, yes, I actually do control the change address. So when that wallet constructs the transaction, it’s sending out to the address you want to pay to, but the change address is coming back to one that you control—or at least that multisignature quorum controls. So do you agree with that? Or do you have anything to add to that point?
Salvatore Ingala:
Yeah. One thing we can add is that one thing that another technology that is now central to the new app that we didn’t mention so far is the output script descriptors, which is again mostly developed by Andrew Chow I think, and what descriptors do is to be able to describe all the receiving addresses or the change addresses or all the possible addresses of let’s say a wallet or an account in a simple way that can be easily transferred to different applications and so on. And the reason that’s useful is that once we start using multisignature or more complex scripts, we need to be able to describe how these things look like, to describe really to the hardware wallet or to the software you’re using to sign transactions. And by knowing these descriptions—that look like a little programming language, basically—the wallets are able to identify [and] to generate all the addresses that are relevant for an account. So both the receive addresses or the change addresses. But also they’re able to, from the point of view of the hardware wallet, is able to really verify that the transaction is going where it’s supposed to go. So in particular, when you spend, for example, 1 Bitcoin—but 0.9, Bitcoin is going back to your own wallet because it’s the change address—the hardware wallet needs to be able to detect which output is the change address. And descriptors allow us to do that. And the wallet policy language that we use in the new app is basically designed on top of descriptors, meaning it’s a slightly more modified language because there were some needs that we have specifically for the hardware wallets that were not taken into account when the descriptors were designed, and these needs are that—one is that the descriptor language is a bit too verbose for the user. It’s too long. Like when you describe a multisignature wallet, for example, with Specter, you can export the descriptor for your backup, for example, but it’s a very long string because it contains all the XPUBs, the public keys of the co-signers. And so it’s a very long string. And for example, the receive addresses and the change addresses are almost derive from the same XPUB with just a very little modification. And so it means that the same public key is basically present twice in the descriptor. So by modifying the language a little bit, we are trying to do something where first we separate the keys from just the general template of the scripts. So we say, Okay, this is just a multisignature 2-of-3. So you can visually see on the screen some simple description of what you are registering on the device when you register a policy. And then you have the list of the co-signers that you check one by one. So this is how the UX flow will look like when you register a policy. And so from the policy, the hardware wallet can easily derive the actual descriptors. And then from the descriptor, it can derive all the addresses and everything, and it can do all the checks that it needs to do. And so the idea of the new flow is that by using this language, you can do—once—when you start using a new multisignature wallet, you can do this registration of the policy that teaches the hardware wallet how to recognize addresses and outputs that are relevant to that specific multisignature wallet. And from that moment on, the hardware wallet knows how to recognize them, and so it can give you the usual experience when you sign transactions or when you verify receive addresses.
Stephan Livera:
I see. So the output descriptor part—actually, I’ve got an episode: just for listeners, I’ll put that in the show notes as well, so stephanlivera.com/337, you’ll see that episode with Andrew Chow—but essentially it’s like an easy way to quickly represent what is that multisignature setup, or more advanced setup. So I guess in this case, we’re talking mostly from a multisignature point of view—that’s kind of the key thing. So as you were saying there, this is part of that registering the multisignature setup at the start. It’s a one-time thing. So is this something that would then come into Ledger Live itself, or is this something more like it’s kind of operating more at the software, underlying level?
Salvatore Ingala:
I don’t know that right now. I don’t think it’s in the plan for the short-term because it will not really give any specific advantage to Ledger Live, unless Ledger Live wants to integrate at some point multisignature.
Stephan Livera:
I see. Okay. So essentially what we’re talking about is just more like additional or better support for multisignature at the device, let’s say the Ledger Nano S and Ledger Nano X level, not necessarily putting multisignature creation and quorum management inside Ledger Live, which is the desktop or laptop software, correct?
Salvatore Ingala:
Yeah. I hope it will eventually also be on there, because I think the end goal of PSBT and descriptors and so on is that eventually all wallets will be interoperable and will support all the same kinds of advanced scripting conditions without really having to care about the details. And I think the potential is there, but it’s a long way to go before we are to that point.
Stephan Livera:
I see. Yeah. And so one other comment that I’ve seen from the blog post, as well as some of the Twitter commentary, is that the hardware wallet is still going to be stateless. So, first of all, what does stateless mean? And then explain a little bit in the context of this—let’s say you have a multisignature. How does that work if the hardware wallet is still stateless?
Salvatore Ingala:
Yeah, exactly. So the meaning of stateless in the context of hardware wallets means that, apart from the seed—like the 24 words that you store on the device—you store nothing else on the device that you need to persist in the long-term, that you need to remember for the future. And this is a design decision that has some advantages and some disadvantages. One big advantage is that the only really crucial thing that you need to back up is your seed, right? And as long as you have your seed, you can still reconstruct all the basic addresses and everything that you need to reconstruct all the keys that you might ever need. That’s not entirely possible when you work with multisignature wallets, because it’s important to also have a backup of the of the multisignature wallet. So unlike the seed, which is so important to keep private and so you never want it to leave the hardware wallet, the description of the multisignature is not so private, meaning losing it has some privacy implication, but nobody can still spend your funds if they discover your backup of your multisignature wallet. And so several hardware wallets recently started to have some kind of process to register these policies on the device, to register multisignature on the device so that you can use it, but that’s not easy to do at Ledger because of this decision to keep the device stateless. And so what we did was to come up with a solution to make it possible for the device to kind of remember that something was registered, even if it’s not really stored inside the device. And the solution we came up with is to use something called HMAC. It’s probably easier to think of it like a signature. So when you register a policy on the device, there is the whole description of the policy. So this policy is called, let’s say, cold storage. And this is the descriptor of this policy. So it’s a multisignature 2-of-3, and the keys of this wallet is me, Stephan, and Jack Dorsey. And that’s it. So that’s everything that is in the description of the wallet. And this is registered on the device. And what the device does is first validates with the user. So the user has to approve. So you verify on the screen of the device that you’re registering this policy, all the information that we just mentioned is shown on the screen and you have to approve it. And once the user approves everything, the device returns basically a signature, a statement that says, Okay, I approve this policy. So in any future interaction with this policy, for example, when you want to sign a transaction, the client library—the client software—could be, let’s say, Specter desktop, for example, will have to send the description of the policy to the hardware wallet, and the signature that proves that it was previously registered. So the hardware wallet can verify that. And so without ever needing to store everything, you get the same result as if you actually stored it inside.
Stephan Livera:
I see. So just to be clear then: in this case, is the device still storing then that string to then check it against that? So is it now essentially storing the seed and this string so that it knows, Okay, yes, this is a valid—
Salvatore Ingala:
No, it’s not storing anything because the private key that is used to sign the statement is also derived from your seed. What we use is something called SLIP-21, which is something similar to BIP32, but for symmetric encryption. It gets very technical, but basically you can derive the same key from your seed. And so even if you erase your hardware wallet and you set up again the hardware wallet with the same seed with the same 24 words, then that signature will still be valid. And so basically, once you register a policy on the device, you cannot unregister it. It is not revocable. Of course you could delete the signature, and if nobody has the signature it’s equivalent to unregistering it, but there is no actual way of proving that that was deleted. So the only way to really revoke a multisignature would be to spend it and move the funds to a different wallet.
Stephan Livera:
I see. So just as an example, does that mean then you—let’s say you would use Specter desktop in that example—you then could not take that setup over and use it on say Sparrow Wallet, Electrum, or something else, because you had already agreed it to that initial Specter desktop setup? Or where am I missing it there?
Salvatore Ingala:
So, one thing that could be done is to try to standardize this process. And so the signature wallet returns is just a 32 byte string. So once you store the 32 bytes, you can move it elsewhere in principle, and as long as we agree on the format that could be done, but that’s something that will need to be maybe standardized.
Stephan Livera:
That’s a later conversation, right.
Salvatore Ingala:
But basically, if you lose that, the only thing you need to do is to re-register the wallet in a different software, and then you can start using it. The only thing that you need to do for the registration is to have the backup of the wallet. So the information that any multisignature wallet will have this backup.
Stephan Livera:
Gotcha. Yeah. So it’s not like a showstopper—if you lose that 32 byte string, you could recreate it so long as you had your overall wallet backup, which, if we’re playing in a multisignature context or world here, then you presume the software or the company or ideally the tech-savvy user knows to keep that backup, which is the multisignature backup. Which could be held on a USB stick, it could be a printed out paper file, it could be all kinds of different ways that could be backed up. But the point is: that should have been backed up to show, Okay, what are all the public keys of all the wallets associated with this multisignature wallet? Not just, you know, the typical 24 words seed aspects of it.
Salvatore Ingala:
Yeah. For multisignature wallets, keeping that backup, or even for future more complex scripts, having that backup of exactly what is the policy it’s crucial. Like if you lose that, you might not be able to retrieve your funds, ever. Like you can try to guess it when it’s some simple script, you can try to guess, Oh, what was the script, but the complexity there can get high enough—like the number of policies—once you start thinking about more complex policies, you might have multisignature that also has additional conditions like timelocks, like you cannot spend these funds before one year. And at some point the number of combinations become so much that if you don’t have the backup, you can never retrieve your funds. So the backup there is really crucial.
Stephan Livera:
For listeners or just people out there, if they are customers of, let’s say for example, like my sponsor Unchained Capital, or if they’re using say Casa, and they have a Ledger device as part of their setup there, what kind of changes would they see using the Bitcoin 2.0 app? Or, if any?
Salvatore Ingala:
I’ve never used Casa. I should, because I really would like to see one of those. But once the app was out, one of the things that I’ve been working on was to try to make integrations easier. So together with the app, in the month after, I released a little Python library that is able to talk to the application. And currently I’m trying to—like the two things that are more important to me right now to get done will be a proper integration with the hardware wallet integration library, which is a library developed again by Andrew Chow—like, he’s always present in these things—which is basically: the Python library is able to talk in a standardized way to all the different hardware wallets from different vendors. And the library already supports Ledger wallets, but it does not yet support the new multisignature features, and there is some work to be done there. And I’m working with—I tried to make a little proof of concept with Specter on how it would look like to integrate the multisignature support for the new app. And yeah, the only non-trivial thing is that the registration flow is not something that—it’s a new concept. So there is a little bit more work to be done in the UX because you need to have this in the app. But once it’s done, it’ll really look like any other multisignature wallet. Like, the beauty of these things is that it completely abstracts the complexity behind. So for the end-user, what you see is: you’re signing a transaction, like you’re signing a transaction and you’re signing it with this wallet. Like for people who have never used multisignature walllets, Specter and Sparrow are the suggestions that I’ll give, because they’re really very good and easy to use. And they make the user experience quite quite seamless, if you think about it. Like once you create a policy register, now you want to sign a transaction. You just say, Okay, sign with this device, you plug your device, you sign your transaction—that’s it. So in terms of the user interface, the goal is really to not change anything for the user, almost.
Stephan Livera:
I see. Yeah, no, it makes a lot of sense. I think it’s probably—I’m just asking the question as well, because I have a lot of listeners who might be on the more tech-savvy side, and they’re kind of more interested exactly how the nuts and bolts are working because they might be trying to play around themselves with Specter and Sparrow and all sorts of things. Also, Taproot support. So can you tell us a little bit about Taproot support in the new app?
Salvatore Ingala:
Yeah. So Taproot support was—yeah, we were quite proud to be ready on day one with at least basic receive and send support. And there is definitely—maybe for people should I also introduce very briefly what Taproot is? I guess you might have had other shows on Taproot that probably give more details so people can check those out. But basically, Bitcoin had recently a new softfork that introduced a lot of new cool stuff, and in particular a new transaction type called Taproot. One of the things that it does is to make policies that are more complex in particular, again, multisignature but even more complex scripts, both more private and more efficient to use with Bitcoin. Like one problem that you would’ve had in the past—and you still have until some work for integration is done—is that if you use multisignatures, your transactions are actually more expensive than single signature, so you are disincentivized to use those. While once the proper integration work is done in the ecosystem with Taproot, it will be possible to do basically multisignature transactions that are invisible to other people and they are more private. So that’s extremely exciting. And one of the things that Taproot does is also to make very complex scripts a lot more efficient. And the technology they use is, again, Merkle trees. Basically, instead of having just one complex script that has all the possible conditions, you put all of these conditions in a Merkle tree, which is this structure that in a very short way commits basically to all the possible scripts. And so when you want to use one of these spending conditions, you only reveal the one that you’re going to use. I guess it could get a bit more technical, so maybe we leave it here. And yeah, in Ledger, we have Taproot support for BIP87, which is the normal single signature transactions. We don’t yet have support for scripts, but that’s definitely like one thing that we will work on in the next few months. One issue is that the goal of the new app is to support arbitrary scripts. For example, with miniscript, and miniscript is not yet standardized for Taproot. So we’ll be on the lookout for the standardization efforts, and definitely we would like to support it as soon as possible, but that goes on and on with the progress within the ecosystem. But once that’s done, definitely it will make sense for anybody who uses more complex conditions to move on to Taproot instead of SegWit, because you can do more stuff and you can do it more cheaply and more privately. And one thing I would like to mention about Taproot is there has been a lot of misleading or wrong information about Taproot. Like there are people saying like, Oh, Taproot is so exciting—we bring DeFi to Bitcoin. No, it doesn’t, it wasn’t designed for that. And on the contrary, there have been lot of people saying like, Oh, Taproot is so overhyped, it doesn’t actually change a lot in Bitcoin. And I think Taproot actually changes a lot in Bitcoin, but the effects will be much more visible in the longer term. Meaning in the short term, people will not see anything because it’ll take time to actually do the work of implementing all these things. But one thing that changes with Taproot is that a lot of these complex scripts become usable in a completely seamless way for the end user. For example, one thing that I will be particularly excited about exploring with Taproot will be assisted custody, where you could have a wallet where it looks like a normal wallet for all use cases. But if you lose your key, there is some custodian that after two years, maybe, or after one year, can retrieve your funds. And you can build even more complex ways, more complex conditions. You can have services where you can use multisignatures to have more complex policies. You can have noncustodial services that can provide some additional conditions. So the beautiful thing of Taproot is that it makes these things possible at no cost, at absolutely zero cost for the end user. And unless you lose your key, it really looks like a normal wallet to you. So I’m really excited about these kind of applications and about more widespread adoption of multisignature that will probably come together with with PSBT adoption.
Stephan Livera:
Right. And so just exploring that idea for a second, it could enable new kinds of storage methods. So as an example, people could have maybe 2-of-3 multisignature or 3-of-5 multisignature, but planning for say maybe after two years or after three years, there’s some kind of backoff or backdown: instead of 2-of-3, it’s 1-of-3 after five years to help in the case of recovery or something, people can build more fancy and advanced methods of doing this using the scripting capabilities that are more easily enabled in a Taproot and Tapscript enabled world. Because historically, if people wanted to do that pre-Taproot, they would’ve had to have a script that contained all of that. And basically everyone can read that. Whereas now, in the Taproot world, as let’s say, Pieter Wuille would explain it, he calls it policy privacy, right? You can have all of these other spending conditions in your tree, and you only have to reveal it when you go to spend it. As opposed to revealing it even when you started that setup, right?
Salvatore Ingala:
Yeah. And on a similar direction, for example, one thing that could be done is for inheritance planning. Like, one thing that people often forget is what happens to my Bitcoins if I die? And if you have, for example, three kids, you could have a policy in your wallet that says like, Okay, after three years, two out of three keys of my kids can can access my funds. And that’s similar to what we described before, but it’s for a different use case. And again, could be done completely transparently, could even be done without your kids knowing it. And you tell them in your will, for example. I think all these things are really very little explored. And there are a lot of opportunities to build businesses and products and things on top of this.
Stephan Livera:
Yeah. That’s really fascinating to think about. Like, as an example, let’s say you are the father of three children and maybe you put a hardware wallet with that public key that you know of, you know, you setup your different vaults, one for each kid, and then in the will you say, Hey, I gave you access to a hardware wallet and the backup is here and actually two of three of you can spend it, or something like that.
Salvatore Ingala:
And then you could even add another key with your notary that is only active after five years, for example, so that you can always add more conditions that downgrade slowly the security or become more custodial, but you only use them in case of emergency.
Stephan Livera:
Yeah, that’s really fascinating. So there’s all kinds of possibilities there. And also you touched on miniscript earlier. So could you explain just the high-level beginners—what is miniscript? And what are you thinking of there as a potential with the Ledger Bitcoin app?
Salvatore Ingala:
Yeah. Miniscript is basically a language built which is very similar to descriptors. It’s kind of an extension of descriptors, and it adds a bunch of properties that make manipulating scripts a little bit more easy and streamlined. The main thing from the point of view of the application is that that we can represent more complex policies in a simple way. So the same way that we describe multisignature, by adding some more functions to the language, some more operators, you could add different conditions that are either additional or an alternative the policy that you already have. For example, we already mentioned the timelock, like the simple output descriptors don’t support timelocks, but the miniscript language supports timelocks, so you can have combinations of keys, plus some delay that before you can spend the funds, some time has to pass. And these timelocks are useful both because you might just want to lock your funds for some time, but also because they’re used in many protocols to ensure, for example, in Lightning network, timelocks are used to make sure that the rightful owner of the funds can access the funds before someone else we will be able to do it. So you can design more complex smart contracting systems, like layer 2 systems, using these complex scripting conditions. So miniscript basically allows to extend beyond the multisignature, because it allows, for example, to combine several multisignatures or to combine multisignature with timelock, and all the possible conditions that you might have in Bitcoin, or could be of course expanded in the future if new opcodes are added.
Stephan Livera:
I see. Yeah, this is really fascinating stuff. I’m also curious as well around any thoughts on the likes of MuSig, MuSig-DN, or MuSig 2, do you foresee that being necessary, or do you have any thought of that kind of thing being applied into the Ledger Bitcoin app in the future?
Salvatore Ingala:
That’s very interesting. Yeah. I will say not in the very short term, because there are things that are easier and more like—you catch the things that are higher-yield first. But it’s definitely going to become the standard for multisig in due time. So it’s definitely something I will be interested in exploring at some point, because MuSig really gives that benefit of making multisignature as cheap as single signature wallets, which you don’t get just with miniscript.
Stephan Livera:
Okay. Excellent. And so I guess those are the key questions I had around the Ledger Bitcoin 2.0. Do you have any other comments for us just in terms of what’s next for Ledger and Bitcoin technology, Bitcoin security, anything else to share with the listeners?
Salvatore Ingala:
For what’s new for Ledger? I guess maybe you can ask Charles Guillemet next time you have you have him on the show.
Stephan Livera:
I’ll ask Charles, yeah.
Salvatore Ingala:
You can ask Charles for those. Like, I don’t set priorities, but I can tell you the things that I’m more excited in Bitcoin personally: definitely more widespread adoption of miniscript and policies and everything, like streamlining these things is probably the lowest-hanging fruit right now in Bitcoin. I’m also excited about the more widespread adoption of layer 2 solutions which doesn’t stop at Lightning. Like recently people have been developing the statechains idea. And that’s also very interesting to explore because I don’t think the layer 2 space ends at Lightning—I think there will be a lot more things. There are protocols being built like Revault, who’s been building vaults that are based on protocols based on pre-signed transactions and so on. And actually about a month ago I did a tweet trying to fetch comments on like what we would you want hardware wallets to do in the future. And I was totally restrained by Adam Back saying like, Oh, more complexities is bad. You want to keep things simple and so on, which I think missed a little bit the point of my question, because what I was asking is what do we want to do with hardware wallets in Bitcoin? Because I think people who think in the future you’ll be able to do everything with a Raspberry Pi for Lightning Network are not bullish enough, because if the price of Bitcoin goes up—not investment advice—but if the price of Bitcoin goes up let’s say 10X from now, opening and closing a channel will start to become a little bit too expensive. And so there will still be the need for other layer 2 systems, other solutions, other custodial or semicustodial systems and so on. And the amount of value transacted in the Lighting Network will be a lot higher than it is now. So you will not want—like you cannot feasibly consider doing that with just hot wallets, right? So you might want to have hardware-level security even in the Lighting Network. So one of the things would be interesting to explore is: can we provide some more security to the Lighting Network? Or can we provide some more security to statechains? Or to protocols that use pre-signed transactions like the vaults? And definitely those are interesting things to explore. And I think there will be a lot of work to do in the next few years in the hardware space as well.
Stephan Livera:
Fantastic. So yeah, today we spoke a little bit about a range of things. And so some of those things are more further off like the likes of miniscript and MuSig and so on. But I think the important things for today: PSBT support, Taproot support, and also making multisignature a bit easier for people even just in today’s multisignature context, because the more people who can easily use multisignature, the more robust, the more secure people can become and the more robust the overall ecosystem is. So I think those are probably, at least for me, from my perspective, those are my highlights in terms of what we’re seeing out of the new app. So I guess that’s probably a good spot to wrap up there. Salvatore, where can people find you online?
Salvatore Ingala:
Right. They can just find me on Twitter. My username is @salvatoshi. So hit me up if you have any comments or questions, or if you want a feature that we didn’t implement yet. Of course we are listening. And also I’d like to mention Ledger is hiring. So if people are interested in working at Ledger, there are a lot of open positions. So maybe come to work with me on Bitcoin.
Stephan Livera:
Fantastic. Well, thank you very much Salvatore, and speak again soon.
Salvatore Ingala:
Thank you, Stephan.