Why Bitkey Ditched Seed Phrases | Clay Garrett SLP778

0:00That mindset to me doesn't feel like they're out there really talking to customers. In the wake of the cold card incident, there was a few different podcasts. I listened to with kind of leads within hardware wallet manufacturers. And a lot of times the conversation was just, well, we should have made this more secure and therefore less usable. And we should just trust customers more and they'll figure it out. Hi, everyone. Welcome back to Stefan Lavera podcast. Joining me on the show today is Clay Garrett. Clay is lead at Bitkey from block. Welcome to the show, Clay. Thank you, Stefan. I appreciate the opportunity to be here. So Clay, let's get into Bitkey and talk about the model, how it works. You know, what you were thinking about the design of it and the security of it. Obviously recent conversations around security and self-carsity. But yeah, I mean, maybe just start with a bit of an overview on the Bitkey product. I know you had an earlier version and then the V2 of Bitkey, which has a screen, came out was April this year or earlier this year, right? Talk to us a bit about that. Yeah. Yeah. It came out in April at Bitcoin Las Vegas. We launched it. Yeah.

1:00So first of all, the, you know, with a new release of the new Bitkey, the system itself didn't change. There's some significant things that changed about the hardware itself, which we can talk about. But, you know, Bitkey is a two of three multi-sig. So that means, you know, you need two of the three keys together to to sign and spend it in a given time. So the three keys are blocks key. So that we have one key and then you have two customer keys, one on the customer's phone, one on the Bitkey itself. So because you need two or three to spend, we cannot spend without you and you can spend freely without Bitkey. And so, you know, they kind of create some interesting options for both recovery and, you know, spending without your hardware if you, if you so desire, which happy to get into the details of that. But we were just overall looking for a way to solve some of the pain points that we heard a lot from, from customers as we were digging into this about their self-custody setups. And one notable thing that people may or may not be aware of is that we actually don't export a seed phrase. So the entire system does not require you to write down anything, to remember anything new.

2:04We use things that are, you know, already in your life, including, you know, like your cloud access, your phones, your fingerprint that you always have. And so, you know, we kind of, you know, bucked some things that were, you know, part of traditional self-custody in doing this. But it opens up a lot of value that is, is hard to get in other types of setups. Yeah. And I think we should talk a bit about that because that makes me kind of remember this point because obviously with the cold card thing, everyone was spooked about entropy and then it became all about like, oh, yeah, you got to get your dyes. And, and to be clear, I've been an advocate of dyes rolling, you know, but I think it's important to step back and understand base rates here because most people lose money or at least in Bitcoin, and they've lost money because of losing their backups or kind of losing access to their coins, rather than an entropy vulnerability as catastrophic as the cold card one was. So do you want to just touch on that a little bit and how that plays into your design and the thinking of Bitcoin? Sure. We use a term a lot called safety and we sort of combined security and accessibility,

3:10you recoverability all into one term that's essentially the thing that matters overall to, to customers, which is, you know, do I have access and am I going to lose access to my funds in any way? Right? That could happen because of threats where, you know, our security posture matters a lot, but it can also happen because of everyday life. If, you know, if you're tasked with managing the life cycle of the seed, then, you know, that's something that now you have to take care of as well. And so, you know, I think security is an important part of it, but we talk a lot about safety because of that. It's, you know, sort of the, the holistic view of the system in terms of how likely you are to actually retain control of your funds. Right. And I think there's all these tradeoffs around, you know, how the product is designed. So let's just talk a little bit about the, so you mentioned the two or three model, right? It's in that one key in the, you know, the Bitcoin device, the physical device itself, one in the phone and then one in the, the block server or Amazon web services, Nitro server or enclave. When are each of those used?

4:11So primarily a customer will probably use the, the two keys that they own. So that's the at key and the harbor key. In that case, block is completely uninvolved. You know, our server does not do anything as a part of any transaction like that. In fact, the, our default electric server, which actually, you know, use it, the phone uses to go broadcast the transaction to the network. Those are actually not even run or owned or accessible by block. We use third party providers for that. So that, that is sort of an important property to make sure that, for example, if block were to go out of business, we're not in the way of you moving your funds. Now the other common combination would be the app key plus the server key. Primarily, that was built for recovery scenarios where if you lose one of your two keys, that's okay. Like we're going to help you get back in business. You know, Bitcoin is really built around layered security and no single points of failure. So if you were to, for example, lose your hardware, what you would do is, you can, you know, buy a new hardware, start a recovery period where we essentially for seven days,

5:15the Bikki servers will notify you at every touchpoint we have for you. So push notifications, email address, your, your SMS will say, someone is trying to recover your account. If this is not you, go, go to the app and hit cancel. And then that, that recovery will be canceled and we won't sign, you know, on, on your behalf. If the seven day passes, seven days passes and, and we don't hear from you, you don't cancel it. We assume that it is you and, you know, good faith we go ahead and, you know, sign the recovery transaction, which moves the funds from the old key set, which you've lost one of the keys of to a brand new set of three keys that is established with the new Bikki hardware that you bought. So you're back in business in the inverse. If you lose your app, and for some reason you don't have your cloud backup, you sort of do the same thing. And in verse, you just, you use your hardware key and then the server key to sign into a transaction that moves it to a brand new set of three. There's also a feature that you can turn on. It's not on by default, but it's called transfer without hardware. And this is, you know, a feature that, you know, some customers just really, really love a lot and depend on, which is they don't have to have

6:16their, their Bikki at home, for example, if they just want to do, you know, daily or weekly spins, you know, under a certain amount. So if you turn that on, you can say, I want to be able to spend X number of dollars, you know, in your local currency per day. And then the Bikki server then acts as a policy signer. We make sure that, you know, we're tracking the amounts that you send under that policy. And this way, if you were, you know, let's say that you're traveling, you don't want to bring your Bikki with you, but you want to be able to use Bitcoin while you're traveling. If someone were to snatch your phone while you had it unlocked and open up the Bikki app immediately, you know, while they run away, they're only going to be able to get whatever you have set as that daily limit per day. And then you would be able to then go recover. And as soon as you recover, wind up locking them out of access and, you know, in the end, the sort of maximum exposure you would have as seven days worth of that daily limit. Again, that's an optional feature. You don't have to turn it on, but, you know, a lot of customers really love the flexibility of that. I see. And so then in that example, what's going on is when that customer originally set it

