Can we give a round of applause for Kevin, and welcome him to the stage. Thank you. Alright, yeah, so I'm going to do a talk around Timelocks in Bitcoin. I'm going to start with a pretty quick introduction on the different types of Timelocks over time in Bitcoin, and where we're at today. Also, a little bit, very, very quickly talking about what we're using Timelocks for in Bitcoin today. And also all the very exciting stuff that's happening on Bitcoin in the past few months that is going to completely change the game over how we use Timelocks. And by the end of this talk, I hope I will have convinced you all that the future of Bitcoin is pretty much having Timelocks everywhere. So yeah, that's the idea.

So the quick history, I mean, it's just, you know, many of you probably already know that. It's just that I'm doing a quick refresher on what Timelocks are, how they work. The very first one on Bitcoin was by using the nLocktime. So the way this works, this is an absolute Timelock. So at the very beginning of Bitcoin, you could already set a field in your Bitcoin transaction that's called the nLocktime, and the amount or the number you would put in this field would be the minimum block height that the blockchain should be at for your transaction to be relayed. This was a relay policy, so it was not a consensus rule, which is, you know, it's not very smart. That means that you could have a transaction that prevents yourself from spending or from being added to the blockchain. But if a miner got it, they could still put it through. So that was, you know, changed pretty quickly to add as a consensus rule. So now blocks wouldn't be valid if they include a transaction with an nLocktime that is higher than the current block height.

So this is cool, but it's still not enough because this is at the transaction level, meaning that if you have the private key, you can still, you know, sign a different transaction without this lock time. And so you could, you know, bypass yourself or, you know, remove the lock time from the transaction.

So what's really interesting in Bitcoin script is when you want to enforce conditions. And so you can enforce this by an Opcode. This one is a CLTV, CheckLockTimeVerify. So when you add that in your script, basically it's going to enforce that the transaction spending this UTXO has an nLocktime set at a higher or equal value than this CheckLockTimeVerify. So what that means is that, you know, I'm giving you a Bitcoin address. You probably don't know, you know, what the script is, but maybe the script when I crafted this Bitcoin transaction actually include an OP CLTV, and this will prevent me from spending this transaction before block, I don't know, 800k right? So we're not there yet. What that means is that when you send me money, I will not be able to spend this money myself before we reach block height 800,000 or more.

We also had something a bit different, or added, to also allow for actual time, not just a block height, just because it's more practical for some people for some use cases. So depending on the value you have in this nLocktime, it can be interpreted as a time, a date, you know, in the calendar. So that's in Unix time. So, yeah, just so you know, you don't have to set a specific block height, you can just say these funds are not going to move before 2130. Well, actually, no, not with that one. So let's say 2030 and and that would be locking your funds until that day.

Then relative Timelocks were added. So we're talking about like 2015 for CLTV, 2016 for the equivalent in relative Timelock. What a relative Timelock is, is that instead of having a specific time or a specific block heights at which you can now move the money, it's actually starting the counter from when the UTXO was created. So when the output you are spending was mined. So that's when you start your counter. You are then defining a number of blocks that you need to wait before a transaction can spend from that. There is also the equivalent in term of time. So you have blocks of 512 seconds that you can, you know, increment. So you can have that in seconds instead of blocks. And there is the equivalent of CLTV called CSV. So CSV is just the Opcode that's going to enforce that there is a relative Timelock in your transaction. A little bit of a difference from a technicality here. The nLocktime is at the transaction level. The sequence is at the input level. Doesn't matter much. But yeah, also the end sequence is used for other things. Not going to cover that at all. But it's, you know, yeah, there are a few things we use and sequence for. So what I'm talking about here is just the Timelock part.

