Bitcoin Vaults & Custody

Hi and welcome to the Stephan Livera podcast focused on Bitcoin and Austrian economics. Today, for episode 108, we are carrying on with the Bitcoin custody series with the well-respected Bitcoin developer Bryan Bishop. But first, let me introduce the sponsors of the podcast. So firstly, Kraken, one of the world's biggest and best Bitcoin exchanges. You guys are Know I like the way they operate, they've really impressed me. They've got a really strong focus on security and as an exchange, they've really acted ethically in the space under Jesse Powell's leadership. They're one of the longest standing exchanges, they're consistently rated the best, they have some of the best liquidity available in the industry, they've got high trading volume and low fees. They've also got twenty four seven support and on the institutional side, they are providing best in class accounting, reconciliation and reporting. Services for cryptocurrency hedge funds, asset managers, and fund administrators. Kraken have an OTC desk for those higher touch large block trades. They offer five fiat currencies and also offer margin and futures trading. To learn more and sign up, go to the Kraken link in the show notes. Next up, look into Unchained Capital. They're a Bitcoin financial services company offering a multisig two of three keys vault and also offering Bitcoin collateralized loans. So on the vault side You can use Trezor or Ledger, you still maintain control with your two keys, and Unchained Capital would be the third key or co-signer in that case

that you need them to sign as well. And there's a lot of work being done on this, and open-source contributions coming from Unchained Capital, so look out for my upcoming episode with Dhruv Bansal from Unchained Capital, where we will talk about some of this stuff. Also, on the Bitcoin collateralized loan side, Unchained allows you to get USD liquidity without selling your bitcoins, so consider your own scenario, but this might be more tax efficient for you. If you wanna learn more and sign up, go to the Unchained Capital link in the show notes. So carrying on with the Bitcoin custody series, so we started on SLP 106 and we were talking about Glacier protocol with Diogo Monica, and in episode 107 with Casa CEO and CTO respectively, Jeremy Welch and Jameson Lopp, we were talking about the Casa wealth security protocol. So today we have Bryan Bishop, on Twitter you'll know him as at k a n z u e r. He's a well known Bitcoin developer, he's got a wealth of knowledge when it comes to Bitcoin stories. Owing to his years of experience working at LedgerX previously and as a consultant nowadays. So in this interview, we touch on vaults, Shamir's secret sharing, hardware, Smart Custody, transcripts, as well as transhumanism. Onto the interview. Bryan, welcome to the show, man. I'm a big fan of your work. Thank you, I'm a big fan of yours as well. Yeah, so look, we're doing Bitcoin custody, I know you're one of, you're one of the guys to talk to on this exact topic,

and so maybe we, we'll just start with a little bit of a background, what was some of your work with LedgerX, and then wh-what's some of the work that you're doing more recently?

So, I started at LedgerX in two thousand and fourteen, and it was a pretty interesting experience. I ended up staying there for four years, and I left, just about one year ago exactly from today.

and, you know, I was super interested in what they were doing because I had actually previously looked into clearinghouses, and I was trying to figure out what does it mean to be a clearinghouse when you have Bitcoin. Like, how does Bitcoin change the financial system? And clearinghouses are a very important part of the financial system. they're, they're often where systemic risk is aggregated and things like that. And, so when I saw LedgerX and we got to working together, of course I wanted to team up and join because I thought the, the mission was and is important,

And, it was just a, very interesting experience. I mean, as you can imagine, Bitcoin's a very unregulated asset in general, like fundamentally, even philosophically. And, on the other hand, if you wanna be the first federally regulated Bitcoin options exchange, like LedgerX did, and- As they became, then you're very regulated. So on the one hand, you have something unregulated and something very regulated, and it was just a, it was a fascinating experience.

Yeah, so actually it might be interesting to dig into that a little bit. What were some of the-- I think it would be interesting for the listeners just to understand, because back in twenty fourteen, I'm sure the ecosystem was much less developed, and some of the good options in terms of custody at that point would have been things like offline armory, right? Things like that, that was what people were doing then,

Built out, you know, there was no Glacier protocol then. What was the thinking then, and how has it shifted to now?

Well, so, I mean, first, at any startup, you, you really don't have any idea whether this thing is gonna work. And at LedgerX in particular, the, the, the bet or the gamble that was made was that the CFTC would end up being the correct regulator for this startup. And also that this startup would be able to secure the licenses required to operate as a, as a, as a clearinghouse for, for Bitcoin options. And anyway, it turns out those bets, definitely paid off. it just took a few years for them to get there.

many people aren't aware of that, that they actually did, get licensed, years ago to, to operate as an options exchange for Bitcoin.

as part of that, all of the contracts are physically collateralized with, with physical Bitcoin, like real Bitcoin, that's custodied at LedgerX. And that was one of the big projects that I was, part of and responsible for was, secure storage of Bitcoin

Right. And so what was some of the thinking there, and how did that sort of change? Were the things that you were working on then, in those days, did they become sort of formative in terms of how the rest of the industry is looking at it now, or did it, did the, did the thinking shift a little bit?

So there, there's definitely some things that I would consider to be, standard or, or a part of any good design for a system for storing Bitcoin. And that, that's actually around the human processes around storing Bitcoin, like checklists, documentation, something that I call the signing ceremony or signing ritual, and, those things, tend to be something that, that every company should do. Now, there were also some, some technical choices made and design decisions that looking back would I revise them, sure. for example, I am greatly embarrassed that, we had to wait until Andrew Chow to have, partially signed Bitcoin transactions as a BIP one seventy-two Before, you know, we ended up-- we were doing something quite similar, I just neglected to figure that it should be standardized, and that's, that's profoundly embarrassing, but it's a good standard, it's a very good idea, we should definitely be using partially signed Bitcoin transactions in that encoding format

Yeah, that's fantastic. and just for any listeners who are unfamiliar, make sure you go back and check out episode ninety nine, where I talked to Andrew Chow about PSBT, partially signed Bitcoin transactions. but Bryan, back in those days, as I understand, I, I recall there was, you know, offline armory, right? And there was something sort of close to it, but it was like its own thing, right? It wasn't like a gen-generic,

what's the word, serialized wallet interchange format that you can take from one wallet To a hardware wallet to other pieces of software to sort of jointly construct a transaction that works.

Yeah. So when I talk about this, armory comes up often and,

I thought I knew Armory, but I get the sense that, if you go back and look at Armory, you're always gonna find something new that they thought of first back in twenty eleven, basically. So it's, it's an interesting archaeological expedition, I suppose.

Right, yeah. And so let's just get into, I guess, what, what's some of the later work that you've been doing, since leaving LedgerX? What, what's been your focus?

Well, I've just been doing a whole bunch of consulting and contracting in the Bitcoin space, and this goes, across the board from things like basic, like just basic consulting and strategy, but also things like code review, security analysis, Just peer review of software and systems that other people have developed, but then also things like doing architecture for new projects, and,

you know, I haven't talked about it publicly, but this also, includes a, stint at, Blockstream actually, as a, as a contractor.

Fantastic, the gun for hire. but I'm sure you've got a lot of different stories about, custody and cold storage. Might be, interesting now just to dive into a little more detail if, if you've- Got any horror stories for the listeners?

Yeah, I do have horror stories, and I'm, I'm saddened to say that. you know, the process of handling Bitcoin, as, as a developer, I am still somewhat terrified every time I do a Bitcoin transaction. It's actually, unclear whether you're really doing everything correctly, because if you do it wrong, it's gone. So for, for myself, I personally try to always test my Bitcoin transactions on like a test network. Before I actually do the real transaction. And I, I know it sounds burdensome, but for, large amounts of money, this does make sense. And unfortunately, I've heard for some particularly wealthy individuals that have bought into Bitcoin and who are famous in the, in the news for such actions I've, I've, through, through one of my projects, a, cold storage project, talking with people, I found that, it turns out that it tends to be the case that these guys don't come up with a plan, they don't have a good, strategy written down

and, and to me that indicates that they aren't operating their Bitcoin wallets as securely as they could be. In, in one incident that I'm aware of,