7:17up, he's got his, you know, his Google or his iPhone and he's got his app phone key. And what you're saying there is at that point, if he, if the customer has, you know, somehow lost his phone, he has to go get a new phone and then sign into either Google or Apple. And then that's where it's going to pull back the key down from the Google cloud or the Apple cloud and then decrypt it and then have it again as a live phone hot key per se. Exactly. And when you do a cloud recovery, so like you said, we pull down that payload from the cloud. It isn't, it is encrypted by the hardware, as you mentioned. So if somewhere, where to just get access to that payload, but did not have your unlocked hardware, it's useless to them. The hardware will decrypt it. And at that point, we actually give you the opportunity to sign out any other devices. So if you at that point would say, yes, now the attacker has your phone, you know, for some reason, they would be able to keep it, you know, from locking this entire time. They would now not be able to communicate with the big key servers anymore. I say so at that point, you're doing, you would buy a new phone and then tap it with your

8:19existing bit key device. Right. Exactly. And then at that point, then you start the transition over to recover in that, is there, is there still, so that's where there's a seven day timer in that, in that scenario? Actually, yeah, as long as you have your hardware and access to your cloud, there's no delay period, right? So it would be an instance wallpover. Right. Right. Because at that point, you have your hardware key, because you used your hardware to decrypt the backup and then after you decrypt it, you have your app keys. So you have your two keys. That's all we, you know, as long as you have that, we believe you are who you say you are. And we don't require a key set rotation at that point. You just, you sort of lock the other attacker out because for them to access your funds, they need the server to cooperate with them. And we essentially invalidate their access token and the server just won't talk to that device anymore. I see. Okay. And so I guess the other scenario you were talking about with the seven day delay is if you have only access to buy a new phone and sign into Google Apple, but not your device because maybe it's in another country and you can't get there yet that kind of scenario or right.

9:22So if you've lost your hardware, that's the, the, the, the, the, that's not a whole scenario, right? That's the whole thing that I described. The, the other is if you only have your hardware and for some reason, you lost your, your Apple password, like you actually couldn't get back into your cloud and you only had this, you now only have one key. And anytime you only have one key, we require the seven day delay to then sign a sweet transaction to move you to a brand new set and create a new key for you. So anytime you're able to access both keys, there's no sweep or seven day delay required. Anytime you have permanently lost one key, that's when we make sure that, you know, we want to make sure that you are who you say you are. For example, like let's say that someone just, let's say you had a room, an evil roommate, they waited for you to unlock your bit key and then they took off with it, right? They only have one of your keys and we do not want to let them immediately recover because we want to make sure that you have seven days to prevent that recovery. So that, that delay period would be there. And so yeah, and then, you know, the inverse, which is the much less common is when you've lost

10:25both your phone and your cloud. So you can't do the typical cloud recovery, you know, you just, you just have your hardware. And then that's, that will also create a seven day delay period. I'm curious then, in that evil roommates and artists, I mean, you've got to quickly run and buy a new bit key device and get it within the seven days. Well, they can't do anything with just your unlocked device, right? So they have to, yeah, they have one of your keys. They don't need to be able to log into your bit key app, right? Exactly. Exactly. Which they can do if, you know, if the seven days goes by and you haven't responded or cancelled, you know, any of our, at that point, probably 30 or 40 notifications do you that someone's trying to recover your account. But yeah, that's far we haven't, we haven't heard of that happening at all. Gotcha. Yeah, yeah. Yeah. All right. And then, okay, yeah. So I guess the point here is we're getting into like, there's a lot of ways to recover your coins. And for people who've been around for Bitcoin a while, they know that, you know, a lot of people, maybe if they're not as serious about Bitcoin or even people just who are serious about Bitcoin and make a mistake, they lose access to their own coins or the common

11:26scenarios we hear are like family or friends who maybe they install some malware or type in their 12-word seed into, you know, a malware or the wrong kind of online connected computer and then, you know, boom, the money's gone. So there are those scenarios. I want to be fair. That's, you know, that I think this system helps you protect against that. But maybe the downside then would be that there's elements of like somewhat of a vendor lock that exists here. So to be fair, like you get certain trade-offs of this, you get better recovery, you have like this inheritance system that's in there. You are not as reliant on one piece of hardware per say, but then there's a bit of a vendor lock. Is that how you see it? What do you think about the vendor lock? Do you think like it's a justified vendor lock? Is that how you would explain it or what do you think? First of all, I would say there's no intentional vendor lock. It's, you know, and I think in the future, you know, probably probably look back at, you know, this time and say, oh, remember, you know, when Bitcoin was, you know, had vendor lock-in, the reason that that exists today is that the design decisions

12:31that we chose were just very non-standard in the industry, right? The system heavily relies on hardware being able to perform certain, you know, decryption and encryption operations, which are not common, you know, amongst hardware wall vendors today. I think, you know, we're hearing more and more about certain vendors, you know, exploring this and I think maybe even one or two implementing it in specific ways for certain reasons. But at the time when we developed it, you know, we were, I think the first ones to do this. And so then there's also the element of not exporting seeds. And so I think I can see a future where the Bitcoin system is more of a protocol where, you know, anyone that wants to develop for this protocol can do so. And then the parts become a little more interchangeable. We've definitely talked about that in the past, you know, whether that being someone else implementing their own Bitcoin style server and, you know, maybe implementing certain additional features on top of it or, you know, being able to bring in

13:32other hardware wallets into the Bitcoin ecosystem. We're actually looking pretty intensely this year at trying to, you know, see what third-party hardware support would look like. For example, if you wanted to have one Bitcoin hardware and then one, you know, treasure ledger, whatever, hardware wallet as a replacement for the app key. Wait, what would that do to the system? You know, it would, I think give certain benefits that people are looking for with maybe only very light tradeoffs on the other side of it. So I just want to make sure it's clear that the ethos of Bitcoin is not, hey, it's Bitcoin or nothing. It's just that we felt like this design needed to exist. And it's a lot easier to, you know, be a single vendor putting out all the pieces necessary, then trying to launch a product that requires on seven different companies all agreeing on the timeline and building something, you know, that hopefully the market accepts. And I think now we've shown that the market definitely is very interested in the Bitcoin style concept. And I think we've even seen more companies push towards this direction, which we're excited about. Like, we're very