All right. So that was very, very quick intro. You might have heard about some things. I think my numbers are quite right here, but I'm not too sure. So if I'm doing some mistakes, feel free to correct me. I don't think I would be far off. But anyway, so there is some FUD around Timelocks. I mean, there's been some FUD forever around the fact that, you know, don't play with Timelocks because you're going to lock your funds forever. This might be possible using some Timelocks if you do really stupid things, but there are some that are a bit safer right? So if you use an OP CSV, typically this is the maximum amount of time you can lock your funds for. So if you use the number of blocks, it's going to be about, you know, just over a year, 455 days. And if you use the time in seconds, it's going to be, you know, 388 days maximum. So if you use a CSV, even if you do like, you know, big mistakes, you should be fine. You're much less fine if you fuck up in nLocktime because you can lock your funds for more than 9,500 years. So you may not be around when you do that. So, yeah, just so you know. The trigger here, I mean, doesn't really matter, but there is a limit. So if it's 500 million or more, it's interpreted in Unix time. If it's less than 500 million, it's interpreted in blocks. So that's why it's a long time because, you know, we're not at block 500 million yet. All right, and in the sequence, it's a bit more complicated there is different bits that have different meaning. So if the bit 22 is set, you see this value as like the value times 512 seconds. And that's the time in seconds. And if the bit is not set, then it's just in number of blocks. It's pretty similar, but, you know, 512 seconds is not exactly 10 minutes.

All right. So what is this thing? What are Timelocks used for today? Not much. I mean, probably you don't use Timelocks for your personal coins. You may for some cases, but that's very rare. So one of the reasons why people may want to use Timelocks for themselves is to prevent themselves from spending. Why would you do that?

Well, I don't know. Maybe you are a compulsive spender and you just want to hold your coins for a long time. And so you create an address, of course, yourself, right? Nobody can force you to use Timelock. And so you create an address and you just ensure that, you know, you cannot move these funds for 10 years. So that's, you know, forced holding strategy. You could do that if you wanted. This can be useful in Germany and now in Portugal, where you have a tax law that says that, you know, if you keep your coins for one year, then there is no capital gain tax. If it's less than a year, you need to pay capital gain. So why not, instead of keeping track of all the coins you buy and sell or whatever, or you receive from payments, just generate addresses that prevent you from spending for a year. So then, you know, your wallet is just, you're never going to pay tax on it. So, you know, that might be a use case.

The real thing that is used is basically an escape hatch for multi-party contracts. And there is some, you know, used ones like, I don't know, Green from Blockstream, where you can, like, basically when you use Blockstream Green, you use them or you can use them as a second factor. So basically every transaction you do is co-signed with Blockstream. Of course, if their server was offline or dead or they lose the key, you don't want your funds to be lost forever because of that. So there is a Timelock that they are using. You're not really aware of that. That will let you spend the funds without them after a certain time. I think that still works like that with Green.

And then you have more advanced stuff. So like Revolt that you might have heard of that we worked on. So Revolt is basically adding or playing with Timelocks and pre-signed transactions to be able to enforce spending policies on Bitcoin transactions. So that's useful in, like, multi-party scenarios where you're a group of people or an organization and you want to delegate some funds to, I don't know, some people who are going to do the payments. You want to make sure that they cannot spend more than 10k per day. You can play with, you know, smart contracts on Bitcoin just using Timelocks and pre-signed transactions and enforce this kind of stuff. So if you're interested, just look into Revolt.

The Lightning Network is also using this. It's using Timelocks for escaping the multi-party contract you have in your channel. So of course, if the other party in your channel disappears, you don't want your money to be locked forever. So you can use an escape transaction using a Timelock. And you can also use it, or it's also used in Lightning to be able to punish someone if they try to steal money from you. So if the other party in your channel is trying to revoke or to close a channel at a previous state, you have a Timelock there that you can play with to actually punish them and take their money. That's used today, but it's very specific, right?

So it's not very common for normal users to use Timelocks. And yeah, this is going to change. So, woohoo! The reason why... [audience question muffled]. Yeah, I mean, they just hold the gun longer. So, yeah, one of the reasons why this wasn't really enforced... Sorry, not really used until now is because of tooling.

We didn't really have good tooling. It's been 14 years that we have Timelocks in Bitcoin. But the problem is that it was still very custom scripting, and you're not, like really, you shouldn't play with custom scripts when you do your own Bitcoin wallet stuff. You're going to lose money because you don't have compatibility between wallets, because hardware wallets don't handle it, because whatever reason, right? So this is why nobody has really explored Timelocks in a normal day-to-day wallet perspective.