A, what I would describe a Bitcoin core developer was invited into a process where someone was securing a large amount of Bitcoin as an investment, and they, were introduced to a whole team of other people that, that- In my opinion, you know, they were definitely not Bitcoin core developers, they were just other people, you know, friends of the family or something. And, you know, just basic things like, "Well, send me a PGP-signed message of the, of the signature of the-- oh, sorry, excuse me, a PGP-signed message of the, the address or keys you want me to use." And like the other individuals involved had no idea what that meant. So There, there's just basic human training that has to occur to get this right, and that's, that's very much something I'm focused on right now. Software can definitely help, but there are still human steps and actions and checklists that have to occur.

Right. So let's break that down a little bit. So the, the,

I guess the procedure you're referring to there is a signing procedure. Can you talk through what's normally required? So in particular,

let's say that you, have a team that's distributed and someone has generated a new key And they are communicating that key to you, the public key of course. They keep the private key and they communicate the public key to you. How do you know that when that data arrives at your machine, that that data hasn't been tampered with? Well, one way that you can do this is using PGP-signed messages, where you sign a message indicating, cryptographically that, this was the, in fact, the true message, and it becomes unforgeable for adversaries who don't have the private key.

Yeah. So this is like that example where you might want to-- I guess, you're getting at this idea that you wanna verify that it truly is their signature or that it truly is their key, and you might need to check that not through one channel, but through different channels, so it's harder to fake

that You know, one thing that I've been thinking about, and I'm not ready to move on it, but there should be a standard in our community and industry for, signed withdrawal requests, for Bitcoin exchanges, where users, submit a signed, cryptographically signed message indicating that they really do want to withdraw from the exchange. This way, exchanges can, verify that these withdrawal requests are legitimate. Because right now, I mean, the only way that these exchanges really verify it is, as far as I'm aware, phone calls and emails and video chat.

Right, so it On the exchange to verify that the user did truly want to do the withdrawal and that they wanted to do the withdrawal to this specific address, when really, if a hacker or an attacker knows that, once they've compromised the exchange website, then they could do all these sorts of different tricks like replacing the address with, which, which is, inserted into the website so that they can sort of hijack the withdrawal, or they might do, like a hijacking the deposit as well. I guess that's another possibility if somebody goes to the exchange, they- They ask the exchange, "Oh, give me an address for me to deposit into, " and then at that point, they could get hijacked and send bitcoins to the wrong address, the hack-- the hackers or the attackers address. That's right. Although that's a different problem.

That's right. So there's one particular security aspect for exchanges that I've been, recently popularizing some thinking around. In particular, I've been looking at exchanges that get hacked, and they usually have hot wallets, and the hot wallets get drained. And my observation here is that when an attacker gets into a web server for an exchange, it's not the case that the exchange developers were dumb enough to put the private key to their wallet right there on the same web server serving up the exchange that the hackers got into. Instead, what usually happens, is that the attackers get in and there's a signing server of some kind where Bitcoin transactions get signed, and maybe it checks a database of withdrawal requests or something, or maybe it checks some other indication, and then it signs the, the transaction. So based off of this, I, I don't think that just withdrawal requests alone is enough, because unfortunately an attacker could insert, withdrawal requests into a database. And so instead, I think, something that we should really be looking at is this idea of, what I call a restricted signing server. And basically what this does is it says, okay, I will actually sign anything that is given to me on condition that the output script in the Bitcoin transaction matches a specific- specific output script template, and that output script template is the following. It's the exchange is allowed at any time to immediately recover the funds to a cold storage wallet or relative,

relative time lock delay and then the key that the user is withdrawing to. So that could be the user's legitimate key or the attacker's key. And the idea is that this transaction gets broadcasted, and it, it only gets signed in, in the event that, the output script exactly matches that template I just described. And then it gets broadcasted, and the exchange has whatever that delay period is, maybe two days, maybe one day, to watch on the blockchain, and if that destination key doesn't look right, it's allowed to revoke that, those funds, and return it to cold storage for the exchange. I think that will significantly reduce the, the, the, the, consequences of theft attempts at, at exchanges that get hacked.

Got it. let me just think that through in my head again. So what you're saying is there would be a relative time lock placed on that transac-- on the outgoing transaction from the exchange, and the signing server is only going to sign it in the case that it has this particular scripting i-in the way that the transaction is crafted or- Constructed, let's say, and you're saying that if, if there's something suspicious, the exchange might withdraw it to a given cold storage address that the exchange knows it has under its own control.

That's right. So this requires the exchange or even the users to be monitoring the blockchain to watch for those potential transactions.

Right. And so I suppose in that case where, let's say, the exchange later figures out, oh, damn, actually there was something wrong, we think our customer got compromised. It's actually an attacker address that we're sending to, then in that case, how, how would the, exchange spend it back to the, back to its own safe address, if you will?

So there's a few different ways to do that. one is that, one possibility is to have pre-signed transactions that could be broadcasted that can do the recovery, and they're signed at the same time as the other transaction is signed. Or you can,

possibly, like you want the delay to be long enough so that you can go to the cold keys and make that transaction, so that's another op, another option. there, there's a few ways to do it. Got it. And so

is that related to your vaults proposal or is that separate?

It is related, and I, I've personally been finding it challenging to determine how related it really is, whether it's the same idea or not of my vaults proposal. And so the vaults proposal, interesting story. the one that got written up in the media is technically broken, but I quickly published an email afterwards, indicating a, a less broken version.

but yeah, I mean, basically the idea of a vault is to have that revocability period. The, the problem though is that in Bitcoin today, the-- previously the only known ways to do that revocability period was using something called a covenant, which would require a soft fork or a hard fork to implement in Bitcoin. what a covenant is, is it's just an extra restriction on a Bitcoin transaction. You know, you can think of a, of a, the requirement of a public key and its private key signing as one form of a restriction or covenant, but there are more advanced covenants that people have imagined that say only transactions that look like this format are allowed to spend this output, things like that. Anyway, I was thinking about this, and I figured that there's,

I figured incorrectly that there's partially a way to do this with pre-signed transactions without requiring a fork on the network. And the flaw in my proposal was that essentially you presigned this huge tree of transactions where you can keep bumping it into the future if you want, until the end of time, you know, because relative time lock and you can just bump that out

and in particular, if, if an attacker,

steals some of the coins, you get to revoke the rest to cold storage. The, the original flaw in the proposal was that it was, unfortunately assuming that the attacker would voluntarily tell you that the attacker has stolen your information

and unfortunately that's not a reasonable assumption. the, the updated version is, is,

such that it has the following property. The property is that it is a vault where If you set it up in this way, a theft can be detected and you will lose at most one percent of your funds. So I can't prevent one hundred-- I can't prevent, the, the thief from stealing at all, but I can limit the amount that the thief is able to steal So the way that this works is the following. There is a Bitcoin transaction setting up this vault. there's some inputs, and then, in, in one example, there's one hundred outputs, and each output has one percent of the funds. Each output has the same script template that I just described for the restricted signing server, the one where there's an immediate recovery to cold storage available as a possible route. Or a relative time lock spending to some key, and that key is predetermined at the time that you set up the vault. And so the concern is that between the time that you set up the vault and the time that you broadcast this transaction, it's possible that an adversary has stolen that hot key that was, already baked into this whole scheme. And so what this is doing, oh, and there's one more thing, there, on each of the relative time locks and each of the one hundred outputs, each one is one day further into the future. So on the first day, one percent is available, on the second day, one percent is available, and so on.

and the idea is that, you have to sign a transaction during that one day to take that one percent. And if an attacker does it, it indicates that, first of all, the attacker has the private key And you should use the recovery method on the other ninety nine outputs. You can do it at any time. If he steals the first one percent, you do it for the other ninety nine outputs. If he steals the second to the last, you do the recovery for the last one percent, and so on.

anyway, what this does in effect is it limits your losses to one

percent of your total funds. Got it. And so the exchange or whatever service provider is, you know, doing this, using this vault construction, they would presumably be watching the chain to make sure that it hasn't gone to the wrong address or ba- or maybe more likely, the customer would come to them and say, "Hang on, I did this withdrawal and it didn't come to me, what's going on?" And at that point, you would tick off and go, "Oh, okay, maybe we need to now or not, rather the other pathway, the immediate spending pathway, to spend it back to their own cold storage, correct? So

I might need a better name for this, but I've, I've personally been calling it like a watchtower. So the, the users of this scheme would, require perhaps multiple watchtowers to be monitoring the blockchain and even taking actions on their behalf if they don't otherwise trigger some tripwire switch saying, "Please don't, you know, please, I'm actually trying to withdraw my money" or, or whatever it is.

