{ "episodeId": "SLP778", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "clay_garrett": { "name": "Clay Garrett", "role": "guest", "tag": "CLAY" } }, "segments": [ { "speaker": "clay_garrett", "time": "00:00", "start": 0.0, "text": "That mindset, to me, doesn't feel like they're out there really talking to customers. In the wake of the Coldcard 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." }, { "speaker": "stephan", "time": "00:19", "start": 19.0, "text": "Hi, everyone. Welcome back to Stephan Livera Podcast. Joining me on the show today is Clay Garrett. Clay is lead at Bitkey from Block. welcome to the show, Clay." }, { "speaker": "clay_garrett", "time": "00:29", "start": 29.0, "text": "Thank you, Stephan. I appreciate the opportunity to be here." }, { "speaker": "stephan", "time": "00:32", "start": 32.0, "text": "So, Clay, let's get into Bitkey, 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-custody. 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 it April this year or earlier this year, right? Talk to us a bit about that." }, { "speaker": "clay_garrett", "time": "00:56", "start": 56.0, "text": "Yeah. Yeah, it came out in April at Bitcoin Las Vegas, we launched it. Yeah, so first of all, the, you know, with the 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 2-of-3 multisig. So that means, you know, you need two of the three keys together to sign and spend at any 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 2-of-3 to spend, we cannot spend without you, and you can spend freely without Bitkey. and so, you know, that kind of creates some interesting options, for both recovery and, you know, spending without your hardware, if you, if you so desire, which I'm 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, you know, 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. we use things that are, you know, already in your life, including, you know, like your, your cloud access, your phones, your, 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 hard to get in other types of setups." }, { "speaker": "stephan", "time": "02:24", "start": 144.0, "text": "Yeah, and I think, we should talk a bit about that because that makes me kind of remember this point because obviously with the Coldcard thing, Everyone was spooked about entropy and then it became all about like, oh yeah, you got to get your dice and to be clear, I've been an advocate of dice 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, 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 Coldcard 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 Bitkey?" }, { "speaker": "clay_garrett", "time": "03:03", "start": 183.0, "text": "Sure. We use a term a lot called safety, and we sort of combine security and accessibility, recoverability, all into one term that's essentially the thing that matters overall 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 a 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 holistic view of the system in terms of how likely you are to actually retain control of your funds." }, { "speaker": "stephan", "time": "03:47", "start": 227.0, "text": "Right. And I think there's all these trade-offs around, you know, how the product is designed. So let's just talk a little bit about the, so you mentioned the 2-of-3 model, right? It's in the one key, in the, you know, the Bitkey device, the physical device itself, one in the phone, and then one On in the Block server or Amazon, web services, Nitro server or Enclave, when are each of those used?" }, { "speaker": "clay_garrett", "time": "04:11", "start": 251.0, "text": "So primarily, a customer will probably use the two keys that they own. So that's the app key and the hardware 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 Electrum server, which actually, you know, use, 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 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, Bitkey 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, the Bitkey service will notify you at every touch point 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, hit, go, go to the app and hit cancel. And then that recovery will be canceled and we won't sign, you know, on your behalf. If the seven day passes, seven days passes and we don't hear from you, you don't cancel it, we assume that it is you and, you know, in 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" }, { "speaker": "clay_garrett", "time": "05:46", "start": 346.0, "text": "Key keys of, to a brand new set of three keys that is established with the new Bitkey hardware that you've 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 in inverse. You just, you use your hardware key and then the server key to sign. 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 their Bitkey at home, for example, if they just want to do, you know, daily or weekly spends, 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 Bitkey 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 Bitkey 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 Bitkey 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 is 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." }, { "speaker": "stephan", "time": "07:09", "start": 429.0, "text": "I see. And so then in that example, what type, what's going on is when that customer originally set it up, 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." }, { "speaker": "clay_garrett", "time": "07:44", "start": 464.0, "text": "Exactly. And when you do a cloud recovery, so like you said, we pull down that payload from the cloud. It is, it is encrypted by the hardware, as you mentioned. So if someone were to just get access to that payload, but did not have your unlocked hardware, it's useless to them. The, the hardware will decrypt it. And at that point, we actually give you the opportunity to sign Any other devices. So if you, at that point, would say yes, now the attacker has your phone, you know, for some reason they've been able to keep it, you know, from locking this entire time, they would now not be able to communicate with the Bitkey servers anymore." }, { "speaker": "stephan", "time": "08:15", "start": 495.0, "text": "I see. So at that point, you're doing, you would buy a new phone and then tap it with your existing Bitkey device." }, { "speaker": "clay_garrett", "time": "08:22", "start": 502.0, "text": "Exactly. And" }, { "speaker": "stephan", "time": "08:22", "start": 502.0, "text": "Then that, at that point, then you start the transition over to recover, in the, is there, is there still, so that's where there's a seven-day timer in that, in that scenario?" }, { "speaker": "clay_garrett", "time": "08:30", "start": 510.0, "text": "Actually, yeah, as long as you have your hardware and access to your cloud, there's no delay period, right? So." }, { "speaker": "stephan", "time": "08:36", "start": 516.0, "text": "So it would be an instant swap over." }, { "speaker": "clay_garrett", "time": "08:38", "start": 518.0, "text": "Right, right. Because at that point," }, { "speaker": "stephan", "time": "08:39", "start": 519.0, "text": "You," }, { "speaker": "clay_garrett", "time": "08:39", "start": 519.0, "text": "You have your hardware key, because you, you used your hardware to decrypt the backup, and then after you decrypt it, you have your app key. 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." }, { "speaker": "stephan", "time": "09:08", "start": 548.0, "text": "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 or Apple, but not your device because maybe it's in another country and you can't get there yet, that kind of scenario or." }, { "speaker": "clay_garrett", "time": "09:22", "start": 562.0, "text": "Right. Well, so if, if you've lost your hardware, that's the." }, { "speaker": "stephan", "time": "09:25", "start": 565.0, "text": "Well, that's another whole scenario, right? Yeah, that's" }, { "speaker": "clay_garrett", "time": "09:27", "start": 567.0, "text": "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 sweep 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 real, an evil roommate. They waited for you to unlock your Bitkey 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 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 both 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, seven day delay period." }, { "speaker": "stephan", "time": "10:37", "start": 637.0, "text": "I'm curious then, in that evil roommate scenario, does that mean you've got to quickly run and buy a new Bitkey device and get it within the seven days?" }, { "speaker": "clay_garrett", "time": "10:43", "start": 643.0, "text": "Well, they can't do anything with just your unlocked device, right? So they have to, yeah, they have one- They don't need to be able to log" }, { "speaker": "stephan", "time": "10:49", "start": 649.0, "text": "Into your Bitkey app, right? Exactly," }, { "speaker": "clay_garrett", "time": "10:51", "start": 651.0, "text": "Exactly. Which they can do if, you know, if the seven days goes by and you haven't responded or canceled, you know, any of our, at that point, probably 30 or 40 notifications to you that someone's trying to recover your account. But, you know, thus far we haven't, we haven't heard of that happening at all." }, { "speaker": "stephan", "time": "11:06", "start": 666.0, "text": "Gotcha. 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 scenarios 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. So I want to be fair, that's, you know, 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 se, 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?" }, { "speaker": "clay_garrett", "time": "12:14", "start": 734.0, "text": "First of all, I would say that there's no intentional vendor lock. It's, you know, and I think in the future, you know, probably, probably look back at, at, you know, this time and say, oh, remember, you know, when Bitkey was, you know, had vendor lock in. The, the reason that that exists today is that the design decisions that we chose were just very non-standard in the industry, right? The, 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 wallet 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 Bitkey 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 Bitkey-style server and, you know, maybe implementing certain additional features on top of it, or, you know, being able to bring in other hardware wallets into the Bitkey ecosystem. We're actually looking pretty intensely this year at Trying to, you know, see what third-party hardware support would look like." }, { "speaker": "clay_garrett", "time": "13:43", "start": 823.0, "text": "For example, if you wanted to have one Bitkey hardware and then one, you know, Trezor, Ledger, whatever, hardware wallet as a replacement for the AppKey, like, 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 trade-offs on the other side of it. So I just want to make sure it's clear that the ethos of Bitkey is not, hey, it's Bitkey 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 than 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 Bitkey style concept, and I think we've even seen more companies push towards this direction, which we're excited about. Like, we're very much, 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 BIP for that and got, you know, the BIP accepted and hope that others, you know, start building that type of privacy feature into other wallets as well." }, { "speaker": "stephan", "time": "14:56", "start": 896.0, "text": "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 Coldcard, you know, vulnerability, entropy vulnerability, there was a lot of discussion around multi-vendor, multisig. And I guess that's maybe one of the areas where Bitkey feel, at least currently, now to your, to your, to be fair to you, it sounds like you're actually looking at ways to sort of go, you know, to advance that, but it seems, it sort of feels currently more like single vendor. Now, yes, it's a key, it's, you know, a hardware key, a phone key, and a server key, but the software to manage it is all written by, you know, by Bitkey 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 Bitkey key as part of the quorum, then you would have multi-vendor." }, { "speaker": "clay_garrett", "time": "15:44", "start": 944.0, "text": "Right. Yeah, that's true. And, you know, I think the multi-vendor conversation that, you know, I think just gained a lot of steam after the Coldcard incident. It's not like it started there. I think it's directionally 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, 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. Vendor B, you know, 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 are 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 vendor C, you've actually decreased your security. And that's, I don't know, it's not a real world example, but it, you know, it just says 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'd 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 as, you know, thinking that Just by, you know, adding more vendors into the system, you're automatically gaining more security." }, { "speaker": "clay_garrett", "time": "17:11", "start": 1031.0, "text": "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, and if you're looking at a multisig with a couple of hardware wallets, if those hardware 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 fourth vendor, right? You've got your two hardware wallet vendors, your software wallet vendor, and now you're sort of becoming a security vendor where you may not be an expert in that. And, you know, are you going to be capable of securing a seed against all the things that might happen for your lifetime? You might be. Like some people are actually really good 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, it, it, there's always a trade-off in any of these and we need to look at both sides of the trade-offs. And that's not me saying that, oh, therefore a single vendor is the solution. That's not what I'm, what I'm saying. But it's also not saying that multi-vendor is automatically the solution. It needs to be really well thought out in terms of, you know, what trade-offs you're making and what you know about each of those vendors that you're choosing." }, { "speaker": "stephan", "time": "18:23", "start": 1103.0, "text": "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, like six or seven years ago, that was probably the main point. 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 don't lose your coins. And I think that was probably 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 Coldcard case, I'm sure many security experts were looking at the Coldcard 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?" }, { "speaker": "clay_garrett", "time": "19:21", "start": 1161.0, "text": "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 something that is, I don't, and 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." }, { "speaker": "stephan", "time": "20:28", "start": 1228.0, "text": "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 lunch, but I think for people securing, you know, very large amounts, it's probably worth your while, you know, right? It's, that's probably where it is more relevant for them. And so I guess on 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-custody for normal people, and I'm, 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 2-of-3 Bitkey 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?" }, { "speaker": "stephan", "time": "21:15", "start": 1275.0, "text": "Like who is the product known for? Yeah." }, { "speaker": "clay_garrett", "time": "21:18", "start": 1278.0, "text": "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 inheritance setup? Are their family members technologically savvy, the ones who, who might need to, you know, inherit their funds, for example? What, you know, a certain amount to one person might be something that they are 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 Bitkey 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, 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, for someone who already has a hardware. Wallet who is unhappy with, you know, their current setup or just wants some diversification, wants some peace of mind that if their elaborate setup, for example, has some flaw that they, 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." }, { "speaker": "clay_garrett", "time": "22:48", "start": 1368.0, "text": "So we are designing Bitkey to be worthy of that. Like that is definitely our intent while not sacrificing 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, we do believe that was a sort of big gap when we started building in terms of the space. You know, and there's 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 are so many options to choose from. There are so many wallet providers. There's, you know, kind of the recovery and co-signing services like Bitkey, like Casa, Nunchuk, Unchained, et cetera. 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 make sure that the server integration is exactly what's expected with the app integration, that the hardware works as expected, et cetera, et cetera. 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." }, { "speaker": "clay_garrett", "time": "24:21", "start": 1461.0, "text": "And, you know, 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 things that have, 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 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, Bitkey's probably not a great option for you because you're sort of putting all your eggs in one corporate basket. If that's your, your worldview, 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 worldviews 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, pro-propose our customers think about things." }, { "speaker": "stephan", "time": "25:36", "start": 1536.0, "text": "Understood. Yeah, now I guess another, I mean, maybe the, this depends on where you actually keep the physical Bitkey device, but I think one thing from a multisig 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 night kind of situation. And if you had, you know, I think one example of like having multisig, 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 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 it work in a Bitkey scenario? Are you, like, would you, like, how would you make that work for a Bitkey? Would you, like, if the user has, you know, his phone at home and, you know, and his Bitkey in like a home safe, or maybe is the answer that, you know, You would, in that scenario, you would want to keep a Bit, the Bitkey 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 Bitkey?" }, { "speaker": "clay_garrett", "time": "26:49", "start": 1609.0, "text": "Today, I think that is the answer. You would need to make sure that your Bitkey 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 day's 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 a 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 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 we've talked about a lot and is very interesting." }, { "speaker": "stephan", "time": "28:08", "start": 1688.0, "text": "Okay, yeah, so then in that scenario, you would have Well, still the, you still have the Bitkey in a different location, or are you saying in that scenario you could have, cause I mean, theoretically, if you are securing a lot of value and your phone and your Bitkey is in the same location, it can be spent, right? Like theoretically, gun to the head, it can be spent, right?" }, { "speaker": "clay_garrett", "time": "28:30", "start": 1710.0, "text": "Yeah, that would allow you to actually have your Bitkey at home, and the funds would just be like unspendable for 30 days. And, you know, we were, we picked that time as something in our design because if we went back to research all of the past wrench attacks that have been published, and, you know, none of them lasted for, I think, I think the maximum was six or seven days in terms of, you know, any type of kidnapping, because every day that a kidnapper is holding you is additional risk for them." }, { "speaker": "stephan", "time": "28:57", "start": 1737.0, "text": "Yeah, exactly," }, { "speaker": "clay_garrett", "time": "29:00", "start": 1740.0, "text": "Exactly. 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 ceterand then they just take your, you know, they leave with all of your stuff and 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 an attacker is not incentivized to actually, you know, do harm to you, just to sort of wait out that period. So." }, { "speaker": "stephan", "time": "29:29", "start": 1769.0, "text": "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." }, { "speaker": "clay_garrett", "time": "29:41", "start": 1781.0, "text": "Right." }, { "speaker": "stephan", "time": "29:42", "start": 1782.0, "text": "But larger values are secured by that 30-day lockout kind of period." }, { "speaker": "clay_garrett", "time": "29:47", "start": 1787.0, "text": "That's right." }, { "speaker": "stephan", "time": "29:49", "start": 1789.0, "text": "Interesting. Yeah. Okay. So, I mean, yeah, that could make sense for people too. 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, talk us through the recovery contacts system?" }, { "speaker": "clay_garrett", "time": "30:04", "start": 1804.0, "text": "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, where we encrypted something to the, and upload it 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, your hardware at the same time? You know, because any, any time you have them together, there's some chance that, you know, some event will cause you to lose them both. And so we spent months working on a design, and I think It landed in a really good place, and it uses what we call recovery contacts. And when a 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 actually 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 enter 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," }, { "speaker": "clay_garrett", "time": "31:31", "start": 1891.0, "text": "Act as your recovery contact, you know, 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 pass that public key through Block and it's kind of secured by this out of band, it's, the protocol is actually called SPAC2, the out of band protocol, and it allows you to basically have a secure channel that Block, or anyone else can't, 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 encryption key, you actually use it to encrypt your app key. So you have an encrypted app key, and then you have your recovery contact's encrypted version of the thing that encrypted it. So it's kind of like almost like a onion skin, 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 DEK. Ship that over to your recovery contact." }, { "speaker": "clay_garrett", "time": "32:57", "start": 1977.0, "text": "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 contact 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+Notify period to sweep your funds from your your two of, you know, the the key set where you've lost one of the keys to a brand new one." }, { "speaker": "stephan", "time": "33:42", "start": 2022.0, "text": "I see. And so the recovery contact process, is that instantaneous unlock? And then from there, it's a seven-day period for the, you know, like for that initial process, for that process we talked about earlier, right?" }, { "speaker": "clay_garrett", "time": "33:54", "start": 2034.0, "text": "Yeah, yeah, delay and notify is what we call it. Yeah, exactly." }, { "speaker": "stephan", "time": "33:57", "start": 2037.0, "text": "Okay, delay and notify. Okay. Gotcha. Okay, so yeah, so I think that's, and that's kind of interesting, that's remarkable in a, 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 and family who are, you know, not that into Bitcoin and they're not like, you know, watching podcasts all the 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 vulnerability, but actually what, where, where have most of the losses been? Well, a lot of the losses have been with custodial exchanges and the failures associated with all of that, like Mt. Gox and FTX and all, all that stuff. But the other big ones are like, you know, malware phishing, these kinds of things, or people like putting their password, putting their 12-word seed into their password manager and then the password manager getting hacked. Like I think that happened with LastPass. 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 2-of-3 or is there like a limit on that or what do you, how does that work?" }, { "speaker": "clay_garrett", "time": "35:19", "start": 2119.0, "text": "Yeah, the limit is actually pretty high. I think it might be 10 or 20. Yeah, so you could really, yeah, create as much redundancy as you're willing to and want to there." }, { "speaker": "stephan", "time": "35:28", "start": 2128.0, "text": "Interesting. 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 peace of mind that you're not going to lose it from the recovery perspective. Like you've at least, you've got that. So 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 Miniscript expanding and decaying multisigs 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 FROST," }, { "speaker": "clay_garrett", "time": "36:06", "start": 2166.0, "text": "Yeah, FROST is actually really interesting. In fact, we've already, we have a working prototype of FROST in our repo that's 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, you know, today 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 key. You didn't have to move" }, { "speaker": "stephan", "time": "36:48", "start": 2208.0, "text": "The coins on-chain, right?" }, { "speaker": "clay_garrett", "time": "36:49", "start": 2209.0, "text": "Exactly, exactly. You can" }, { "speaker": "stephan", "time": "36:50", "start": 2210.0, "text": "Re, oh, sorry, I guess just for listeners who aren't familiar, we sometimes talk about terms all the time. FROST, it's a flexible, round, optimized Schnorr threshold, something like that. Yeah, but the point is, it's kind of like, for listeners who don't know, it's kind of like Multisig, but on on-chain it looks like single-sig. But the trade-off 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-sig, it can be some cost savings, and maybe a little bit of the privacy benefit because you don't, you're not exposing on-chain that you're a multisig. You're actually, it looks on-chain like a single-sig. 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 would, how would that change any of the other aspects of the model that we spoke about, if at all?" }, { "speaker": "clay_garrett", "time": "38:04", "start": 2284.0, "text": "The, the Kind of the beauty is that because the, you know, the underlying technology sort of looks like multisig, you're able to do all the same types of things without really disturbing, you know, 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-sig, you're not multisig, which is cheaper. You get some privacy benefits from not, you know, right now. Bitkey is of 2-of-3. It's like we're the only 2-of-3, but when you see a 2-of-3 on chain, you know, you can make some assumptions and, you know, the chain analysis 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's 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, 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 know, you asked about other things. Any thoughts" }, { "speaker": "stephan", "time": "39:25", "start": 2365.0, "text": "On the, like, covenants? Like, would, you know, if Bit448 hypothetically were to come to Coin, would that change anything in what you could achieve?" }, { "speaker": "clay_garrett", "time": "39:34", "start": 2374.0, "text": "You know, the first thing that always comes to mind around this type of topic to me is, you know, our spend without hardware and, you know, our server being a policy signer, if there was a way to, you know, to sort of enforce that on chain, I think that'd 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 BIP 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 contacts we discussed, your, 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, it's a six months, six month window. And if you haven't canceled that claim within that six months, we Assuming that you, you are no longer here, we then deliver that package to your benefactor so they can decrypt. But it, it does contain the app private key. And I think covenants through like, you know, the delegated signing feature might allow us to remove that, the app key and just let the benefactor, you know, 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 enforced by our policy. So I think there might be something interesting there we still need to dig into." }, { "speaker": "clay_garrett", "time": "41:01", "start": 2461.0, "text": "We haven't, you know, sort of 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 Bitkey 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, you know, the arbiters here. We just do it when there's no other option. So," }, { "speaker": "clay_garrett", "time": "41:24", "start": 2484.0, "text": "Yeah, I think that's a really interesting possibility as well." }, { "speaker": "stephan", "time": "41:28", "start": 2488.0, "text": "Yeah, interesting. And so, and I think the other one that often gets brought up here, now James OB had this idea of Op Vault, and I believe that's now kind of been superseded by Salvatore Ingala's idea of Op CCV or Check Contract Verify, and I think that would enable like a really 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 listeners 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. SoYeah, also we touched on this earlier, but chain code delegation, it 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?" }, { "speaker": "clay_garrett", "time": "42:09", "start": 2529.0, "text": "Yeah, sure. So a chain code is what essentially allows you to, you know, as you're deriving wallets in an HD wallet, it, it's the mechanism that you need to be able to, you know, derive addresses without the private key. And right now in a traditional 2-of-3 multisig setup, all members of the, of the quorum have the chain code. So it's, you know, it's a part of the descriptor of the XPUB. And so what that means is that any, you know, recovery service today or any party that's, you know, within your 2-of-3 has the capability to see all of your on-chain activity. And when we launched Bitkey, we were no different. We had that capability as well. We didn't want that, so we really worked hard to remove ourselves and invented something called chain code delegation. And so basically the app withholds the chain code fr, 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 app to calculate the, just the minimum necessary data 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 implemented that. It became a BIP, it's BIP 89, 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 Biki after that moment, we're, we're blinded to transactions that," }, { "speaker": "clay_garrett", "time": "43:44", "start": 2624.0, "text": "That we are not a part of signing. So 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." }, { "speaker": "stephan", "time": "43:56", "start": 2636.0, "text": "Yeah, I think it's probably an under rated 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, that's the one where Block would know the user's coins in terms of how many they have and where they, where they are on chain per se. But, really interesting benefit there. So I guess we covered a bit there, so I'll just kind of walk it through at least how I understand it and listeners, you know, maybe that'll help you as well, cause 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 you might be used to other hardware wallets, like you might be thinking of like BIP 39, write 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 mentioned, 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, index two, et cetera. And so what, what, what we're doing in this case with, or 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, is blinded to Block per se. And instead of the user giving Block his full chain code, he's, he's giving them a tweak for the recovery transactions or the inheritance transactions so that Block can co-sign for the user." }, { "speaker": "stephan", "time": "45:29", "start": 2729.0, "text": "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 all his addresses and balances to Block's, to Block." }, { "speaker": "clay_garrett", "time": "45:44", "start": 2744.0, "text": "That's right. Yep. Nailed it." }, { "speaker": "stephan", "time": "45:47", "start": 2747.0, "text": "Gotcha. Okay. And then, Electrum servers. So you touched on this before about how there are, you know, other servers. It's not, can you talk to us a bit about that? And I, 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." }, { "speaker": "clay_garrett", "time": "46:10", "start": 2770.0, "text": "Sure, yeah. By default, Bitkey will connect to one of our third-party Electrum servers. It's either Mempool or Blockstream. And that does not route through Bitkey servers, so it goes, you know, directly from the app to those third parties. And 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 actual, 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 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 not a one-click-and-done type thing, but we've definitely had customers who, who, who have done it and use it. But, you know, if you're using any other, you know, you, 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 sort of self-signed. We have looked at the option of just allowing you to bypass the TLS requirements. We just, we want to do it in a way that customers really understand the trade-offs because if you're sending non-TLS traffic, you need to make sure that you're doing it in a way that's secure, like, you know, Tailscale 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." }, { "speaker": "clay_garrett", "time": "47:44", "start": 2864.0, "text": "But, you know, Bitkey doesn't have a way to validate that you're using Tailscale 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 transaction Activity to anyone that's watching 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." }, { "speaker": "stephan", "time": "48:14", "start": 2894.0, "text": "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 guardrail for people, but there are people who maybe 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?" }, { "speaker": "clay_garrett", "time": "48:34", "start": 2914.0, "text": "You know, that is actually, I don't know that we have discussed it. Now, I joined the team, I think, about six months after the project started. So, you know, part, 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 I, 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 addresses with a, with a node or an Electrum server that you are interested in, which essentially, you know, gives them full view of your wallet, you would, you would sort of get, ask 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 data of your wallet without a third party knowing exactly what your wallet is." }, { "speaker": "clay_garrett", "time": "49:27", "start": 2967.0, "text": "I don't, I can't think of anything technically that would prevent us from doing that. If I understand it correctly, it does push a lot of the hashing to the client side and on mobile. For example, if you didn't log into Bitkey 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 privacy, I think that's really interesting for us to look at." }, { "speaker": "stephan", "time": "49:55", "start": 2995.0, "text": "Yeah, I think that's, I think that's my understanding as well that basically there are some wallets that do do this, but there is a trade-off, as you said, that it pushes more to the 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, 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 neobank or my, you know, or 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, where are my coins, right? Cause 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 Electrum or Sparrow and they're looking on the wrong, the wrong input. They're looking, 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, there are trade-offs of that, but, nevertheless, yeah." }, { "speaker": "clay_garrett", "time": "51:01", "start": 3061.0, "text": "That, that loading moment when you first open up a wallet is, it's especially tricky for self-custody, I feel like, because if you just show the cash balance, well, 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 wind up, 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 tried to work hard to make sure that that experience is as good as it can be, but it's, it's chock full of trade-offs in itself." }, { "speaker": "stephan", "time": "51:39", "start": 3099.0, "text": "Yeah, I see. So, I guess, yeah, I'm just sort of thinking about what else there is. So, in terms of, yeah, where, 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 Coldcard thing, Liquid, I think, I think Bit, Bitbox had some vulnerabilities, Core Lightning had some vulnerabilities, Boltz.Exchange, like, I mean, there's so many, I'm probably forgetting some. What, what are your thoughts on all that? And like, you know, what does" }, { "speaker": "clay_garrett", "time": "52:08", "start": 3128.0, "text": "It mean for the industry, for Bitcoin security? I think anyone who says that things haven't dramatically changed, they're not being honest with themselves. I'm not saying anyone has said that, but just, you know, as a way to start the topic, it's, it's changed dramatically. And I think many of us are still reckoning with what it means and how 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, 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, are, are going to find ways to do. And, but, you know, I also think that it, 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, 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, what's 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 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 offset that with, you know, ways to build faster, more effectively with LLM. So it's not like we're just necessarily, 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" }, { "speaker": "clay_garrett", "time": "53:43", "start": 3223.0, "text": "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, it, it, I would be surprised to find any, any major player in this industry that was sort of just proactively building that way, you know, on purpose. But 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, making sure that you are solid from the ground up is really, really important. Constant scanning of your, 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, 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, every company's 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 ask me again in three or six months. Let's see what's changed. Yeah, it's, yeah, it's been pretty crazy." }, { "speaker": "stephan", "time": "54:47", "start": 3287.0, "text": "So, I mean, 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, multisig 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 ETF and custodial and that's it. Where, where does Bitkey fit into all this? How do you, yeah, how do you, yeah, fit Bitkey into that?" }, { "speaker": "clay_garrett", "time": "55:21", "start": 3321.0, "text": "You know, I think a lot of people still don't fully understand that when you buy a Bitkey, you're not just, you're not just buying a wallet, you're actually buying a, you're buying a wallet that comes with a service that's free for life. And so, you know, we are a recovery co-signing service and there's not a monthly fee attached to it like there is 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 industry is very much DIY. It's like pick and choose your parts and go build your own car, you know, versus going to a lot and figuring 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 not have that option. So I just think that we need to all as an industry be willing to challenge our past ways of thinking when we hear from customers that this thing is really hard, right? This thing is stressful. You know, in the wake of the Coldcard incident, there was a few different podcasts I listened to 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, you know, we should just trust customers more and they'll figure it out." }, { "speaker": "clay_garrett", "time": "56:47", "start": 3407.0, "text": "That mindset, to me, doesn't feel like they're out there really talking to customers, because that's one thing we do a lot is talk to customers and, you know, on 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 where Bitkey sits right now is 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 coalition that helps build alongside us. For the customers who need it. And then I would just say, I'm, I'm glad we live in a 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 a seed phrase is a beautiful thing to someone who is ready and equipped to use it. And, you know, it crosses borders and would never want that to change. In fact, we're also even looking at options, for example, for seed import into Bitkey. And obviously, if we have third-party hardware, then that would come with a seed as well. So We're really taking the post Coldcard era as a time to reevaluate everything that we've built so far and see where the option spaces are to get kind of, and continue to expand what Bitkey can be." }, { "speaker": "stephan", "time": "58:08", "start": 3488.0, "text": "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 have, you know, maybe we get so trapped up or so caught up in how we're used to doing things, we just kind of expect everyone to just be able to figure it out. But it's just not that simple, right? Unless you're going to actually invest the time and the money, potentially," }, { "speaker": "clay_garrett", "time": "58:32", "start": 3512.0, "text": "To," }, { "speaker": "stephan", "time": "58:33", "start": 3513.0, "text": "To really do that. And I guess, you know, for people who aren't, you know, diehard Bitcoiners, that's, that's a bigger ask for them. So, yeah, I appreciate what you guys are doing. I was, you know, I was a bit more critical of Bitkey V1 with no screen, because I was a bit like, oh, what are you signing? How, how do you verify what you're actually signing? Bitkey V2, I mean, hey, you've got a screen. You can, you're verifying, you're clear signing something there, and you have an interest Mix of, you know, easy recovery, but also easy use. And hopefully the users are not going to get, you know, scammed or malware or phished 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. Like you could have some in this solution and someone in another solution and, you know, maybe you got some here cause you're doing some other thing that like you're doing a Bitcoin collateralized loan there or you have other things. So all these are, you know, options for people. So yeah, just finally, listeners, you can find the guys at bitkey.world and Clay, your handle was @clay_garrett, was it?" }, { "speaker": "clay_garrett", "time": "59:41", "start": 3581.0, "text": "Yep, that's right. On X. There we go." }, { "speaker": "stephan", "time": "59:43", "start": 3583.0, "text": "All right. Well, I think that's all from us. So thanks for joining me, Clay." }, { "speaker": "clay_garrett", "time": "59:46", "start": 3586.0, "text": "Hey, thank you so much, Stephan. I appreciate it." } ] }