So very, very recently, and we're talking about just the last few months, output descriptors, and specifically miniscripts, has completely changed the game. So now we can have compatibility between wallets that are using complex Bitcoin scripts, including Timelocks. So Bitcoin Core has added miniscripts in November for the watch-only part, and just merged the code for signing as well. So that means that you can import an output descriptor with Timelocks, with miniscripts, into your Bitcoin Core, and you will be able to spend from it, which is really cool. You have libraries. So now you have BDK, you have REST miniscripts. These are out, and you can play with them. You can build a wallet with them. So you don't have to build everything from scratch. We're very far from crafting your Bitcoin script by hand. And also now we have signing devices handling miniscripts. So that was the last bit.

So yeah, Salvatore is probably in the room, or maybe. I don't know. I didn't come to his talk this morning, so maybe he's skipping mine. So basically Ledger has that in now their main Bitcoin app. So if you have a Ledger and you update it, you will have an app with miniscript capability. So it's capable of understanding the script. It's capable of generating the change address with the same script. It's capable of signing transactions. It's really cool. And the other hardware wallet that handles that right now is the Spectre DIY. There are more hardware wallets that are going to integrate miniscripts this year. So really excited, really exciting, and I really think we are going to change the game with that. So now wallets. We're starting to see some wallets that are capable of understanding that. So I mentioned Bitcoin Core. You have Liana that we're working on. I think Sparrow handles miniscript as well, although it doesn't really have, you know, Timelock per se, but it will be able to understand it and spend from it. You have another wallet called MyCitadel. So you have quite a few wallets already that understand this, and they are all compatible with each other. So this is also the very cool thing. We're not talking about custom things here. You're generating your wallet on one. You can just import it to the other one and spend from it. Big game changer. And all of that is like in the past few months.

So now is the beginning of my talk. So I'm here to talk about, you know, safer self-custody. A lot of people have been talking about self-custody being either, you know, oh, it's super easy. Everyone can write 12 or 24 words on a piece of paper. And then you have the extreme where people are saying, you know, people cannot do self-custody. They're going to lose their money. I don't believe in any of that. I think we're somewhere in between. It's not as simple as just, you know, writing 12 words on a piece of paper, because you need to also secure this piece of paper. And it's not also, you know, the solution is not to give all your money to Coinbase or whatever.

But now we can play with really cool stuff. So I'm going to play with you here, or at least to give you some ideas of what can be built today with these tools. We're not talking about crafting, you know, manually transaction or anything complicated. This is like, you know, graphical user interface stuff, compatible between wallets, compatible with Bitcoin Core. So you can do that today, right? So I'm just here to try to get you start thinking around what we can do with Timelocks today.

One of them is we could imagine now having a wallet where you don't make a backup of what I'm calling here the primary path, which is like your normal key with no Timelock. You use it like, you know, like your normal key. But then you have a Timelock that's, let's say, a year. After a year, you have a second key that becomes valid to spend this money. So instead of doing a backup of the 12 words of your main wallet, of your primary key, you're going to make a backup of the one that's Timelocked. Why would you do that? Well, there is a lot of reasons you could do that. One of them is just that people are inherently bad at safekeeping stuff. So where are you keeping your 12 words or your 24 words? I'm not going to ask you, right? But it's probably not very safe. It's probably not very safe. Could someone have access it? Could someone access it? Maybe right now when you're at the conference, right? Maybe someone is at your place and looking for this. If they find it, it's game over for you. You lose your money, right? Now you can just have that. If they find it, well, they have a piece of paper with words on it, but nobody can spend money from it unless you stop using your wallet for a year, right? So the cool thing about that is that you can use something very basic like Tamper Evident Bag. So as long as you check from time to time, you go back home after the conference, you just check that nobody opened your Tamper Evident Bag, you know your funds are safe. You know that nobody can steal your money. And this is super cool. It's very different from just keeping 24 words somewhere and just hoping that nobody finds them, right? Very basic use case. And I think that should be the default in every wallet right now. Of course, it doesn't have to be no backup of the primary wallet. I'm just abusing a bit here. You could have a very, very safe backup of the primary wallet. One that's like extremely hard to find, extremely secure, but you have like more accessible ones that are Timelocked just in case something happened, you know. To me, that's a very good option and potentially that's like the future that every default wallet will have.