14:34much, hey, you know, we want to be a team player in this environment and open standards do matter to us. In fact, the chain code delegation, our privacy feature, which we might talk about later, we wound up creating a bit for that and got, you know, the bit accepted and hope that others, you know, start building that type of privacy feature into other wallets as well. Excellent. Okay. Yeah, because I guess that's also the other kind of question that comes up on some of these discussions is, you know, in the wake of the code code vulnerability, entropy vulnerability, there was a lot of discussion around multi vendor multi-seag. And I guess that's maybe one of the areas where Bitcoin feel at least currently now to be fair to you, it sounds like you're actually looking at ways to sort of go to advance that. But it seems sort of feels currently more like single vendor. Now, yes, it's a key, it's, you know, a hard-working phone key and a server key, but the software to manage it is all written by, you know, by Bitcoin or by block. And so I guess, but I guess to what you're saying, then theoretically, if you did have a possibility of having a non-bit key as part of the

15:41quorum, then you would have multi vendor. Right. Yeah, that's true. And, and, you know, I think the multi-vendor conversation that, you know, I think just gained a lot of steam after the cold card incidents, not like it started there. I think it's directly correct in terms of the way that people should be thinking. But, you know, one, one nuance that I haven't heard a lot is, you know, let's just sort of take a theoretical example of three vendors, maybe almost like a Goldilocks style. Right. So imagine you could look under the hood and you could tell that vendor A just, you know, had the best security. Vender B, you know, it was great at some things, maybe not so good at others, and vendor C actually wasn't that great. But they all talked a great game, you know, they, you know, companies or companies are going to advertise, you know, as though they're the best of the things that they're, you know, purported to be. If you started with two hardware wallets from vendor A, and you go, okay, I really need to go multi vendor, and you wind up choosing a hardware wallet from

16:41vendor C, you've actually decreased your security. And that's, I know, it's not a real world example, but it, you know, it just has a thought exercise that it's not that multi vendor automatically increases your security. It very well could, if you'd gone the other way, if you had started with two wallets from vendor C, and then you added one from vendor A, you've done exactly what you're trying to do. And so I just want to make sure that I don't want, you know, us to fall into a trap, you know, in the industry at all, is, you know, thinking that just by, you know, adding more vendors into the system, you're automatically gaining more security. I think we need to really understand what, what you're getting. And then another element that is at play here is that depending on the design of the system that you're putting together, enough you're looking at multi-sig with a couple of harbor wallets. If those harbor wallets that you are basically entrusting to securely generate and store a seed for you, if the first thing that they do is show that seed to you on a screen and say, cool, now you go manage it, you're kind of adding in a, a fourth vendor, right? You've got your two harbor wallet vendors, your software wallet vendor, and now you're sort of becoming a security vendor,

17:43where you may not be an expert in that. And, you know, are you going to be capable of, of securing a seed against all the things that might happen for your lifetime, you might be. Like some people are actually really great at this. And, you know, I'm glad that we have options that allow people to do this. But I just want to make sure that we are always aware that it, there's always a tradeoff in any of these. And we, we need to look at both sides of the tradeoffs. And that's not me saying that, ah, therefore, single vendor is the solution. That's not what I'm saying. But it's also not saying that multi vendor is automatically the solution needs to be really well thought out in terms of, you know, what tradeoffs you're making and what you know about each of those vendors that you're choosing. Yeah, I guess so. But I think it just comes down to fault tolerance is kind of the, like, if I think back to kind of the Michael Flaxman sort of message from what's like six or seven years ago, that was probably the main point is the main point is by choosing these different methods, you can give yourself at least one chance that, you know, something can go wrong and you still

18:45don't lose your coins. And I think that was probably the, the spirit of it. And I guess to your question around kind of company A company B company C, I guess the point is we don't know in advance, right? Because we don't know like if you knew that, okay, company A, the best one, maybe it would make more sense. But the problem is these vulnerabilities can be hiding anywhere, right? Like in the cold guard case, I'm sure many security experts were looking at the cold guard stuff and it didn't get found for what five years, like ledger, if ledger Don John didn't find it and they've got this, you know, amazing security team, if they didn't find it, I mean, what chance does, you know, any normal person? Yeah, I think you're exactly right. And I think that in the limit, you, you say that, well, surely this isn't going to happen to all the companies all at once. And I think that's probably true. And so it's almost then, okay, well, the more that I add, the better. Okay, so now I've got a three of five or a five of seven. Okay, but now you have five seeds that you have to geographically distribute. And again, it's just putting more, you know, burden back on the end user, which is

19:47something that is, I don't know, I just don't think we talk about enough, right? Because any given, any given customer is obviously very, you know, trustworthy to themselves. Like they're, they're not going to go rug themselves, right? But it's sort of like what they don't know, what experience they don't have that really, really comes into play and is sort of the root of why we designed a lot of the things the way that we did at Bitkey. So it's just, it's just a matter of where you're pushing. It's like, you don't get any sort of, it's a zero sum game in a lot of ways. You don't get any, any freebies by distributing it more. You're not just automatically getting more safety. You're putting more on yourself in the end. Yeah, I mean, in simpler terms, it's like you can make yourself more fault tolerant, but you pay a complexity price for that. Like you have to, you know, it's not a free launch, but I think for people securing, you know, very large amounts, it's, it's probably worth your while, you know, right? That's probably where it is more relevant for them. And so I guess

20:49on that question, let's talk a bit about that. Like obviously, you know, the marketing from what I see is, you know, this is self-classity for normal people. And I'm in favor of that. That's a good thing. You're making it simple for people, right? To the complexity point. But is there a point above which you would say actually this two or three bit came model is not the right one for you like above that level. You should, you should be looking at something else or how would you, how would you answer that? Like who is a lot of know for? Yeah. Yeah. I think it's a little bit like asking, like saying like, what's the right car for a car enthusiast? Like it just depends so much on the individual situation, right? You know, it depends on how willing they are to learn about the areas of operational security that matter for their scenario. Do they have a complex inherent in setup? Are there family members technologically savvy? The ones who who might need to inherit their funds, for example, what, you know, a certain amount to one person might be something that they