yeah, all, all of the proposals that I just described require something like watchtowers or given another name. the other interesting thing is that actually the, the method that I just described for vaults and losing at most one percent was actually, developed for the purpose of personal cold storage. I sure, I'm, I'm sure it does apply to commercial cold storage and custody, but the dynamics might be a little bit different. As an example, there's something similar to trusted setup in- in my scheme, in particular, if you choose to do this with multisig vaults, where multiple people come together to set up these, this vault scheme, or even, yeah. Anyway,

the requirement is, that at least one of the members of this multisig group deletes the key, because if you don't delete the key, then it's possible for another transaction to be signed that avoids the vault structure. So this is the pre-signed locking covenant mechanism, right? And the problem with this is that this in of in, one must be honest, one must honestly delete the key, is that in a commercial context, I'm not sure that businesses are willing to make that assumption that someone really did delete the key. In a personal cold storage context, I can certainly trust myself that I destroyed the hardware that just had the key. So I think that's a slightly more reasonable assumption. In a commercial context, I'm not so sure.

Right. I mean, potentially that could become part of some kind of signing ceremony or ritual, like if everyone watches that person, you know, delete the key. but I suppose you're right, there could be some way that they've tampered with the setup such that they actually maintain a copy of the key. And how do you prove they've deleted every single possible copy Difficulty you're getting at.

So the, there is, one idea I've been toying with that might save the commercial custody case for, for a scenario where you have to delete keys is, models more like, Green Address two of two, where one, where the user has one of the keys. And so in that context, you can still probably trust the user to delete the key if you ask them to. So I think that might be reasonable.

Okay, and I guess let's sort of bring it back to the, I guess the- I guess it's, it's just so scary, right? There's like, there's just so many things you don't know who you can trust, so you just sort of have to try and figure out,

ways to kind of make yourself safe from multiple angles,

I know you were also keen to talk about this idea of a bit flip horror story. Can you tell us what is a bit flip? So, okay,

in, in computer security and in Bitcoin in particular,

A hypothetical but very real concern is that there are things in this universe called cosmic rays, and they are high en-high energy particles that, sometimes tend to intersect, computers. And when they intersect computers in certain ways, they can cause a bit flip, and this is called a bit flip error. And so when thinking about different security protocols and different software implementation, being able to protect, protect against these problems is very important. So techniques like checksums are, are definitely helpful and other things like that or, ECC memory and so on.

but yeah, I mean, it is a big concern, and that's part of the reason why I mentioned earlier that even when doing Bitcoin transactions, I personally can feel terrified from time to time. It's this idea that there might be a single error, just one little bit flip somewhere, that might completely break something or, and it's just very hard to get this right, which is why we need open standards for cold storage and wallets and so on. We, we need to get this right as a community and certainly for people who aren't developers and understand some of these things.

Gotcha. And with that, that actually brings to mind, Glacier Protocol as well, right? So this is address reuse, right? Where actually as part of Glacier Protocol, they actually do use the address just to be sure that you can actually spend from that address. But then the downside is there is a privacy trade-off there, because you are now reusing the address, it makes it easier for an outside observer to now link those transactions or to try and infer something about how, you know, what somebody is doing with that address. And potentially that might be one piece of the puzzle that helps them understand, I know Bryan is securing his coins using X, Y, and Z protocol, or he did it at this time, where was he at this time? Things like that, right? They could try to start using that information.

So Glacier Protocol was a very interesting approach with, basically written documentation with steps for what software to run and how to use it. And I, I think it's, it falls a little short in that I think the, the ideal solution would be both, a lot of checklists and written documentation and steps and even videos and even com- paid training services, but then also a, additional software to help you walk through all the steps as well. I think that's a very important piece of it. In fact, I've been working with Christopher Allen on, his project Smart Custody dot com, which started as a series of workshops around the question of how to secure assets for consumers. And, in particular, the workshop, started with, just a full day of walking through various hardware wallets and adversarial modeling about what are the possible threats and you know, for each person that's different, and depending on which threats you're particularly concerned with, some of the different hardware choices get made.

Yeah, there's so much with that because, I guess, yeah, part of it is also how easy is it to use multisig, what, and what hardware do you use and, Also, it's that idea of,

fighting against bit rot, right? So, so sometimes in certain models that's used, that's why multisig is used as well, that, you know, for example, in the Casa model, they go seedless, and the idea is that, you know, you've got three or five, whereas perhaps with other models, let's say the Unchained Capital model, where they're going two of three, and Unchained holds one of the three, then, you know, it's a slightly different model. How do you think about

Seedless versus backing up seeds, because I guess the argument either way would be, one would be, you know, if you're going seedless, that's easier for the customer to think about and less possible things to protect, because now you've got to protect the backup seeds for each of those, but depending on how many pieces of redundancy you have The seed might be required, or a, or obviously in a, in a single signature hardware wallet scenario, then obviously you do need to back up the seed. So how do you kind of think that through in terms of the trade-off decision there?

Well, unfortunately, I don't have an answer for you, but I can definitely talk about those trade-offs. I think Klaxman in particular is fond of mentioning that for the case of single-sig setups, it's actually, you know, one of one, okay, well, really it would be better to do one of two multisig. And the reason for that is bit rot and hardware failures, and if you're one hardware wallet fails in a one-on-one setup, well, now you're out of luck, especially if you didn't have a, a seed written down. so in that case, if you're doing one of one with a hardware wallet without a seed, you should be doing one of two multisig so that you have two devices, and if one fails, you're okay. If you do two of two multisig and one fails, and you have no seed backups,

Then you're in serious trouble, right? So, yeah,

the, the question of seedless versus, writing down seeds, yeah, it's a, it's an interesting one.

I, I can definitely see, merits both ways. So when you have a seed based backup system, one of the questions that I end up always having is, okay, so I've put a hardware wallet in a vault, in a safe somewhere. And now I have a seed that I'm gonna write down, a recovery seed or, or other recovery system. And of course, you shouldn't really be putting that in the same vault. It increases the complexity, right?

Yeah, I think, I think that we're a long way from having a single, standard,

you know, standard of care and quality, for these procedures. just producing hardware wallets isn't enough, there needs to be a broader, broader system and mechanization around this.

Right. And I guess I might also ask you this now as well, as I know you're a little closer to the Bitcoin core developers, obviously as you run the list and everything. I've noticed that some Bitcoin core developers are a little more, let's say, skeptical of hardware wallets. Can you articulate why that is and what they would recommend instead? Well,

okay, so many of the hardware wallets are developed on the basis of, of like this idea that they're consumer friendly and easy to use. So that's one thing.

the, the security claims of hardware wallets, are certainly open to, to analysis and criticism. And there's a big question as to whether, hardware wallets are really a great idea or if you can get equivalent security with regular commodity hardware like just laptops stored in vaults that are air-gapped and never connected to the internet. So on the hardware wallet side, in particular even hardware security modules, the argument is that you have tamper-resistant, tamper-proof, tamper-hardened hardware That makes it extremely difficult for an attacker to extract secret data from. However, in hardware wallets on the market, it's not necessarily the case that all of them use that. Some of the, these hardware wallets are actually more, along the lines of And consumer friendly interfaces more than anything else, and with some, some amount of security of course, as a consequence of not having keys on your, your computer.

It, it remains to be seen if, secure enclaves or trusted execution environments in hardware security modules are really advantageous compared to using multisig with commodity hardware stored in multiple locations. One of the ways that I look at this is I call it, you know, the, the, when thinking about the philosophy of cold storage, I call it, multi-factor difficulty. That's how I assess cold storage. You know, what does cold really mean? It means that there is, there are multiple different types of difficulty factors for accessing and using this cold storage, whether that's, secrecy of the location, geographic distance, storing in multiple jurisdictions, or even, access procedures like a heavy door or something. you know, if you have a heavy door for the vault, maybe Grandma isn't gonna be able to be a thief, you know, it eliminates some of the possible attackers, you know, because Grandma can't open a two hundred pound door or something, I don't know.

so yeah, so you need, you need multiple different types of difficulty. And this is actually similar to,