You can play with some weird stuff here. So for example, you have things like OpenDime where you don't have the private key by default, right? That's the point of OpenDime. So you have an OpenDime, so it's like a small device. You OpenDime, you can put some coins on it and the only way to spend from it is basically to destroy the device. It's signing a transaction or it gives you the private key and that's it. You use it once, right? If the device dies, you lose the money. It's gone. You have no way to recover it. So you're completely trusting that the device will survive before you actually want to move the coins. You can completely imagine that the OpenDime after, I don't know, 10 years, in case the chip dies, you know that there is an exit pass after 10 years, right? But you assume that somebody will already have used it before that, so it doesn't create any kind of way to extract the money outside of the OpenDime. It's just like a recovery pass just in case. You can also see HSMs, which are like machines that sign transactions. You're not supposed to have a backup of the key of the HSM. That's the entire point. It's supposed to be in an enclave and not accessible, right? So now you can have exit pass basically in case your HSM dies or refuse to sign or whatever. After a long time, you could be able to have another pass to spend the money or to recover the coins. You can also start playing again with things like brain wallets. You shouldn't do a brain wallet of your coins if you don't have any backup of that. So a brain wallet is when you decide to memorize your words. You don't write them down anywhere. You're like, you know, your money is in your head. Very good. If you lose it, you lose it forever. Well, not anymore because now you can have a brain wallet, but just in case you really fuck up, you know there is a thing that you can recover maybe in a few years. So pretty cool as well. Password protected wallets, same thing. If you have a password on top of your seed, if you don't backup the password, you have a risk of losing it. So why not having an exit pass again after a long time just in case this happens so you don't fuck up?

OK, another idea. You could just move from a single SIG to a multi-SIG. Some people have been talking about social recovery for wallets. So that's an idea I don't really like, but anyway, I can talk about it. So social recovery is like if I fuck up, I can ask a bunch of my friends. They might not know about each other, but if I have enough of them or enough of their keys or shards, I can recover my funds. When you do that, currently, you also have the risk that they actually find out about each other and they collude against you and they steal your money. With a Timelock, they can't do that. As long as you don't lose your key, you know there is absolutely no risk that they even think about colluding. So you're pretty much sleeping well at night. You don't have to think, oh my God, are they still my friends? Whatever, you don't care.

That can also be services. It doesn't have to be your friends. You could pay different companies to be available when that happens or if that happens. Again, you don't have to think, oh my God, I don't know, there is the FBI trying to seize my money. They are going to talk to all the companies and force them to sign a transaction. No, they can't. Not before the Timelock expires. This also reduces the risk for the third party because now the third party is not at risk of being threatened because they can't spend your money. So it's very different. When you give a key to someone else, they now have the responsibility to safe keep this key for you. That has a cost. If someone put a million dollar or a billion dollar on a key that they share with someone, this person now has a target over their head. So having a Timelock on top of this also reduces the risk for this third party.

Decaying multi-sig, you might have heard of decaying multi-sig. It's a concept where you can have a very strict multi-sig instead of having a threshold. So you can have something like a three of three that after a long time or whatever time, become a two of three in case someone loses a key. Why not after that become a one of three? So as you can see here, it's not just one Timelock. You can have as many as you want. You can have a Timelock after every week changing the conditions. So you can do really cool stuff. And again, this is not custom scripts. It's just you define your policy. You can import it in core. You can import it elsewhere. It works. You can also have something a bit different from decaying multi-sig where you add extra keys. So if you don't want to reduce this threshold for different reasons, you can actually add a key that's going to become valid after a specific amount of time. So that could be, I don't know, a solicitor, attorney, right? Maybe you would then add another key that's in a safe in the company. But these keys are not valid before the expiration of the Timelock. So this is not the same as having a three of five here. Just a three of three that if there is a problem, become a three of four, that if there is a problem, become a three of five.