21:50are willing to trade ease of use for, you know, whatever they believe the negative side effects of a given solution might be. And so, you know, we definitely do market a bit key to, you know, normies, but not exclusively by any means. You know, I think that bitkey was so easy to use at the beginning that it really sort of became the narrative externally that that's who we are. More and more though, we have really leaned in after we started learning who our customer base really was. We've leaned in on making a product that works for the Bitcoiner, right? For someone who already has a harbor wallet who is unhappy with, you know, their current setup or just want some diversification, wants some peace of mind that if their elaborate setup, for example, has some flaw that they mess up that they're not losing everything, for example. And some people have actually moved their, you know, have shared that they moved their full stacks to bitkey. So, we are designing bitkey to be worthy of that. Like, that is definitely our intent while not

22:56sacrificing the properties that make it great for a beginning person, you know, someone who's like just moving their coins from exchanges, for example, because we do believe that was a sort of big gap when we started building in terms of the space. You know, and this one more other thing that I would share in terms of the multi vendor story is when you're putting together a multi vendor setup, you're in many ways putting together a system that's probably pretty unique. There's so many options to choose from. There's so many wallet providers. There's, you know, kind of the recovery and coastsigning services like bitkey, like Kasa and Unchuk, Unchained, etc. And, you know, I'm not aware that there's any of those companies are continuously, for example, running integration tests across all of those possible combinations, right, to make sure that the systems that you're putting together are battle tested themselves. Whereas, you know, the flip side for a single vendor solution like bitkey is we have 300 integration tests running every day on our servers that

24:01make sure that the server integration is exactly what's expected with the app integration that the hardware works just expected, etc., etc. Not that that's a silver bullet, by any means, but I think it's just it's important to call out the some of the benefits of single vendor because so often we just hear single vendor bad, multi vendor good. And, you know, we we just like to approach every conversation in the design space at bitkey with a lot more nuance than that. And that's one of the the things that have really come out of that conversation is that there are like a lot of great positive trade-offs for the, you know, the downsides of any single vendor solution. So I think to answer your question, it's it's really down to what matters for the individual what their individual belief systems are. For example, I would say if you're someone that thinks that the average corporation is, you know, out to just, you know, rug you or screw customers for the benefit of profit, bitkeys probably not a great option for you because you're sort of putting all your exit one corporate

25:02basket. If that's your your world view, I'm not here to like try to change that. It's just that like that would clearly move you away from something like this. And I'm sure there are other world views that would also do that. In the end, I think I personally would recommend a diversification of something, you know, like there's a lot of great value from from a single vendor solution. There's a lot of great value from a multi vendor solution from a custodian for a portion of it. So we're definitely not a one size fits all kind of shop here in terms of the way that we, you know, propose our customers think about things understood. Yeah, now I guess another, I mean, maybe this depends on where you actually keep the physical bit key device. But I think one thing from a multi-seag perspective is one. I mean, it's kind of unfortunate nowadays with all the, you know, crypto kidnappings and things, especially in France and other countries. But one thing that, you know, if you have a decent stack that you're trying to protect, you're worried about like wrench attacks or like an armed robber at

26:03night kind of situation. And if you had, you know, I think one example of like having multi-seag, but the keys in different locations where maybe if you have a key at your home, you only have one key at home. So that way you can't spend, therefore, you know, if the hypothetical armed robber is gone to the head, he can't take your coins, at least in that scenario. How would work in a bit key scenario? I used like, would you, like, how would you make that work for a bit key? Would you, like, if the user has, you know, his phone at home and, you know, at his bit key in like a home safe, or maybe is the answer that, you know, you would, in that scenario, you would want to keep the bit key device in another location. Is that how you would solve that? Or what do you, how do you answer that? Kind of, I guess the point is, how do you deal with a, with a $5 wrench attack for bit key? Today, I think that is the answer. You would need to make sure that your bit key is at a different location from your home. And that's sort of the great, you know, it's the value prop of our transfer without hardware is that you can go and set that limit. You could, you know, you could even set that quite high if you were interested, such that, you know, if a attacker did come home, they could get a

27:07days worth of funds or even, you know, take your phone and get, you know, seven days worth of it. And maybe that's enough to satisfy them and prevent further violence, for example. But we actually have thought about this very, very deeply. And we've got some really interesting designs that are quite far along around, you know, vaulting features. The, the policy signer, the server key, it gives you a lot of really really interesting options. And, you know, for example, you could, you know, envision a setup where you moved certain amount of funds into a vault that could not be signed for by, by the app, but only by the hardware and the server. And then the server would require, you know, a 30 day request to sort of elapse before it actually decided to sign for the funds. So there's some really interesting flexibility there that we think can help the, the wrench attack type situation that we're looking at. It's nothing that we've committed to in a roadmap yet, but we do have a very, you know, kind of near the end design that that we've talked about a lot. And

28:07it's very interesting. Okay. Yeah. So then in that scenario, you would have, well, still the, you still have the bit key in a different location or you're saying in that scenario, you could have, because I mean, theoretically, if you are securing a lot of value and your phone and your bit keys in the same location, it can be spent, right? Like theoretically, going to the head can be spent, right? Yeah, that would allow you to actually have your bit key at home. And the funds would just be like unspendable for 30 days. And, you know, we, we were, we picked that time as, as something in our design, because we went back to research all of the, the past wrench attacks that have been published. And, you know, none of them lasted for, I think the maximum was six or seven days in terms of, you know, in type of kidnapping, because every day that a kidnapper is, is holding you, right? Is additional risk for them getting you. Yeah, exactly. Exactly. And, and we also even thought deeply about, you know, we don't want someone to just, well, take your stuff and make you swap your fingerprint, et cetera. And then they just take your, you know, they leave with all of your stuff

29:11and harm you so that you can't stop them, you know, design looks at ways that we can make sure that you are present at the time of request and that you're present at the time of withdrawal as well, you know, so that, and the attacker is not incentivized to actually, you know, do harm to you just, to sort of wait out that, that period. So, I guess you're kind of leveraging almost like a policy signing element to put a kind of a timer or a time lock on the large, and so theoretically, the idea would be you might keep smaller values in just kind of immediate spendable, right? But larger values are secured by that 30 day lockout kind of period. That's right. Interesting. Yeah. Okay. So, I mean, yeah, that could make sense for people to, okay. Let's talk a bit on the recovery side of things. So, we touched on this on the, you know, individual recovery, but you also have this recovery contacts system. So, can you just talk through the recovery contacts system? Sure. Yeah. So, the evolution of our recovery features, you know, this is all pre-launch was the first one was kind of clear is cloud backup and recovery,