multisig, in fact. you know, one of the recommendations I've been making lately is that if you have multisig, and in particular, multi-party multisig with a number of your friends and colleagues or something, I actually believe it's important to have, a group of people that have a mix of motivations. For instance, maybe some business colleagues, maybe some friends, and then maybe some family members, because your family members have very different motivations regarding you than your, possibly your friends or your colleagues. business partners, may respond differently to you being coerced than your family members. Family members just want you to get back safely. Right? And business colleagues, you know, maybe they just want your money or something, but, you know, they, they certainly w-uh, aren't gonna respond in the same way to a family that will do anything to get you back in the event that there's, there's funds at risk.

in fact, along that, mix of motivations recommendation, the other multi-party multisig recommendation that I think we should all be making is that if you have multi-party multisig, you should be regularly testing, your, your multi-party participants. And by testing, I mean things like, if you ask them to help sign a transaction, do they actually verify over a secondary channel or, or third channel that you really intended to do this transaction? And if they don't actually do a good job with that verification task, you should, you should remove them from the multisig group.

Yeah, no, that's, that makes a lot of sense, right? It's, it's not just literally checking the health of that key and checking there's been no bit rot of the key, it's also the Security practices and awareness of the individual who's holding that key.

That's right. And so for, for that test, one thing I've been thinking about is that, well, what do you ask them to sign? And you could ask them to sign garbage, that just wouldn't work at all. Or what you do is you ask them to sign a transaction that moves all of the funds into a new multisig setup that they aren't included in. And so if they do sign it, unintended, then,

yeah. But that's almost the opposite of the, oh right, so if they do sign it, then, yeah, gotcha. So, for a second I thought it was like the other way around. So then it's like, if, if she, what's the, what's the one? If she drowns, she wasn't a witch, and if she's alive, then she is a witch, and let's burn her at the stake or whatever. But I guess it's the other way around

I think the other component that's difficult with some of this, and this is mentioned in the Smart Custody book, and I might even mention it with, Christopher Allen and ask for his comment on it, is this concept of process fatigue, right? We can design the most amazing protocol, the most, you know, complex- Procedure, but then the reality is, if people don't spend the time to read and understand that procedure and to correctly execute it every time, then there is that risk of process fatigue, and I suppose, you know, we are human, we're fallible, we can make a mistake on these things. Have you kind of seen any examples of that or you've witnessed that in your own, Bitcoin storage and Bitcoin journey? Oh, no, I never get fatigued, no.

but, but for this problem in particular, in my opinion, software should be doing a lot of the work for you, and then the user should only be required to do certain things that software isn't capable of do-- doing, like moving a laptop from one end of the vault to another or,

you know, like not, not even necessarily finding a place to store a vault or, or a bank with a safe. You know, that could be automated by software as well. it just happens that, banks, don't currently support that kind of feature. but yeah, it should be

That I've been having is that,

you know, in, in modern society,

gamification of, of all sorts of loot boxes and so on has, has really just been completely psychologically addicting and even devastating. It would be interesting if we could apply that actually to fight process fatigue, because it's very interesting that someone can like click a single button on a phone as a-- and consider that a game, you know, all day. but at the same time, there's this other process fatigue of, of running through checklists and everything. So maybe if the two can be combined of like checklists but also gamification or something through that software that I mentioned, then, then that might be something worth doing. But all of this really requires, empirical testing. You know, we need to collect large amounts of data from people trying different ways of securing their Bitcoin and seeing what happens. Are people able to follow these steps? Are people able to protect their assets? And if you follow up a year later, do they still have them? Or did they decide, well, that step was complicated, so I've just been, you know, storing my passphrases on a sticky note on my, on my front door or whatever? You know, we need to collect this data and find out.

Right. Yeah. And I suppose to, to one of the points you were saying earlier, it's around standardizing or what is the standard of care. I think that also flows into this idea of levels of security, right? So at the start, people, you know, if it's like forty bucks or whatever, they can leave, What do you think about trying to, create levels, if you will, on how paranoid to be, how much work to put in at each level?

Well, that's a hard question, but I'll give you some cyberpunk perspective on this, which is that cryptography is an incredible tool that, that gives you basically asymmetric power, meaning anyone can generate a, a, a forty-ninety-six bit key and encrypt data and, you know There's no way to break that computationally right now, and anyone can do that, any, almost any smartphone can do that, right? That is a, an extremely powerful tool,

Another example is, another way to, to cheaply create these kites, types of cryptographic secrets is, something that I've been calling "delete the bits," and, Adam Back introduced this to the Bitcoin community a long time ago on Bitcoin Talk and cited even further history where other people had come up with this. But in "delete the bits," the idea is that you have a secret and it can be decomposed into a collection of bits. And, you delete some of them, and then you store the, the shorter version. What this does is it forces you to do a brute, brute force parallel search to recover the original secret, which has some amount of cost. It's kind of like the delayed, time lock encryption from Peter Todd.

And, by doing this, you know, you can, you can make a secret that costs a million dollars in computational power to get the original secret back. And any phone can do this cheaply. The, the task of deleting bits from a string or a value is something that any phone can do very cheaply, and suddenly you have a way to create a ten million dollar secret right there. So I think that's really powerful, and the idea of having these levels of protection, I don't know if that makes sense. If you have a very cheap ability to make a very cryptographically strong protocol that is cheap and simple to use,

Then you might as well use that to protect even small amounts

of money. Got it. So it's almost breaking a little bit that idea that you should,

you know, try to increase the security as, as you go. And, I think I heard, I-- One good point I've heard is really that people have to think in terms of, What if their coins are worth ten times more than what they really are right now? Because that may be the reality given Bitcoin and, you know, the years to come.

also there is this problem of getting enough entropy or enough randomness in the generation of keys, because we as humans are fallible again, and we are too liable to,

repeating the same patterns and so on, generating insufficient randomness. And again, this is a topic mentioned in the recent Smart Custody book as well. Well, do you have any thoughts around, the use of the TRNG and random number generation in hardware wallets, and then doing things like, for example, with the Coldcard, how you can roll dice to add entropy, or in Glacier protocol, I think it, it involves, sixty-two dice rolls to generate some additional entropy?

Yeah, I definitely like the dice roll protocols, and in particular, one of the ideas that's been floating around in the hardware wallet community lately is this idea of A hardware wallet that has, multiple chips on it, like heterogeneous hardware from like multiple different manufacturers from different nations, and then you combine the entropy from multiple chips, because if you have a, if you have a, a random value and you add another random value to it, then it, it's gonna be random, right? Or if you add something non-random to a random value, it's random, that's just one of the properties of, of high entropy values.

so anyway, having multiple chips is an interesting approach, and the thinking behind that is that if you're paranoid that a government has backdoored your random number generator or has biased it in some way Then, what are the chances that the same, government has the same bias in all these chips from all of these different countries?

Right, yeah. And I suppose, I guess it depends how paranoid you wanna get, but, even if you're buying dice, you wanna make sure-- How, how do you make sure that the dice themselves aren't biased? That's right. Yeah, yeah,

yeah. I guess you wanna mix it with other entropy then, yeah.

Gotcha. and so- I'm also interested to ask around this question of hardware wallets compared with other constructions. So as I understand, there is the use of HSM modules or hardware security modules in some, Bitcoin custody contexts. How do, how do you think about, you know, the idea of, you know, I, I think this also kind of plays a little bit into,

like, for example, Trace Mayer is big on this idea of using purism laptops and using generic hardware as opposed to a specific piece of hardware, because if I see you've got a cold card, I know you've got Bitcoin. So, yeah, but I, I suppose let, let's just start with, the, I guess, the value of HSMs versus hardware wallets and the use of secure encl

Okay. Well, other than the, the previous things we talked about earlier, for commodity equipment, one of the interesting observations is that there are many different manufacturers that are making all of this equipment. So from a supply chain integrity perspective, you have the opportunity to go to many different stores, even in your own city, buy different laptops, buy different computers, and be reasonably confident that you have a, a good diversity across multiple supply chains.

going back to hardware security modules, I personally,

have questioned their utility and value.

in particular, the only hardware security module that I think really provides a lot of advantage is the one that has a form of tamper resistance, where in the event that it-- the system is physically tampered with, it deletes the secret. If it doesn't have this capability, then,

you-- I, I'm not sure it's as valuable as people think it is.