And again, you can have, of course, escape hatch from third parties. The way it works today, typically you have companies like Kasa, Unchained, BitGo, whatever. There is quite a few companies that are offering you a service of being a cosigner. So they're going to enforce policy on your behalf when you try to spend money. But at the same time, they don't want to have the risk, or you don't want to have the risk with them that if they disappear, or if they fuck up, that you lose your money. So the way they do it today is basically a two of three, where you have two keys. One of them is like your very safe backup, so really hide it very well. You're never supposed to use it, except if the provider has a problem, and then you know, okay, it's fine, I have two keys, so I can spend. A problem with this technique, when you don't have any Timelocks, is that any attacker that knows you're using these services, they also know you have access to enough keys to bypass the service. So using the service in the first place is not enforced. So if I'm a very bad person, and I know you're using a service like that, I can just threaten you. I know you have two keys. I don't know where they are, but I know you have two keys, so I don't care about threatening the service. They are not necessary in this transaction. Now, with Timelock, you can actually enforce that. You can have it a strict two of two. I cannot bypass the cosigner. The client doesn't have two keys. But if the cosigner, you know, lose their keys or disappear, then you can have, you know, Timelock happening and something else happening. The something else could be decaying, so that could be just you having a key, but that could be a risk. Maybe you don't want that risk. As we were saying, you know, it's a risk, a physical risk. Maybe you want to add the key of another service provider there. So let's say you have a key at Unchained, Unchained stopped replying, now you add the key after the Timelock of Kasa. And if Kasa is also not there, you can add another key of another service provider, right? So you can do really cool stuff about escaping services without you necessarily being able to bypass them, right? I don't know. Are you following? Cool! I hope you're going to have ideas I didn't get, right?

You can do a reverse hatch. This one is one that we find very, very cool. So, yeah, a little bit of a spoiler alert. I think we're going to try to monetize that. So, yeah, this is basically why people are still using custodians. They are afraid they may lose their key. They don't want the responsibility of keeping their key. But everyone knows it's really cool to be, you know, your own custodian, to have self-custody, right? So why not both? Why not being able to have people have full custody of their coin? It's their own key, their own coin. But if, and only if, they really fuck up and they lose their key, and they lose their backup, and they lose everything, they still have this panic button of like, I forgot my password kind of thing. Where after a Timelock, the funds are actually entering a custody. So they're actually becoming spendable by your trusted body. I don't know, you can think of, again, you know, the Casa, the Unchained, whatever, without Sardine. Whoever, right? So you can imagine that this third party doesn't have your coins, only if you lose everything and you really fuck up. So this Timelock, you know, is a relative Timelock. As long as you keep using your wallet, as long as you still have your keys, we never have access to it, right? It's only a service in case you really fuck up. And, I mean, this is a game changer. I think this is really a game changer for anything related to self-custody. Now it's not choosing between self-custody and, you know, having some risk, or using a custodian and giving them all the risk for you. You can have something in between where as long as you, you know, as long as you don't fuck up, you are absolutely in control of your coins.

It doesn't have to be a third party, of course, and we all have done this kind of stuff where basically you're trying to onboard your Mom or your family or someone in your family. As a Bitcoiner, you probably have done something like that. You're helping them set up a hardware wallet. You're helping them set up everything, but in the bottom of your heart, you just know they're going to fuck up. So you keep a copy of their mnemonic. I'm quite sure there is quite a few of you that have a copy of a mnemonic that, you know, you're not supposed to have, but it's just there just in case. So why not have, you know, give them a little bit more, I don't know, trust or hope. You give them full custody of their coin. They should, right? Only if they really fuck up and after a long time, you know, if they come crying to you that they really fucked up, you know, you can help them. So this kind of stuff, we can really do it.

This is just a screenshot. [audience question] Yeah. It can be two out of three of different providers as well, so you don't have to trust a single third party. It's a composable thing. [/audience question] Yeah, yeah, yeah. You can definitely have multi-sig as well, like in the previous escape hatch. It doesn't have to be a party. It doesn't have to be a third party. It could be anything, right? This is just a screenshot of what Liana looks like right now. So Liana is this wallet that deals with Timelock, miniscript, everything, descriptors. This is built for Timelocks, right? So the UI is a bit different when you set it up, when you, you know, turn it on the first time. That's what it looks like. But then when you use it, it's a normal wallet. It's just, you know, receive sends. You don't have to think about Timelocks. This example here is a pretty complex one, actually. I should have done simpler. But anyways, imagine that I want to have spending policies using an HSM, so a machine that, you know, enforce the rules I set with it. Let's say I cannot spend more than, I don't know, 1,000 euro worth of Bitcoin per day, and the HSM is going to enforce that. I don't want to be able to bypass this because I'm technical enough, and maybe, you know, I really want this new computer, and it's 2,000, and I would just go find a way to bypass it. I don't want that. So instead, this is a 2 of 2. I want to enforce it that the HSM has to co-sign transactions. But at the same time, this is a machine I don't have a backup. I don't have a way to bypass it, so I need a way to, you know, if it dies, to go over it. And why not also have a way that, you know, if really something happened and I lose my keys, it would be cool maybe that I can recover my coins. So in this case, I put a Timelock of about a year, and I add my mom to a multi-sig. This one is a 2 of 3 threshold. So what this means is that if the HSM dies, I can just go see my mom after a year to, you know, recover my coins. If I lose my money and the HSM didn't die, well, I can also go see my mom, and she can sign a transaction with the HSM and recover my coins. If I die, my mom can also go sign a transaction with the HSM and recover the money. So it's pretty powerful, and I cannot bypass it before waiting a year, right? So this kind of use case are possible today. This is just a few clicks, and it works. And this descriptor, you can import it in core if you don't want to use Liana, whatever.