30:13where we cryptid something to the, and uploaded to the cloud that only you could decrypt with your hardware that lets you back in immediately. Then we started thinking about, well, okay, well, what if you didn't have the elements required to do that? So, you didn't have your hardware or you didn't have your cloud. That led to the other two that we talked about that eventually, you have these seven day, you know, waiting periods that we discussed. Then we still felt like, well, that's still not good enough. Like, what happens if you actually lose your phone and your hardware at the same time? You know, because any time you have them together, there's some chance that's, you know, some event will cause you to lose them both. And so, we spent months working on a design, and I think that it landed in a really good place and it uses what we call recovery contacts. And when the recovery contact you basically, you take someone that you trust in your life and you don't have to trust them with your, you know, private key material. You just have to trust them enough that in the moment of need, you can reach out to them and they will help you, right? So, to set this up, all your recovery contact needs to do is download the Bitkey app. They don't

31:14actually need a bitkey hardware. So, it's free. And there's an out of band authentication mechanism that happens where you send them a code. They end with the code in the app. And that's just to enable to make sure that sort of, you know, block or anyone else can't man in the middle you and eventually, you know, act as your recovery contact on your behalf and get any kind of material that would be helpful. And so, the way it works at the time that you actually need it is, let's say that you've lost both your hardware and your phone. You still have your cloud. So, you have the packages that we've uploaded to the cloud. What we do at the time of enrollment is the your recovery contact shares a public key with you that allows you to encrypt things that only they can decrypt. So, once they they pass that public key through block and it's kind of secured by this out of band, the protocol is actually called spake 2, the out of band protocol and allows you to basically have a secure channel that block or anyone else can't intercept. So, they send their public key over to you, you then use that public key to encrypt a data encryption key. And before you encrypt that data

32:19encryption key, you actually use it to encrypt your app key. So, you have an encrypted app key. And then you have your recovery contacts encrypted version of the thing that encrypted it. So, it's kind of like an onion scan like it's nested. And then all you do is you send back to your recovery contact the encrypted data encryption key so that they can later decrypt it for you. You never actually send anything that has your private key to them. You just upload that package to your cloud. Then whenever you need them, you download the package from the cloud, you have the encrypted deck, the DK, shipped that over to your recovery contact. They decrypt it for you. Now, you have the unencrypted deck which allows you to decrypt your private key that you had stored. So, it essentially acts like the hardware did in our original cloud recovery. But instead of the hardware encrypting your private key, you sort of use this nested layer of encryption from your your recovery contact. So, it kind of, you know, it's a lot of complexity under the hood, but in the end, it feels like magic because you're like, I've lost both of my keys. What do I do? My recovery

33:22contact is there. They unlock it for me. Now I've recovered my app key. And from there, you're basically in the same scenario that we started our conversation about, which is I don't have a hardware anymore. So, you go through that seven-day delay-in-notify period to sweep your funds from your two of the keys that were you've lost one of the keys to a brand new one. I see. And so, the recovery contact process is that instantaneous unlock? And then from there, it's a seven-day period for that initial process. But yeah, that process we talked about earlier, right? Yeah, delay-in-notifies what we call it. Yeah, exactly. Okay, delay-in-notify. Okay. Gotcha. Okay, so, yeah, so I think that's, and that's kind of interesting. That's remarkable in that way because it allows the user to kind of have lost, you know, both things theoretically. As long as they've still got access to their Google or Apple account, right? Then they can still kind of get back in the game and not lose their stuff, right? So, that's actually really powerful for, especially for, you know, if you've got friends of family who are, you know, not that into Bitcoin and then I like, you know, watching podcasts all

34:23the time and they want to be able to just casually recover, right? So I think that's actually, it's worth understanding because it's like, I think sometimes we can have a recency bias, right? Like, if we think about, okay, people lost money because of the entropy of vulnerability. But actually, what, what, where have most of the loss has been? Well, a lot of the losses have been with custodial exchanges and the failures associated with all of that, like, Mt. OX and FTX and all that stuff. But the other big ones are like, you know, malware, phishing, these kinds of things, or people like putting their past, putting their 12-word seed into their password manager and then the passive manager getting hacked, like, I think that happened with last pass. There were some examples of that historically. So I think this idea of, you know, being able to recover your coins without even while having lost that is pretty powerful. And so then in terms of recovery contacts, is it like you can set up like two or three or is it like a limit on that or what do you, how does that work? The limit is actually pretty high. I think it might be 10 or 20. So you could really create as much redundancy as you're willing to and want to their.

35:28Interesting. Okay. And then so basically, you know, family or close friends, maybe they can be your, they can be your recovery contact. And then that way, you kind of gives you a little bit more piece of mind that you're not going to lose it from the recovery perspective. Like, you've at least, you've got that, that. So that's, that's really interesting. I like that idea. And then, I guess kind of future stuff a little bit like there's kind of talk about things like, you know, Frost and mini script expanding and decaying multi-segs and things like this, or maybe like a covenants upgrade for Bitcoin, if we hypothetically were to get that, which of those would be interesting to you? If at all. Yeah. Frost is actually really interesting. In fact, we've already, we have a working prototype of Frost in our repo that is not, it's not actually, you know, live. We built it as part of a software wallet exploration a couple of years ago. And, you know, Frost is amazing. And it actually opens up some really interesting properties in our system. One being that, you know, today, when you lose a key, like, you know, I've said a few times,

36:29you know, today you, you've lost one. You need to go create a brand new set of three and do an on-chain transaction to move from one to the other. Well, because Frost, like the Frost dynamic, because you can actually repair key sets in that sort of same dynamic. And all you've done, you haven't actually changed the coins on-chain. Exactly. Exactly. Oh, sorry, I guess just for listen to you aren't familiar. We sometimes talk about terms all the time. Frost, it's a flexible, round optimized, nor threshold. Yeah. But the point is, it's kind of like for listen to you, don't know, it's kind of like multi-seag, but on, on-chain, it looks like single-seag. But the tradeoff of that is that it requires a bit more interactivity. It's kind of newer technology. There's not as many people in the industry doing it. I've done some episodes with the Frost Snap guys. They're doing Frost, obviously, but other than that, it's not maybe not very well kind of adopted yet. But it allows these kind of flexible aspects where it can be single-seag. It can be some cost savings and maybe a little bit of the privacy benefit because you don't, you're not