Gotcha. and what about this, concept of having an open-source secure element? As I understand, that's one difficulty, right? So, I understand the ledger has a secure element, however, it's closed source. there are efforts and thought, you know, being put into this idea, but as I understand, the cost is perhaps at this point prohibitive.

So As an example, in programming, you want to,

include mitigations for common attacks such as side-channel attacks. That's for software. For hardware, you also wanna mitigate side-channel attacks as well and a variety of other things. and that's where secure elements and secure chips come from. That's, that's their primary utility there. And the idea is that even from, you know, power analysis, voltage analysis, or other timing techniques to gather data, you won't be able to extract internal state- From those machines. And ideally, secure elements shouldn't be doing speculative executions, so Specter and Meltdown and other, other attacks that, that depend on, speculative execution don't work, which is a very fascinating one itself. if you're not aware of speculative execution, modern processors actually execute instructions before they're supposed to, to speculate about the outcomes because it's faster to do that, than to wait for data to be fetched from other peripherals on the, on the motherboard. And so as a result, computers are constantly executing code that shouldn't be executing,

and then the, the results are presumably erased. But unfortunately, people have discovered that there's actually ways to do this in a way where you can cause, certain state to be preserved inside of the speculative execution hardware on the chip And this can, influence, certain timing of other instructions and executions and things like that that can be analyzed to either extract information or in some cases inject information. So anyway, ideally a secure element shouldn't be using, speculative execution.

one of the interesting trends in the community is I'm seeing the very beginnings, and I can't emphasize that enough, it's still very nascent, but I, I'm definitely seeing a lot of interest Towards some sort of community open-source secure element project. probably my best guess is that it'll be based around Risk Five.

but yeah, I mean, I mean, part of the problem is that to get a chip manufactured, you're looking at, you know, many thousands of dollars. although it depends. I mean, for a secure element for the purposes of Bitcoin and transaction signing and, and hardware wallets, you actually don't need sixteen nanometer or, or lower, node, node resolution solution, you could actually get away with like one hundred eighty nanometer or something like that, which is a few generations old and therefore much cheaper. In fact, many university labs have, you know, micro mechanical engineering and semiconductor manufacturing facilities on campus.

Oh, there you go. W-sort of switching it up a little bit, there was recently a bit of a-oh, it's not that recent now, I guess. There was this, alert key saga, and I know you were involved with that. Do you wanna tell us a little bit about what happened there?

Well, okay, sure. So, the short story is that I released the alert key, which was, a, a secret, passed down from- From Satoshi, for the Bitcoin system. I, I guess I'll get the background now, for those who don't know, and it's sort of an irrelevant detail now, really, but the Bitcoin network used to have something called the Alert system, and the Alert system was a message passing layer where if the Alert key, in particular the Alert private key, signed a message, then every Bitcoin core node had the Alert public key and could verify that this message was signed by the Alert private key, and this message could be Be, displayed to users, such as in the event of, I don't know, the, the hash function being broken or, or elliptic curve cryptography being broken or the Diffie-Hellman assumption breaking down or something. Or, or even the discrete logarithm problem, I mean.

anyway, it b-- it's problematic though, because it's kind of a form of centralization, and there were also concerns that the Japanese government had access to the key as a result of Mount Cox. Long story there.

and, and just over time, the question was, well, who actually has this key? A lot of people ended up having this key. And, and furthermore, another problem was that all of these, copycat forks of Bitcoin that just- Bitcoin and changed the name and, and whatever, a lot of them copied the original alert key. So if there's a message on one network, it would propagate and be valid on other networks. some of the altcoins changed it, so it's not all of them, but anyway, this was a problem for some of them. And so as much as Bitcoin Core developers wanted to get rid of this alert system, and they, they disabled it, quite a while back, they couldn't, They couldn't,

completely get rid of everything here because, there was still this secret, right? And, and the secret, the concern about it is that by having the secret there, there, there is the opportunity for, for certain fraudulent behavior like people claiming to be Satoshi or something. You know, if they have the alert key, then, oh, maybe they're Satoshi or whatever. and so the idea was to release the private key so that everyone could have it, and this in theory eliminates the value of the key. if everyone has it, then therefore you don't know who is actually using it? So it becomes,

when someone signs a message, you just don't know who did it, and it's, no longer important. And it took quite a while to be-- to, for the community to be willing to release the alert key

Because the concern was all these altcoins that had copied the key, and the question was, well, if we release this, then if we release the secret, then is it the case that all of these altcoins are gonna have like negative things happen to them as people like use this key to like-

you know, conduct fraud on these other networks or something to like trick users into-- there's all sorts of edge cases that you can come up with and attacks and so on. And so,

it, it was a number of years and, and, you know, a large amount of certainty that it was time to release the secret, and then it was, and, I did that on stage at a conference and-

the rest is history, it's like completely gone now.

But, you know, that, that brings up another subject though, which is the, the,

you know, this effect where all these altcoins had copied something from Bitcoin, and as a consequence, they-

as a consequence, they,

had, had basically code rot or something,

you know, from a-- th-this also shows up in another way though, which is for vulnerabilities, and security problems. So in Bitcoin, we're of course very interested in maintaining the secure operation of the Bitcoin Core wallet and, and all the other related software, right? Well unfortunately, it's, it's a bad idea to announce every single vulnerability immediately, because if you do so, then attackers can attack Bitcoin users that haven't upgraded to the mitigation yet. So sometimes there has to be a delay there. But i-i-in further cases though, it's not always,

I guess you might even say it's not always moral to release information about vulnerabilities because of all the forks of Bitcoin. Now, you could argue, well, Bitcoin core developers shouldn't be responsible for all these losers who have copied Bitcoin or whatever, and we shouldn't be responsible for their security problems. But on the other hand, I mean, that doesn't necessarily mean that you should announce a vulnerability for a large amount of unmaintained software. So it's, it's difficult to reason about and, and there's a fine line and,

yeah, I mean, it's all related to responsible disclosure, right? I mean, what, what does responsible disclosure really mean? It's a term from the security industry and, you know, infosec industry. cybersecurity or, or whatever you wanna call it. but, you know, what's responsible? Is it-- is not disclosing responsible? If you fix it and don't disclose, is that responsible? If you disclose immediately? I mean, there's a lot of people that could be negatively affected, and, you know, in the future as Bitcoin becomes more valuable, as the whole, crypto ecosystem becomes more, more valuable, you know, there's a lot of money on the line

For sure. And I think even here, there have been concerns raised by people like, for example, Angela Walsh or on around, "Oh, how centralized is Bitcoin?" And so in that example, who were the people who knew about the vulnerability before other people? Did they get an advantage? There are some of those questions that could get raised as well, but there are legitimate reasons why the vulnerability isn't openly disclosed to the world and sundry, because obviously that is gonna expose a lot of people to a great level of risk.

That's right, yeah. I mean, some of these are just really tough decisions, and there's like, sometimes there might not even be a right answer really.

Yeah, there's no easy answers on these sometimes. also I had another one I was keen to ask you about, Shamir's Secret Sharing. So obviously this is a popular thing, it has enjoyed a, a fair level of, discussion within the Bitcoin community over the years, and recently the, the team behind Trezor, SatoshiLabs, came out with SLIP-0039, which is their own, Proposal or standard for the use of Shamir's secret sharing. Now, I understand there are some sort of contrasting views on this. what's your view on, Shamir's secret sharing and where does it make sense? Where does it not really make sense?

Yeah, so I'll start with that and, and describing Shamir's secret sharing in the scheme. for those who don't know, it's quite interesting. The idea is that if you have a secret, there's a way that you can split up the secret into multiple shares or shards, and, you can Where you can say, "Well, I want the secret to be, reassembled only if you have all shares." But you can also do thresholds as well, where you can have like three of four, or, two of five, or five of ten. it's very similar to multisig in that sense, but there's important differences, and these important differences, can tend to reduce the, the use cases for some your secret sharing. So here are the differences. In multisig, you can pass a message to each multisig participant, and they can Sign a message without revealing their private key. That's great. And Shamir's secret sharing, unfortunately, even if it's a five of seven, sharding scheme where you have to have five of the shares to get the original secret,

The problem is that each of these shares must be revealed, and in practice, they're usually gonna be revealed to a single party, and that single party then re- computes the secret. and,

as a consequence of this, an area where I think Shamir Secret Sharing is particularly useful is something like password recovery for a user, where you don't wanna write down your password, instead you write down multiple shares, and you can distribute the shares to either friends, family, or different places in your house, or whatever it is,