That's basically it. So I wanted to say that to me, 2023 is really a very big change in what we can do with Bitcoin just because of this, of this Miniscript stuff. Yeah, just set up a thing. It's a few clicks. You have your descriptor. You can import it wherever you want as long as, you know, the wallet you import it has descriptors. And hardware wallets now support it. So we're good to go. Just try to think about what you can add into your wallets, or what do you want, because people can build it for you. And we can make Bitcoin so much safer and so much, like, error-proof than it was until today. To me, like, this is a massive game-changer. So thanks for everyone that worked on Miniscript, integration in hardware wallets, libraries.

Thank you.

MC: Great talk and a lot of nervous laughs there from people you all had in mind, didn't you, when you were mentioning the who else has that seed phrase. So that was quite telling. Go to the questions here.

Q: So what you were describing with these Timelocks, assuming they don't use some sort of covenant scheme or some sort of deleted scheme pre-sent transaction thing, like, you need to rotate your UTXOs from time to time. So does Liana already do that automatically for you? Or, like, does it tell you you have to come online every now and then and have your hardware wallet ready?

A: Yeah, very good question. Okay, so the question is about how does the Timelock refresh itself? So we are using, in Liana, we're using OP CSV. So the one that's relative to when the output was, you know, mine. So the one you want to spend was mine. So if you don't move your coins, sure, the Timelock is going to expire. So you need to keep using that to use your wallet normally, right? It's a UI problem. It's not a script or covenant or pre-signed transaction problem. I mean, it could be, sure. So this is not to use as, like, your long-term saving wallet because the OP CSV, as I said, is just over a year. So you need to at least spend once a year, right, to refresh your Timelocks. In terms of UI, that's one of the things that is going to be a differentiator between wallets in the future because Miniscript allows you to do really weird stuff. And the wallet, the person that builds this wallet doesn't, like, cannot think of every use case that people can do with Miniscript. So the wallet, from a technical perspective, will be able to spend if it's compatible with Miniscript. So it will understand how to craft a transaction and spend it. But it might not be able to display you, you know, all this information about what the script is actually doing, right? So in Lyana, you have a counter, basically. It's showing you the number of blocks since—how many blocks are left before you go to the second path. So when the Timelock expires, basically, you have a counter per UTXO telling you, you know, getting read if you're getting really close and you should really rotate your coins. We don't have automatic rotation right now, but it's going to come in the future for sure. Yeah, I think that kind of answers your question, right?

MC: Yeah, good. There's one question here.

Q: Hello. Last time I checked and I wanted to implement this Timelock in the Bitcoin wallet. As I understand, I need to, as well as the—to back up it, I need, as well as the mnemonic seed, I need also a Timelock for this transaction. How do I solve this UX problem?

A: So you mean, what do you need to back up, right?

Q: Yeah, I want to restore the wallets that have this Timelock transaction.