37:32exposing on-chain that you're a multi-seag. Exactly. You're actually looks on-chain like a single-seag. So that's some interesting trade-offs. And as you, as you mentioned, it allows this idea to kind of rotate the key set without having to actually move the coins on-chain. So that's kind of an interesting property of Frost. For listeners who maybe you're not familiar with that. So, yeah, so that's interesting. So then the idea would be, Bitkey could be operating in a Frost context. So how would that change any of the other aspects of the model that we spoke about, if at all? That's kind of the beauty is that because the underlying technology sort of looks like multi-seag, you're able to do all the same types of things without really disturbing your on-chain footprint. So, in fact, you nailed some of the other value props there, right? It's actually less expensive because on-chain you actually are a single-seag, you're not a multi-seag, which is cheaper. You get some privacy benefits from not, you know, right now, Bitkey is of two or three. It's like we're the only two or three, but when you see a two or three

38:33on-chain, you know, you can make some assumptions and the channelist's style, you know, piecing together of all the parts of the blockchain might be able to, you know, find out more than you would want about you as a result. So, just a lot of great benefits there. And yeah, I mean, it's something that we were really, really excited about and still are. I don't know when we'll get back to it. It was certainly an important part of our software wallet initiative. And if we get back to that, I'm almost certain that it would that would bring frost to the entire Bitkey system because when we were planning on doing it, it wasn't just going to be, oh, there's a software wallet, Bitkey app and a hardware wallet, Bitkey app. It was going to be all one app and the entire Bitkey system would be converted over to frost at that moment. So, we made, you know, a significant headway there and it's just a matter of, you know, finishing up that work once we, you know, prioritize that back on our roadmap. You asked about other things. Any thoughts on the like covenants like would, you know, if BitFull 4, 8 hypothetically would have come to Bitcoin, would that change anything and what you could achieve? You know, the first thing that always comes

39:36to mind around this type of topic to me is, is, you know, our spend without hardware and, you know, our server being a policy signer. If there is a way to, you know, to sort of enforce that on chain, I think that would be really interesting. The way that we've implemented it now where it's like literally a daily limit that we're tracking, I don't think that's actually possible in the bit that you mentioned. One thing that I think could be interesting is, today, the way that the inheritance protocol works in Bitkey is that in a similar way to the recovery context we discussed, your benefactors do the same kind of public key encryption for you. But rather than uploading that package to your cloud, you actually upload it to block. So that block has that package. They don't have the ability to decrypt it, but they do have that encrypted package. And then, at the end of the inheritance, I think it's a six month window, and if you haven't canceled that claim within that six months, we assume that you are no longer here. We then deliver that package to your benefactor so they can decrypt. But it does contain the app private key. And I think

40:39covenants through the delegated signing feature might allow us to remove that the app key and just let the benefactor become a delegate for you in signing so that they could sign that package with a six month delay that's enforced on chain rather than forced by our policy. So I think there might be something interesting there. We still need to dig into. We haven't validated those assumptions yet. And then the vaults feature I mentioned earlier, I think also could really benefit from from covenants where some of the things we would do are implemented at the big key policy level and we would just love to move those on chain anytime we could move something on chain. We would there's no reason that we want to be the arbiters here. We just do it when there's no other option. So yeah, I think that's a really interesting possibility as well. Yeah, interesting. And so I think the other one that often gets brought up here now, James O'B had this idea of op vault. And I believe that's now kind of been superseded by Savatori and Gala's idea of op ccv or check contract verify and I think that would enable like a

41:42really powerful vault. But to be honest, it doesn't look like there's a lot of excitement for that one. So I would not recommend listening to his hold their breath for op ccv coming anytime soon. But that would enable like a massively powerful vault in terms of what people can achieve. So yeah, also we touched on this earlier, but chain code delegation would be interesting just to kind of talk through a little bit about that. Do you want to just I guess explain a bit on that and maybe start with like what what is a chain code? Yes, so a chain code is what essentially allows you to you know, as you're you're deriving wallets and in an HD wallet, it's the mechanism that you need to be able to derive addresses without the private key. And right now in a traditional two of three multi six setup, all members of the of the quorum have the chain code. So you know, it's a part of the descriptor of the x pub. And so what that means is that any you know, recovery service today or any party that's within your two of three has the capability to see all of your

42:45on chain activity. And when we launch pick key, we were no different. We had that capability as well. We we didn't want that. So we really worked hard to remove ourselves and and invented something called chain code delegation. And so basically the the app withholds the the chain code from the server and which is typically required to actually for the server to do signing. But through something called tweaks, there's kind of a nice mathematical property that allows the the app to calculate the just the minimum necessary data to to to share with the server. It's called a tweak that will allow them to actually do the signing without ever learning the chain code. And then it actually becomes a valid signature. And so we we implemented that it became a bit. It's 589. And I think we launched it about a year ago, just about a year ago now. And after that launch, anyone who's either upgraded to the private wallet who had onboarded before or who just onboarded to Bikki after that moment, we're we're blinded to transactions that that we are not a part of signing.

43:46So it's a, you know, people a lot smarter than me, you know, came up with the idea and implemented it. But it's been just an amazing feature that we've offered to our customers, I think. Yeah, I think it's probably an underrated benefit for a lot of people because a lot of people have this initial idea of the privacy. You don't want to let them know your coins. And actually, in this case, block actually does not know your coins, except in the case of a recovery scenario. I guess that's the one where block would know the user's coins in terms of how many to have and where they where they are on chain per se. But really interesting benefit there. So I guess we we covered a bit there. So I'll just kind of walk it through at least how I understand it. And listen, is you know, maybe that'll help you as well because you might be driving or whatever in the gym. So this idea of the chain code, like so just separate for a lot of people who might be used to other hardware wallets, like you might be thinking of like BIP 39 right down your 12 words. This is BIP 32, but not BIP 39 right? BIP 32 relates to the hierarchical deterministic wallets. You have an extended public key and the idea is that you can derive later addresses. And as you