And,

and then when you, need to recover your password, you go to them, you recover the shares, and you recompute it. The other, the other thing to point out is that besides the single person that goes around to, to collect the secrets Is, they get reassembled into the full secret on a single machine. So then the secret is now assembled on that machine, and that machine has to be protected and airgapped and things like that, otherwise, maybe it's exfiltrating the secret. So it can, it-- there's a bunch of danger,

dangerous elements to this, to consider.

so yeah, SLIP-0039, it's great to see that deployed by Trezor,

you know, people can go and use this now, with their hardware wallet.

at, Rebooting Web of Trust number nine in Prague recently, I was just there a few weeks ago.

we got around and discussed the idea of a binary encoding format for Shamir's secret sharing, and the benefit of this is, the idea is-- it's very nascent, I should, I should emphasize, is that, It might be useful to have another standard for Shamir's secret sharing, that goes beyond SLIP-0039, because SLIP-0039 is limited in a few ways that, that totally makes sense for, what SLIP-0039 is designed for. But in particular, Shamir's secret sharing doesn't actually have,

a limit of sixteen, right? Sixteen of sixteen, that was something from SLIP-0039 really. if you want, you could have a thirty of fifty, secret, you know? you could create fifty shares.

I'm not, now in practice, I'm not sure anyone really would, but, I think it's important to be able to have standards that accommodate for things like that. And, and in, in this kind of standard, the, the bag of elements that you need are things like serialization formats, encoding and decoding,

And you need to have it written down in a public document and things like that. Anyway, that, that's at a, a, a nascent early stage at the moment. And oh, and the other important thing is the actual implementation, of course.

and, and I've heard of different ways of this being implemented as well for a Bitcoin custody context. So some ideas I've heard would be things like, okay, so obviously in the single signature case, you might split up your Shamirs into three or five or whatever you want. another option might be, you might have a multisig and one of those keys might be, kept in a Shamir's share for some sort of redundancy or backup reasons. and then I guess another context that I've heard That it explained was my earlier interview with Michael Flaxman, where he explained this idea of, "Oh, you might do something like, you know, you might do multisig three of five, but then the underlying seed for that three of five, you might split that up into, say, a six of eleven Shamir's secret sharing. " Can you comment a little bit on some of those cases? Which ones do you think make more sense, and which ones are maybe a little vulnerable?

yes. So, so an interesting observation there, okay? So you do three of five multisig on Bitcoin on-chain, and then each of those keys is, an eleven of twelve or something like that. Yeah. And so one of the interesting observations here is that with Shamir's secret sharing, you can actually use larger group sizes than are possible on-chain in Bitcoin today, although with Schnorr signatures, you know, look out for that.

the use case I've heard in a commercial context for Shamir's secret sharing is actually, this idea of rotating out team members. And so the idea is that, you have a secret and, you have maybe a team, you know, you have your three of five, so it's a team of five or something. And the idea is that maybe someone leaves the company and they still have that secret technically, or you should assume that they do. And so the procedure is, you take the other remaining members and they come together, and it is a bit of another one of those delete the key things, trusted setup things, where, they, they recompute the secret, and then they create new shares, and the idea is that they delete the old one. And so if they delete their old ones, then the employee that left with their one secret can no longer-- there's nothing else in the universe now that can be recombined with their one secret to reconstruct the secret. So this is a way of doing team rotation.

this, this use case,

is, is particularly important to Unchained Capital, they recently, released, software project called Hermit that does Shamir's secret sharing with, with encryption. And the idea is that each user types in their decryption passphrase on a single machine that's airgapped and uses QR codes to communicate with the outside world. And, the interesting thing about the Hermit project that I really like is, is that when you type these, secrets into this machine, it unlocks the secret for, for the, presumably the private key, but only for fifteen seconds at a time. And I really like that. So it's a fifteen second timeout. And, if you're, after that time, like if you've looked away to get a cup of coffee briefly or something, and the time runs out, then it deletes the secrets, and I think that's a, a really good,

Oh, fantastic. Yeah, as part of this series, actually, I will be getting Dhruv on as well, so I'll make sure to, go into that with him. But yeah, so just, just to summarize some of the thoughts around Shamir's, so essentially the main risk with Shamir's is that essentially at the point you are reconstituting the seed altogether, that is the point that you are vulnerable, and so you would have to try to do it in a very secure location, and then at that point, you might then need to do whatever your new setup is, so You might be leaving yourself vulnerable, to, you know, getting attacked at that point and physically attacked. perhaps what you could do is set up, you know, the new setup in advance and spend, like, and then get together and do your Shamir's kind of, com-combination and then spend at that point into the new secure setup, if you will.

One of the things to watch out for in the future on the research front is a, a variation of Shamir's secret sharing called Ver- verifiable secret sharing or linear secret sharing, and these are different secret sharing schemes that are similar, but they have a different property. In particular, there are some of these schemes that act more like multisig, where they can generate partial signatures on a message without bringing the secret sharers together into the same room or same computer. And, this is obviously advantageous from a security perspective,

and then they still retain the property where if you wanna recover the original master secret, you can get the shares all together and recover the secret. So it gets, kind of gets the best of both worlds, so that's something to watch out for now. As far as I'm aware, there's no implementation of that for Bitcoin yet, so it's not, it's not quite ready and- It's just, in the incubation phase, I guess you could call it.

Got it, got it. one other thing that just came up to my mind, I meant to ask this earlier, but just around this idea of the vaults construction of your vaults proposal and the idea of having many, if you will, spending, like the one percent, for each, portion of the UTXO or whatever, whatever is being spent, rather, does that- Have a very large script and therefore a very large on-chain footprint. Is that just one of the trade-offs there? Well,

this, the individual scripts on each of the outputs in the transaction are, in my opinion, small. However, because there's 100 of them, yes, it does actually increase on-chain fees and cost of doing this transaction. In fact, it is possible in this scheme to change it from lose at most 1% to lose at most point 1%, but the problem is that this requires, ten times more outputs, right?

so,

that's, that's problematic, but, but, if you're willing to pay the fee, then, then you can do it that way, sure. yeah, and, and

it may make sense for someone with a lot of money, right? So

yeah, yeah, absolutely, absolutely. Yeah, I mean, when I made the proposal on the bitcoin-dev mailing list

I, for whatever reason, I just chose one percent. It's a simple number, I guess.

Yeah, I mean, theoretically you could just do ten percent, right? And just do it like that, right? It's not a, it's not really that big of a- Yeah, I guess it's, it's really-

percent though, you're gonna look back and be like, "Ooh, why did I set it so high? "

True, but I mean, they could set that number anywhere, right? They could say, "Why one percent? Why not point one?" And then, you know, so on. But yeah, I suppose it's about setting a threshold that you're comfortable and, you know, going with that, I suppose. Yeah, yeah. Alright, let's talk a bit about, so I know you mentioned around Smart Custody, so that is a book that you have contributed to with Christopher Allen, and I know there's a workshop on with that. Was there anything else you wanted to mention about that

No, no, I mean, if you're interested in learning more about it, check it out smartcustody dot com, a lot of materials on there, a lot of, you know, just free resources and then in the future there will be more workshops, including one that focuses more on multisig. and also, custody. The previous one was really focused around personal cold storage.

Okay. let's also talk about, one of, the things that you're very well known for is, your work on transcripts at various Bitcoin conferences. So, tell us, I think the listeners would love to know a little bit about, you know, just how do you do it?

Well, so the way that I do it is I just type very quickly on a QWERTY keyboard on a laptop that I bring with me, and I,

website, you know, and I use Git and I Git push the transcript, usually before the speaker sits down from standing up on stage.

yeah, I mean, I'm, I'm just a fast typist, I guess. I've, I've competed on, on various typing websites before, and, one of the results I'm most proud of is that out of five million, competitors, I ended up being ranked number thirty. So I'm not the fastest in the world, but I'm, I'm, I'm pretty damn

fast.

Right, because I think the average news reader speed is say, a hundred and eighty words per minute, and, you know, something like eighty, eighty to a hundred words per minute for a typist is considered relatively fast, and typically transcription typists might be anywhere like one twenty, one forty even. So I guess that's kind of like the rough ranges that a, a transcription typist might be operating at, whereas you're kind of operating higher than that even. So I, I type at a,