A: Okay, so in any Bitcoin wallet, you need two things. You need the private key to be able to spend the money, or the private keys, or the secrets. And you need to be able to find the coins you want to spend, right? From a UI, UX perspective, I think it was a mistake, but anyway, over time, there's just like—the main type of wallet that people are using is a single SIG. You have one key, so you have one mnemonic you save, and that's basically it. So the way the wallets are working today is that the mnemonic you have doesn't contain any information about how to find your coins. That's crazy. You have the private key, that's all you have. So now it's up to your wallet to guess where your coins are. So the way it works on a normal wallet is that it's basically brute forcing the most common path. It's trying to figure out, you know, is this guy using SegWit? Is this guy using TapRoot? What is he using, right? We don't know. So the wallet is brute forcing that, and that's how it works. And I think it's pretty terrible. But yeah, so anyways, that's just why we don't have more information to store today. It's because we're leaving it to the wallet to try to brute force and find your coins so you can spend them. But you should always have a map of where your coins are, and that's what we call a descriptor today, an output descriptor. So typically, if you do multi-SIG and stuff like that, you already should be aware of output descriptors. And basically, Miniscript is doing the same, right? So any type of wallet using what we're doing, like Timelocks here, it gets you an output descriptor. I didn't put one on my slides, but if you were to the, you know, the Miniscript talk this morning or things like that, you probably have seen some. So it's, you know, a bunch of kind of, I don't know, like characters explaining how to find your coins. So if it's a multi-SIG, it's going to say it's a multi-SIG. Here is the first pad keys. Here is the second one, right? So you need to back up two things. You need to back up your mnemonic. You need to back up your descriptor.

Q: Do you think it's time for new mnemonic SIG standards?

A: I don't think so. I think people just, well, the mnemonic is a shit show as well, but I think it's just about people to understand what they are backing up. The descriptor is how to find your coins. And then you have the secret material, which is basically your private keys, no matter what format they have, right? If it's a mnemonic, if it's another kind of private key export, it doesn't matter. You need to find your coins and you need to be able to sign them. It's two different things and we need two things all the time. It's not a new problem is what I'm trying to say.

MC: Awesome. I think we had one quick question at the front.

Q: I shouldn't have forgotten it. Wait, so yeah, that was it. So, okay, so let's say you've got one set up where maybe like I have access to the Bitcoin and then after a year, somebody else, my mom has access to the Bitcoin or something like this. Then I guess both of us need to have this descriptor back up. Does that allow the other person to see your transaction history and everything even before?

A: Yeah, so the descriptor is the map to your coins. It is not the same type of like secret material as a private key, but it does completely dox you because it shows all your coins and so all your history, right? It's kind of like the same problem as an expert, if you want.

Q: So if you do key rotation or like, does the descriptor change every time when you do that?

A: No, no, no, that's the point. So the point is the descriptor is how you build your wallet. And then, you know, all the change address and everything is just respecting this, right? So you don't have to think about that. You don't have to think about Timelocks when you're using it. It's just the first time you set it up when you define what your wallet is. So that's when you create your descriptor that you set your Timelocks and everything, and every transaction you receive, every transaction you send when you get a change is using the same thing. So it's just one descriptor, you keep it, and that's it.

MC: Awesome. Can we squeeze in another question? I think we can.

Q: Well, this directly follows this. So your mom is one thing, but how do you hide it? Do you have any ideas from how, do you have an idea of hiding the descriptors from Mr. $5 wrench? Because it's nice to not give them that information. Do you think like maybe you encrypted using each of the private keys, you encrypted descriptors and put them somewhere?

A: In terms of like $5 wrench attack, I don't think it's really a tool against that. I really don't think it's the focus. But in terms of being able to store and replicate these descriptors, yes, you can encrypt them. And if you encrypt them with all of the keys, then you know that it's not lost. Because basically you need a key to spend. So if you assume that at least one of the keys is still there, then it can decrypt the output descriptor. And so, yeah, the descriptor can be backed up in like the cloud. It's better if it's encrypted so you don't have the risk of leaking information. But then, yeah, if you encrypt it with all the keys, you know you're good.

Q: Quick follow up. So I guess this is also interesting in the case of these custodial providers that you use as your last cause backup. You don't want them to be able to follow you unless you actually need them. But then they should be able to get that descriptor somehow but not have it earlier.

A: Yeah. But see, my mom is not that far from that because I don't want my mom to know how much Bitcoin I have.

Q: But she can't use the descriptors.

A: What do you mean she can't use the descriptor? Yeah.

Q: I don't know how good your mom is with Bitcoin wallets.

A: So, yeah, no, but basically I can just basically share this descriptor with someone else. It's not that I don't want to share any secret material, just this descriptor. It could be encrypted with my mom's key. And as long as they don't collude, my mom has no idea how much money I have. She only needs to be able to access it when I die, right, which is pretty cool.