44:49mentioned, Clay, the chain code is what allows. So it's like the chain code plus that extended public key is what allows people to kind of derive addresses in that index like index zero index one etc. And so what what we're doing in this case with what you are doing in this case is with chain code delegation. The user has his chain code, but it's like block is blinded. It's blinded to block per se. And instead of the user giving block his full chain code is giving them a tweak for the recovery transactions or the inheritance transactions. So that block can cosine for the user. But in normal circumstances, the user is just has his, you know, he's got his phone key and his device key. And therefore does not have to disclose his chain code, his full chain code. And therefore he all his addresses and balances to blocks to block. That's right. Yep. Nailed it. Gotcha. Okay. And then Electrum servers. So you touched on this before about how there are, you know, other servers. It's not

45:54can you talk to us a bit about that? And as I understand, you also have a custom server option because that's like maybe the advanced user wants to, you know, hook it up to his umbral Electrum server or, you know, use something else. Talk to us a bit about how the Electrum server side of this works. Sure. Yeah. By default, you, you, you, Bikki will connect to one of our third party Electrum servers. It's either mem, mem pool or block stream. And that does not route through Bikki servers. So it goes, you know, directly from the app to to those, those third parties. And that, that separation was intentional. Like we don't share any account information or anything like that with those third parties. And then we don't see the, the actual trend, you know, traffic that goes through the Electrum servers. So we wanted that separation. But if someone wants, you know, even additional privacy, we have the ability to set, you know, they can go set what any Electrum server that they wish. It does require TLS. So it has to be a secure connection. Today, the umbral, the umbral options don't come with TLS enabled by default. There are some tutorials on how you can, you know, you can sort of set all that up to work. It's not, it's certainly

46:58not a one click and done type thing. But we've definitely had customers who, who've done it and use it. But, you know, if you're using any other, you know, you could use the other public Electrum servers. For example, the one that you could find in Sparrow, for example, we've tested those out and those work as well. As long as they are, you know, that they have registered certificates and they're not in a sort of self signed. We, we have looked at the option of just allowing you to bypass the TLS requirement. We just, we want to do it in a way that customers really understand the trade-offs because if, if you're sending non-TLS traffic, you need to make sure that you're doing it in a way that's secured, like, you know, the tail scale is a good option that you could still secure and encrypt the traffic even though it would be, you know, visible to anyone that was, you know, watching the traffic across the network. But, you know, Bikki doesn't have a way to validate that you're using tail scale properly. And, you know, the last thing we want to do is make an option that's just very easy to turn on that winds up, you know, leaking all of your, your transaction activity to anyone that's

47:59watching along the network from here to the, you know, to the endpoint. So, you're definitely interested to hear from customers who, which is like, really, really need that option or want that option to, you know, understand where we prioritize it. It's definitely something we can do and probably will. Interesting. Yeah, okay. Yeah, but I mean, as you, the way I'm thinking about it is, you kind of, you're putting in, let's say, a guard rail for people, but there are people who maybe they, they, you know, they really want it another way or whatever. Also, curious on the compact block filter conversation, like BIP 157 and 158. Is that a possibility? Is that something you looked at? You know, that is actually, I don't know that we, we have discussed it now. I joined the team, I think, about six months after the project started. And so, you know, maybe two years before launch. So, I don't know if before I was around, we had the conversation about that. But I think it's certainly an interesting one that we should look at. And you know, help me with the trade-offs here. If I understand correctly, it's that basically, rather than, you know, sharing all of the

49:01addresses with a, with a, a node or an electric server that you are interested in, which essentially, you know, gives them full view of your wallet, you would, you would sort of get asked for blocks, you know, compact blocks from them. And then you would be able to tell which blocks your addresses were a part of and can kind of do all of the work to assemble the, the data of your wallet without a, a third party knowing exactly what your wallet is. I don't, I, I can't think of anything technically that would prevent us from doing that. If I understand it correctly, that it has pushed a lot of the hashing to the client side and on mobile. For example, if you didn't log in a bit key for a year and all of a sudden, you had to pull all those blocks and do all that hashing from what I understand that could be, you know, quite time consuming and, you know, really heat up your phone and that type of thing. But, you know, maybe as an option for someone who is just really privacy-minded and wanted that extra bit of, of privacy, I think that's really interesting for us to look at. Yeah, I think that's, I think that's my understanding as well that basically, there are some walls that do do this, but there is a trade-off, as you said, that it pushes more to

50:04the phone and then that might be slower as an experience. And so maybe there are users who really care about privacy and they would write, they would, they're okay to wait for that. And then, of course, the everyday user might feel, oh no, it's not like my, you know, my neo bank or my, you know, whatever my fancy bank, I want, I want to see my balance straight away, you know, and the other challenge, and I appreciate that, like from your side as a, you know, software and hardware maker here, is that you want, you don't want the user to get spooked and feel like my, my coins aren't there, where are my coins, right? Because then that's like the worst outcome. And we've seen that before, like, you know, sometimes in the industry, when you're talking to people, sometimes you're helping them recover or they're trying to load a wallet in like a lecture or more sparrow, and they're looking on the wrong input, they're looking on the wrong output type, so they didn't see the coins and they were spooked because they didn't see it there or this kind of thing. So, I can understand this kind of a, you know, there are trade-offs of that, but never the less. That, yeah. That loading moment when you first open up a wallet is, it's especially tricky for

51:06self-custody, I feel like, because if you just show the cash balance, A, it's not necessarily updated with how, you know, the price of Bitcoin has changed over time. There might be other transactions that have come in since then that they are aware of that aren't replicated, you know, and so then you want to, you got to kind of show a loading, you know, view, and depending on how long that takes, there's that moment where they're like, you know, depending on how long it's been, they want to see how much Bitcoin they have. So, you know, we've tried to work hard to make sure that that experience is as good as it can be, but it's, it's, it's chock full of trade-offs in itself. Yeah, I see. So, I guess, yeah, I'm just sort of thinking about what else there is. So, in terms of, yeah, where you think things are going in the wake of all these kind of AI-assisted attacks, kind of just broadly in Bitcoin and the industry, there's been a lot of them, right? Like, obviously, the code got being liquid, I think, I think, bit, bit box had some vulnerabilities, core lightning had some vulnerabilities, bolstot exchange, like, I mean, there's so many, I'm probably forgetting some. What, what do you thoughts on all that and like, you know,