on a really good day, I type at two hundred words a minute, which is pretty fast. But court stenographers, type even faster than that. They can-- they've been known to do two hundred fifty words a minute or even three hundred fifty words a minute and higher. And that's because of specialized hardware they have and then also a whole, system of abbreviations that they use.

it's actually interesting, it turns out court stenographers, are actually quite, paid quite a bit actually. it's kind of interesting.

Fantastic, that was a backup career there. I, I actually used to do, transcription typing myself, but mine was more like, recorded police interviews kind of thing and was outsourced to a company. So I would sit there and, sit there with a pedal and stuff. I thought I was fast, and I'm like one twenty words per minute, no, nowhere near your level.

So

I,

And, it, it was, it was based on this idea that I wanted to prove to-- I, I, I think it was to like the principal of the school or something, that all, all of these classes were like a total waste of time, and like if you actually looked at the, the spoken content in a, in a, in a day, you know, eighty percent of it was just garbage, and, you know, it was just a total waste of time or something. Anyway, admirable, goal.

certainly, I certainly typed a lot, but it turned

You're not transcribing

this conversation right now, are you?

No, no, not right now. Unfortunately, so- I'm kidding. No, it's a real problem though, like, so I can type what other people are saying, but when I'm speaking, I can't type that down. So I ended up recording everything else that everyone says, except for what I say. And you would think it should actually be the opposite. It should be that, if you're saying something important, then it should be written down. But unfortunately, I'm just-- That's beyond my skill.

Well, yeah, I guess you could record it and retype it, but then it's a question of time, right? Like ultimately, y-your time is worth more doing, you know, other things than literally sitting and typing.

Well, so exactly. The value of time is one of the reasons why I do this at conferences. If I'm sitting there in the audience and I'm listening to a presentation, I might as well be taking very elaborate notes in a transcript. And furthermore, it means that in the future, if I wanna go and revisit this talk, I don't have to watch the video. And many people find that to be, a, a benefit of these transcripts is that they don't have to watch the video. a lot of people even consider videos to be rude, you know, because it's imposing on your time as a professional, whereas a transcript is, is so much easier to skim and read and extract the important parts from. And if there is something that's really confusing, like someone pointing to a diagram

in the transcript, Which is impossible, you know, then they can go check the video or something.

Right, yeah. I mean, it's, it is a difficult thing because there's a lot of- Important information that's being conveyed through, you know, these talks and even sometimes on podcasts, right? So even with my podcast, I try-- I'm, lately, I'm trying to make sure we get transcripts going for it, so that people can kind of quickly get to the part they need.

Yeah, I, I've actually been, quite curious about that because I do see the transcripts on your podcast, and I'm wondering who makes them. Like, do they get all the Bitcoin terms right on the first pass?

no, definitely not. So I use this website called Rev dot com, and so they use human transcription. I've tried some of the automated ones, unfortunately, they just-- especially with the different accents and the technical terminology, they rarely get it. But Rev dot com, I think they do all right, at least they'll try to Google terms and try to get them, but there'll be some terms that are just hard to Google, or there'll be specific technical terms. Now, there's a little glossary section I can put in, okay, xpub, private key Or what are like different terms of Shamir's, right? So they know what to Google or search, and I think they quickly do a quick search, but obviously it's not, perfect. So I spend a bit of time going back through the transcript to kind of fix it up, and get it ready for when I actually post it on my website, but hopefully that's, valuable for people, but I'm, I'm not really sure, we'll see. No, I,

I certainly find it valuable. you know, funny story, a

I think it was Mark Friedenbach, tapped me on the shoulder at a conference and said, "Bryan, you know, you're, you're a fast typist, sure, and it's impressive and all, and I'm glad you're doing this, but you're also a skilled software engineer, and why not just do a machine learning project to do speech recognition for our conferences and just automate this whole thing?" And I looked at him and I was like, "Oh, yeah, okay." So then I went and built a machine learning implementation of speech recognition. It was based off of B

deep speech. And, since that time, Mozilla has actually done a really, fantastic implementation of that, an, an open-source one at that. the problem with my version was that I had a twenty percent, error rate with words, so it didn't quite work out. but, but the idea though, was that I was training on, audiobooks, because with audiobooks, you have text, and then you have the audio, and so it's a really good, training source.

Yeah, I think that's the Considering, if you're not like a Bitcoiner, it's kind of difficult to know all the terms. but yeah, it's even harder for a computer to figure those out because a lot of, I guess, the spoken word and so on, a lot of these technical terms or names even aren't really-- they're not in books, you know? So you kind of, I guess, there's a bit of model training or whatever that has to happen before it gets to that level. So one of the observations

I've had about these transcripts is that People only find them valuable if they're available immediately after a meeting or after the presentation. If they're, posted two weeks later, I find that people often don't care anymore. It doesn't matter what was said, really. What matters is that they're available immediately and that people have that link and they're able to go back and reference it as soon as possible.

Yeah, I mean, for me, I try to, I definitely, even for me with my podcast transcripts, I try to make sure they are ready at the point I release them nowadays. So I definitely do try to get that But it doesn't le- it does add a bit more admin time and so on of me correcting the transcript and so on and getting it kind of ready to go. But yeah, I mean, that's hopefully people find value out of that. yeah, were there any, interesting topics at some of the recent conferences that you've been to? I know there were a couple in Tel Aviv just recently. Were there any you wanted to touch on there?

yeah, so in Tel Aviv, there were, there was, a lot of conferences. There was, the Decentralized Financial Architecture Workshop, which was trying to pair developers with regulators.

that was certainly interesting. A, a lot of, debate occurred over the travel rule.

then there was Bitcoin Edge Dev Plus Plus at Tel Aviv University, which was a two-day training session. going over basic Bitcoin data structures and, basic concepts, but also some advanced proposals.

a-all those videos will be posted and there's transcripts for, for everything there. And then there was Scaling Bitcoin, which was a two-day conference at Tel Aviv University again. And, Scaling Bitcoin, of course, is more focused on, academic research and advanced prototypes and concepts, right? And, you know, it's a, it's a good pairing to have training and then more advanced concepts. I think that's a good, good way to do, good format for this.

Fantastic. a-and, I know Bryan, you're also involved with administering the bitcoin-dev mailing list. So, can you tell us a little bit about that?

Yeah, so this is, this is somewhat janitorial work, I suppose, but,

some- anyway, for a few years now, I've been part of the, the team that's been, helping Email get through the mailing list and, you know, kicking out the spam and things like that.

one of the-- A few years ago, we transitioned to being hosted by Linux Foundation, and they've been very generous with their resources,

however, Linux Foundation is migrating away from email, and they're kicking us off as a result. they're not just kicking us off, they're kicking everyone else off as well. So as a result, we've been working on coming up with an alternative system setup and making sure that all the permalinks are the same, and thankfully Linux Foundation has agreed to that to make all the, the permalinks for the current mailing list archives, which many people reference in presentations and papers and a-around the web. It's, it's so important to me to have, the, those hyperlinks, remain, Remain there. in fact, if you look around the internet, the half-life of any given link is like less than a few years at this point. But in theory, it should be simple to maintain text email archives for indefinitely, so, let's, let's hope that, that, that continues to be the case. but anyway, yeah, I mean, there's, there's tens of thousands of subscribers on the BitcoinDev mailing list, and,

you know, one of the, one of the concerns when migrating is like, should really all these email addresses be copied over to a new mailing list when the other one closes? You know, it's sort of a privacy thing, maybe not everyone wants that, but at the same time, a lot of people might be sub- subscribed for the sake of like security updates whenever those updates do occur.

you know, recently, as an example, on the Lightning dev mailing list, there was a signed message from Lalu saying, you know, upgrade your nodes, there's, there's a, a vulnerability, you know? If people-- if the mailing list was migrated to another server and people weren't subscribed, nobody would, would have received that message. So, you know, there's trade-offs on, on do-- on both ways of doing this.

I, I, I think you probably do have to just keep everyone who is already on it until they opt out, right?

Yeah, I mean, that's, that's, that's my current thinking, yeah.

Yeah. Okay. Well, yeah, I mean, I definitely appreciate, being able to see some of the discussions live as they're happening, although it sometimes, it, it's Bitcoin, it feels like you're drinking from a firehose, right? Because if you're subscribed to, Bitcoin dev mailing list and the Lightning dev mailing list and you're trying to follow

But yeah, look, let's so- let's talk about one of your other passions. So I know obviously Bitcoin is a big passion of yours, but I know you're also big into this whole idea of transhumanism, biohacking, and so on. Can you tell us a little bit about that?

Right, so before I got into Bitcoin, one of my main focuses was in biotech and something called do-it-yourself biology. The idea here is that, it's possible to, work on biotech projects outside of the context of, of academic labs at, at colleges. And, there's all sorts of systemic effects for why other people are interested in this. Like for example, there's, there's a huge number of biology students and grad students out there that get disenfranchised from the academic system, and then they realize that some of the projects that they wanna work on, they can pursue at home with, with their own means and resources without working with a university.

so in this area of, of biohacking and genetic engineering, I, I certainly have talked about my interests here before.

I suppose though, for, for people who aren't familiar, one recent example that might be interesting to them is that at a conference, in Vegas recently called Biohack the Planet. one of the presentations went over a, a very, typical, biohacking project, and this was a project to make something called Slybera, which is actually a knockoff piracy version of Glybera. Glybera is well known as being the most expensive drug in the world at one point two million dollars as a gene therapy to fix lipoprotein deficiency. And it works, the problem is that it cost one point two million dollars. Well, Sibera is the garage biohacker version, and, you know, the, the presentation went on to, to show that a lot of this work can be replicated in, in your own garage for about seven thousand dollars, approximately, and that's a million dollar drug, you know, as drug prices rise, you look at these prices and then you, you really have to start wondering, what is the actual cost of going and getting lab equipment and putting this thing together yourself? It's not quite clear to me that That abiding entirely by, by regulatory agencies and what they decree to, to be available to the general public is the best way to, to fix health problems that, that might be rapidly leading to end of life scenarios, you know?

Absolutely, and I think, to my mind, this is calling, a big-- one of the big intellectual influences on my mind is the work of Stephan Kinsella. He is well known for being anti-intellectual property, and I think also from a libertarian point of view, we would be anti- You know, the FDA, right? We would have like free market regulation of things as opposed to government regulation of who may ingest what drug or take whatever procedure. but perhaps in, in the Bitcoin future, we might see a lot more jurisdictional competition and maybe we would see medical tourism and people might just go to some other jurisdiction and get a procedure done there or go to some other jurisdiction and make Slabera there, you know, that kind of thing. Yeah, exactly. So-

In my opinion, regulatory agencies shouldn't really be, so paternalistic. Instead, I think the better model would be something more like sandboxes, where people can opt in into the wild west, or rating agencies, where they do very thorough investigations and give a rating based off of their findings. but other than that, I don't think that they should be able to just outright ban things or, or prevent people from getting access to the medicines that they think they need.

Right. and I suppose, now, again, I, I'm with you on this, but I suppose the, the person who's pro intellectual property at this point may say, "Oh, but this company has spent X, Y, and Z number of dollars trying to develop this technology. Why do you guys think you should be able to just make it on your own without, you know, having regard for that?" A-and I think the kind of conciliar response or so might be that, "Look, the whole, that you can't own that. It comes to what, what

Well, in, in my opinion, I actually think that the, the claim that you, you have to have a patent to prevent other people from developing the technology is a little strange. I think that one way to do this and to, to look at it is that if you have this technology that's really valuable, you should be developing it, and if people, for whatever reason, feel the need to develop it themselves, then you're not doing a good job. You know, you can operate a business where you offer this information and these systems for, for utilizing what- Whatever this patent really is, and people will gladly do business with you if it makes sense. But if there's, there's, you know, either, either unreasonable licensing requirements or whatever it is, then, yeah, of course people are gonna try to do it themselves. Of course they are. It, it completely makes sense.

Right, and it becomes, at what point is it cost effective for each individual person to try some of these things? And it may be like, the famed Tesla Model, right? At the start, something's only available to the rich, but then

And I think that's potentially a model that we may see with, biohacking and biotech. Do you have any, thoughts on that idea?

Yeah, I mean, absolutely. It comes, comes back to like exit and voice, right? If you don't have voice, then, you know, you exit the system. And that's really what medical tourism is. It's this idea that, you know, in the US, healthcare is broken, and especially healthcare billing, for that matter. and the idea is that you can get cheaper prices by going overseas to get your

I, I think that, that will also apply from a regulatory perspective as well. A lot of people in the cryptocurrency industry end up going overseas for getting access to financial services that are

more modern, right? Fantastic. I know obviously, so, probably have many shared listeners with Marty Ben, and I know you recently, did an episode with him on that, on the, on Marty's great show as well, so recommend listeners check that out. And, yeah, I guess also I was just curious to get your thoughts on that idea that, will humans Ever live forever? Do you think that's actually possible or do you think it's sort of just never gonna happen?

I think that extremely long lifespans are definitely, physically and, and theoretically possible.

The question is like, when are we gonna be able to develop that technology? When will it happen?

not quite sure, I guess. If you're interested in that question, follow Aubrey de Grey.

living forever, though, I mean, pedantically, if I may, is, is, is, something very hard to guarantee, right? No one knows if something will really live literally forever. In fact, forever from a, in a physics context might not be a real thing. instead, though, I mean, like, yeah, I mean, I think that That humans will be able to have a thousand year lifespan or a ten thousand year lifespan. I think that, biologically, if, if you remain, healthy and relatively young throughout your lifespan, then, indefinite age should be achievable.

Wow, yeah. and I guess the, the other question then, it might be too late for people like you and me, but let's say a generation or two down from us, maybe it's a possibility for them. and also, kind of, at what point? how old are you? Can they reverse age you? I guess that's an even more tough question than to take someone who's already kind of healthy and keep them healthy.

Yeah, so I have a, an interesting perspective here. I mean, everyone wants, some sort of gene therapy that, that'll, you know, reverse their aging process or something, and yeah, that would be great. Unfortunately, that's a magic trick that, that people really don't know how to, to make happen yet. I mean, the best ideas that we have are things like make synthetic organs or grow organs in pigs. And replace all of your organs, once every ten years when you get up there in advanced years, and hope that these replacement organs will keep you, keep you ticking. Maybe these replacement organs will be genetically enhanced in some way, but, you know, this is all quite speculative. On the other hand, though, we have reasonable evidence from even fly experiments that there's a way to breed flies in a way where you can increase their lifespan over a few generations. So with genetic engineering of human embryos, it may be possible to have some of those, those benefits, applied to the next generation of people, you know, your children, namely

and, people, p-- you know, people have concerns about that, and, you know, one of the most frequent concerns I hear is, "Well, I wanna live forever. I don't, I don't care if my child has, you know, a, a twenty percent longer lifespan, I want a twenty percent longer lifespan." And, well, I mean, unfortunately, the time that we're living in, you know, where we are in history of technology development, is that at the moment, we're closer to being able to make, the next generation, namely

just, better genes, different genes, being able to choose those traits, than we are being able to extend a person's lifespan who, a person who is already an adult, their lifespan by twenty percent. That's just, in my opinion, a significantly harder task.

Right. And I guess setting aside all the ethical questions and so on, if it were possible to, let's say, make the next generation super-intelligent, maybe there's a chance that, you know, they would then be able to invent the technology for everyone else to kind of live longer Oh, absolutely, yeah. I mean, yeah,

yeah,

I mean, it's a feedback process. Excellent. Alright, well, look, is there anything else you wanted to touch on today, that we've kind of missed?

No, no, not at all. This has been great, actually. I've, I've really had fun here.

Just before we let you go, make sure you tell my listeners where they can find you online.

Oh, yeah, find me online at

Twitter dot com slash k a n z u r e. Fantastic. And also, I'll put Be, a-w-aware and able to soak up that, Bitcoin conference and also podcast knowledge. So look, thanks very much, Bryan. I think it's been a really interesting conversation, and I'm sure my listeners will get a lot of, will get a lot out of this. Yeah, absolutely. It's been

fun.

Thanks for having me on. I hope you guys enjoyed that. Remember the show notes and the transcript of the interview are on my website stephanlivera.com. You can find me on Twitter at stephanlivera or email me stephanlivera at pm dot me if you have questions or if you are interested to advertise on the show. As always, thanks for listening and I'll see you in the citadels.