52:07what does it mean for the industry, for Bitcoin security? I think anyone who says that things haven't dramatically changed, they're not being honest in themselves. I'm not saying anyone has said that, but just, you know, as a way to start, start the topic, it's, it's, it's changed dramatically, and I think many of us are still reckoning with what it means and how to, to make sure that we're building products that are going to withstand, not only the way things are today, but, you know, we're on a curve here, right? Is this just going to continue in this direction? And one thing that matters a lot is making sure that developers who are going to be working against these attacks have access to, you know, the state of the art, you know, LLMs, you know, just the way that the attackers are going to find ways to do. And, but, you know, I also think that it's likely going to take a shift in our security mindset, you know, I think a lot of companies traditionally, at least, you know, where I've worked, the, the conversation around security and product is always, it's just like a trade-off conversations. Okay, well, what, you know, to implement this security feature,

53:08what is it going to do to our timelines or to the customer experience, and is that going to be worth the trade-off? And a lot of times there's different ways that you think about the security model to understand what the actual risk is, is there. But I think this just starts meaning that you have to just take all that stuff way more seriously and accept a lot of the trade-offs that come along with it. The good news is that we've all set that with, you know, ways to build faster and more effectively with LLMs. So it's not like we're just necessarily going to slow down, but we might wind up, you know, trading off a little bit of speed to make sure that we're fundamentally building things in ways that are not just sort of chock full of holes that are hard to find, right? You know, security through obscurity or that type of thing. And I don't, you know, I'd be surprised to find any major player in this industry that was sort of just proactively building that way, you know, on purpose, but taking stock and taking a look at your own development practices, I think is really important. And probably having more time with security in the room upfront, looking more at the actual architecture layers of what you've built. And, you know,

54:12making sure that you are solid from the ground up is really, really important. Constant scanning of your code base with these tools. And, you know, the harnesses matter a lot here. There's been a lot of great work from Project Loop, for example, out of spiral and, you know, the Bitcoin red team was doing a lot of great work publicly helping out to try to find vulnerabilities. I think every company is going to have to find out what the right fit is for them to make sure that they are, you know, ready to go in this day and age. And I think asked me again in three or six months, what's the way she was changing so rapidly? Yeah, it's been pretty crazy. So I mean, there's, there's all these, you know, if you kind of zoom out and look at custody in the industry, you kind of have different options, right? You either kind of pay a custodian, you use like a kind of like a guided, you know, multi-seag kind of provider. You maybe you pay a consultant to kind of, you know, teach you how to do it yourself or you go and DIY yourself, you know? And of course, there'll be a bunch of people who after all this stuff, they're just going to go to ATF and custodial and that's it. Where where does Bitkey fit into all this? How do you,

55:18you know, how do you, you know, fit bit key into that? You know, I think a lot of people still don't fully understand that when you buy a bit key, you're not just, you're not just buying a wallet. You're actually buying us, you're buying a wallet that comes with a service that's free for life. And so, you know, we are a a recovery co-signing service and and there's not a monthly fee attached to it like there is with with all of the other competitors in that space. And we are a wallet as well. And I think I'd be pretty surprised if if we continue to be the only company that's building both of those things and bundling them that way, because, you know, I think right now the the industry is very much DIY. It's like pick and choose your parts and go build your own car, you know, versus go into a lot and figure out the one that's right for you. And, you know, I think the beauty of it is that I'm glad that there are options to go build your own. Like, I would never want that to change and I would never want customers to to not have that option. So, I just think that we need to all as an industry be willing to to challenge our past ways of thinking

56:21when we hear from customers that this thing is really hard, right? This thing is stressful. You know, in the wake of the cold card incident, there was a few different podcasts I listened to with, with, you know, kind of leads within hardware wallet manufacturers. And a lot of times the conversation was just, well, we should have made this more secure and therefore less usable and customers should have just like, you know, we should just trust customers more and they'll figure it out. That mindset, to me, doesn't feel like they're out. They're really talking to customers because that's one thing we do a lot is talk to customers and, you know, on the the conference room floors. A lot of people will confide in you that I'm kind of afraid to say this, but I'm so glad there's an option that doesn't require a seed, right? And that doesn't mean that everyone needs that. It means that there are customers who need it and let's go build for them. So I think we're a bit key sits right now is in an interesting place. I think we're going to evolve. I think we will, you know, have less vendor lock-in be more standards compliant over time, hopefully by introducing new standards and getting

57:23coalition that helps build alongside us for the customers who need it. And then I would just say I'm glad we live in this space where there are so many great builders that also care deeply about the core values of Bitcoin and still offer things where a seed phrase is required because the seed phrase is a beautiful thing to someone who is ready and equipped to use it and, you know, cross his borders and would never want that to change. In fact, we're also even looking at options, for example, for seed import and to Bitcoin. And obviously if we have third party hardware, then that would come with a seed as well. So we're really taking the post-cult card era as a time to reevaluate everything that we built so far and see where the option spaces are to kind of continue to expand what Bitcoin can be. Yeah, I appreciate what you guys are doing because I think it is a different level of usability for new users, right? I think that's something where those of us who've been around for a while of, maybe we get so trapped up or so caught up in how we're used to doing things. We just kind of

58:25expect everyone to just be able to figure it out, but it's not that simple, right? Unless you're going to actually invest the time and the money potentially to really do that. And I guess, for people who aren't die-hard Bitcoiners, that's a big or ask for them. So I appreciate what you guys are doing. I was a bit more critical of Bitkey V1 with no screen because I was a bit like, what are you signing? How do you verify what you're actually signing? Bitkey V2, I mean, hey, you've got a screen. You're verifying your clear signing something there. And you have an interesting mix of easy recovery, but also easy use. And hopefully the users are not going to get scammed or malware or fished or something like this to type in their seed the wrong way because of this. So yeah, it definitely serves its role. But as we said, there's no one size fits all. So everyone just has to really kind of think for themselves, what is the right solution for me? And then even then, it's not all or nothing. You can have some in this solution and some in another solution. And maybe you've got some here because you're doing some other thing that you're

59:25doing a Bitcoin collateralized loan there or other things. So all these are options for people. So yeah, just finally, listen, as you can find the guys at bitkey.world and Clay, your handle, was it Clay underscore Garrett? Was it? Yep, that's right. On X. There we go. All right. Well, I think that's all from us. So thanks for joining me Clay. Hey, thank you so much to find and appreciate it.