Stephan Livera Podcast with Bryan Bishop - September 22nd 2019

Bitcoin Vaults and Custody

Podcast: https://stephanlivera.com/episode/108/

Stephan Livera: Bryan, welcome to the show, man. I’m a big fan of your work.

Bryan Bishop: Thank you. I’m a big fan of yours as well.

Stephan Livera: Yeah, so look, we’re doing Bitcoin Custody. I know you’re one of the guys to talk to on this exact topic. And so, maybe we’ll just start with a little bit of a background. What was some of your work with LedgerX, and then what’s some of the work that you’re doing more recently?

Bryan Bishop: I started at LedgerX in 2014, 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. I was super interested in what they were doing, because I had actually previously looked into clearing houses, and I was trying to figure out, what does it mean to be a clearinghouse when you have Bitcoin? How does Bitcoin change the financial system? And clearing houses are a very important part of the financial system. 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 mission was and is important. And it was just a very interesting experience.

Bryan Bishop: I mean, as you can imagine Bitcoin is a very unregulated asset in general, fundamentally, even philosophically. On the other hand, if you want to 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. It was a fascinating experience.

Stephan Livera: Yes, actually, it might be interesting to dig into that a little bit. What were some of the… I think it’ll be interesting for the listeners, just to understand, because back in 2014 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, things like that. That was what people were doing then because there wasn’t a built out… There was no Glacier protocol, then. What was the thinking then, and how is it shifted to now?

Bryan Bishop: Well, first, at any startup, you really don’t have any idea whether this thing is going to work. And at LedgerX in particular, 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 the startup would be able to secure the licenses required to operate as a clearinghouse for Bitcoin options. 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 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. That was one of the big projects that I was part of, and responsible for was secure storage of Bitcoin.

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

Bryan Bishop: There’s definitely some things that I would consider to be standard or a part of any good design for a system for storing Bitcoin. 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 every company should do. Now, there were also 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 174. We ended up… We were doing something quite similar. I just neglected to figure that it should be standardized, and 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.

Stephan Livera: Yeah, that’s fantastic. And just for any listeners who are unfamiliar, make sure you go back and check out Episode 99, where I talk to Andrew Chow about PSBT, Partially Signed Bitcoin Transactions. But Brian, back in those days, as I understand, I recall, there was offline armory. Now, something sort of close to it, but it was like its own thing. It wasn’t like a 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 jointly construct the transaction that works.

Bryan Bishop: 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 look at Armory, you’re always going to find something new that they thought of first, back in 2011, basically. So, it’s an interesting archeological expedition, I suppose.

Stephan Livera: Right, yeah. Let’s just get into I guess, what some of the later work that you’ve been doing since leaving LedgerX? What’s been your focus?

Bryan Bishop: 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 consulting and strategy, but also things like code reviews, security analysis, just peer review of software and systems that other people have developed. But then also things like doing architecture for new projects. I haven’t talked about it publicly, but this also includes a stint at Blockstream actually, as a contractor.

Stephan Livera: Fantastic. The gun for hire. But I’m sure you’ve got a lot of different stories about custody and cold storage. It might be interesting now just to dive into a little more detail if you’ve got any horror stories for the listeners?

Bryan Bishop: Yeah. I do have horror stories, and I’m saddened to say that. The process of handling Bitcoin, 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 myself, I personally try to always test my Bitcoin transactions on a test network before I actually do the real transaction. I know it sounds burdensome, but for large amounts of money this does make sense. Unfortunately, I’ve heard for some particularly wealthy individuals that have bought into Bitcoin, and who are famous in the news for such actions. Through one of my projects, a cold storage project, talking with people I found that 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 to me, that indicates that they are not operating their Bitcoin Wallets as securely as they could be.

Bryan Bishop: In one incident that I’m aware of, 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 in my opinion they were definitely not Bitcoin Core developers, they were just other people, friends of the family or something. And, just basic things like, well send me a PGP signed message of the signature… Sorry, excuse me, a PGP signed message of the address or keys you want me to use. The other individuals involved had no idea what that meant.

Bryan Bishop: So, there’s just basic human training that has to occur to get this right, and that’s very much something I focus on right now. Software can definitely help, but there are still human steps and actions and checklists that have to occur.

Stephan Livera: Right. Let’s break that down a little bit. I guess, the procedure you are referring to there is the signing procedure. Can you talk through what’s normally required?

Bryan Bishop: 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 has not 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 do not have the private key.

Stephan Livera: Yep, so this is like that example where you might want to, I guess, you’re getting at this idea that you want to 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.

Bryan Bishop: Absolutely. In fact, 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 submitted a 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, the only way that these exchanges really verify it is, as far as I’m aware, phone calls and emails and video chat.

Stephan Livera: Right. So, it’s sort of putting 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, which is inserted into the website so that they can hijack the withdrawal. Or they might do a hijacking the deposit as well. I guess that’s another possibility. If somebody goes to the exchange, they ask the exchange, 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 hacker’s or the attacker’s address.

Bryan Bishop: That’s right.

Stephan Livera: Or that’s a different problem.

Bryan Bishop: 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. 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 transaction.

Bryan Bishop: So, based off of this, I don’t think that just withdrawal requests alone is enough because unfortunately, an attacker could insert withdrawal request 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. 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 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 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.

Bryan Bishop: The idea is that this transaction gets broadcasted, and it only gets signed in the event that the output script exactly matches that template I just described. 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 those funds and return it to cold storage for the exchange. I think that will significantly reduce the consequences of theft attempts at exchanges that get hacked.

Stephan Livera: Got it. Let me just think that through my head again. So, what you’re saying is there would be a relative time lock placed on that transaction, on the outgoing transaction from the exchange, and the signing server is only going to sign in the case that it has this particular scripting in the way that the transaction is crafted or constructed, let’s say. And you’re saying that 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?

Bryan Bishop: That’s right. So, this requires the exchange or even the users to be monitoring the blockchain to watch for those potential transactions.

Stephan Livera: Right. And so, I suppose in that case, where let’s say, the exchange later figured 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 would the exchange spend it back to its own safe address, if you will?

Bryan Bishop: 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… 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 option. There’s a few ways to do it.

Stephan Livera: Go it. And so, is that related to your vaults proposal, or is that separate?

Bryan Bishop: It is related, and I’ve personally been finding it challenging to determine how related it really is whether it’s the same idea or not with 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 less broken version. But yeah, I mean, basically, the idea of a vault is to have that revocability period. The problem, though, is that in Bitcoin today, previously the only known ways to do that revocability period was using something called the covenant, which would require a soft fork, or a hard fork to implement in Bitcoin. What a covenant is, it’s just an extra restriction on a Bitcoin transaction. You can think of the requirement of a public key, and it’s 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.

Bryan Bishop: 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 the fork on the network. And the flaw in my proposal was that, essentially, you pre-sign this huge tree of transactions where you can keep bumping it into the future, if you want, until the end of time, because relative time lock, and you can just bump it out. And in particular, if an attacker steals some of the coins you get to revoke the rest of cold storage. 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. Unfortunately, that’s not a reasonable assumption.

Bryan Bishop: The updated version 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 1% of your funds. So, I can’t prevent 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. Then in one example, there’s 100 outputs, and each output has 1% of the funds. Each output has the same script template that I just described for the restricted signing server. The one where there’s a immediate recovery to cold storage available as a possible route, or relative time lock spinning to some key. And that key is pre-determined at the time that you set up the vault.

Bryan Bishop: 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 hotkey that was already baked into this whole scheme. And so, what this is doing… Oh, and there’s one more thing. On each of the relative time locks, and each of the 100 outputs, each one is one day further into the future. So, on the first day 1% is available, on the second day 1% is available, and so on. The idea is that you have to sign a transaction during that one day to take that 1%. 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 99 outputs. You can do it at any time. If he steals the first 1%, you do it for the other 99 outputs, if he steals the second to the last, you do the recovery for the last 1%, and so on. Anyway, what this does, in fact is it limits your losses to 1% of your total funds.

Stephan Livera: Got it. And so, the exchange or whatever service provider is 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 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?” At that point you would tick off and go, “Okay, maybe we need to now go look into this relative time lock… not rather, the other part where the immediate spending pathway to spend it back to their own cold storage.” Correct?

Bryan Bishop: So, I might need a better name for this. But I’ve personally been calling it like a watchtower. So 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 trip wire switch thing, please don’t… please, I’m actually trying to withdraw my money or whatever it is. All of the proposals that I just described require something like watchtowers or give it another name. The other interesting thing is that actually, the method that I just described results in losing at most 1%, was actually developed for the purpose of personal cold storage.

Bryan Bishop: 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. And in my scheme, in particular, if you choose to do this with multisig vaults where multiple people come together to set up 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. And the problem with this is that this m of n 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.

Stephan Livera: Right. I mean, potentially, that could become part of some kind of signing ceremony or ritual. Like if everyone watches that person 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? I guess that’s the difficulty you’re getting at.

Bryan Bishop: One idea I’ve been toying with that might save the commercial custody case for a scenario where you have to delete key is models more like GreenAddress two of two 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.

Stephan Livera: Okay, and I guess let’s bring it back to the… I guess it’s so scary, right? There’s so many things, you don’t know who you can trust. So, you just have to try and figure out ways to 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?

Bryan Bishop: 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 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. So, when thinking about different security protocols, and different software implementation, being able to protect against these problems is very important. So, techniques like check sums 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.

Bryan Bishop: It’s this idea that there might be a single error, just one little Bit flip somewhere that might completely break something, 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 need to get this right as a community, and certainly for people who aren’t developers and understand some of these nuances.

Stephan Livera: Got you. And with that, that actually brings to mind Glacier protocol as well. So, this is address reuse 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 what somebody is doing with that address. Potentially, that might be one piece of the puzzle that helps them understand, I know Brian 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, they could try to start using that information.

Bryan Bishop: Glacier protocol was a very interesting approach with, basically within documentation with steps for what software to run and how to use it. I think it falls a little short in that. I think the ideal solution would be both, a lot of checklists, and written documentation and steps and even videos, and even paid training services, but then also 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 smartcustody.com, which started as a series of workshops around the question of how to secure assets for consumers. 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 for each person that’s different depending on which threats you’re particularly concerned with some of the different hardware choices get made.

Stephan Livera: Yeah, there’s so much with that. Because, I guess, yeah, part of it is also how easy is it to use multi-signature, and what hardware do you use? Also, it’s that idea of fighting against bit rot. So sometimes, in certain models that’s why multisig is used as well. That for example, in the Casa model, they go seedless, and the idea is that you’ve got three of 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 it’s a slightly different model. How do you think about comparing going seedless versus backing up seeds?

Stephan Livera: Because I guess the argument either way would be, one would be, 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 obviously in a single signature hardware wallet scenario, then obviously you do need to backup the seed. So, how do you think that through in terms of the trade off decision there?

Bryan Bishop: Well, unfortunately, I don’t have an answer for you. But I can definitely talk about those trade offs. I think Flaxman in particular is fond of mentioning that, for the case of single sig setups. It’s actually 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 your one hardware wallet fails in a one of one setup. Well, now you’re out of luck, especially if you didn’t have 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. So, yeah.

Bryan Bishop: The question of seedless versus writing down seeds, yeah it’s an interesting one. I can definitely see merits both ways. When you have a seed based backup system, one of the questions that I end up always having is, okay, so I put a hardware wallet in a vault in a safe somewhere. And now I have a seed that I’m going to write down, a recovery seed or other recovery system. And of course, you shouldn’t really be putting that in the same vault. It increases the complexity. Yeah, I think that we’re a long way from having a single standard of care and quality for these procedures. Just producing hardware wallets isn’t enough. There needs to be a broader system and mechanization around this.

Stephan Livera: Right. I guess I might also ask you this now as well. 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 skeptical of hardware wallets. Can you articulate why that is, and what they would recommend instead?

Bryan Bishop: Well, okay, so many of the hardware wallets are developed on the basis of this idea that they’re consumer friendly and easy to use. So, that’s one thing. The security claims of hardware wallets are certainly open 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 laptop 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.

Bryan Bishop: However, in hardware wallets on the market, it’s not necessarily the case that. Some of these hardware wallets are actually more along the lines of consumer friendly interfaces more than anything else, and with some amount of security, of course, as a consequence of not having keys on your computer. 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.

Bryan Bishop: One of the ways that I look at this is I call it… When thinking about the philosophy of cold storage, I call it multifactor difficulty. That’s how I assess cold storage. What does cold really mean? It means that 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. If you have a heavy door for the vault, maybe grandma isn’t going to be able to be a thief, and eliminate some of the possible attackers, because grandma can’t open a 200 pound door or something. I don’t know.

Bryan Bishop: So yeah, so you need multiple different types of difficulty. And this is actually similar to multisig, in fact. One of the recommendations I’ve been making lately is that if you have multisig, 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 possibly your friends or your colleagues. Business partners may respond differently to you of course than your family members. Family members just want you to get back safely. And business colleagues, maybe they just want your money or something. But they certainly aren’t going to 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.

Bryan Bishop: 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 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 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 remove them from the multisig group.

Stephan Livera: Yeah, no, that makes a lot of sense. It’s not just literally checking the health of that key and checking there’s been a bit rot of the key. It’s also the security practices and awareness of the individual who’s holding that key.

Bryan Bishop: That’s right, and so 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 the funds into a new multisig setup that they aren’t included in? And so, they do sign it

[inaudible 00:31:42]

.

Stephan Livera: But that’s almost the opposite of the, oh right, so if they do sign it, then yeah, got you. So for a second, I thought it was the other way around. So, then it’s like, if she… What’s the one? If she drowns she wasn’t a witch, and if she is 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, right?

Stephan Livera: Okay. So 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. We can design the most amazing protocol, and the most 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, we are human, we’re fallible, we can make a mistake on these things. Have you seen any examples of that, or you’ve witnessed that in your own Bitcoin storage and Bitcoin journey?

Bryan Bishop: Oh, no, I never get fatigued. No. 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 doing like moving a laptop from one end of the vault to another, or… Not even necessarily finding a place to store a vault or a bank with a safe, 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 software as much as possible. And then the other thought that I’ve been having is that, in modern society, gamification of all sorts of loot boxes, and so on has really just been completely psychologically addicting, and even devastating.

Bryan Bishop: It would be interesting if we could apply that actually to fight process fatigue, because it’s very interesting that someone can click a single button on a phone, and consider that a game all day. But at the same time, there’s this other process fatigue of running through checklist and everything. So maybe if the two can be combined of checklists, but also gamification, or something through that software that I mentioned, then that might be something worth doing. But all of this really requires empirical testing. 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 storing my passwords on a sticky note on my front door, or whatever? We need to collect this data and find out.

Stephan Livera: Right, yeah. And I suppose 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. At the start people, if it’s like 40 bucks or whatever, they can safely just leave that on their phone, it’s not a big deal. How do you think about trying to create levels, if you will, on how paranoid to be or how much work to put in at each level?

Bryan Bishop: 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 gives you basically asymmetric power, meaning anyone can generate a 4096 bit key and encrypt data. There’s no way to break that computationally right now, and anyone can do that. Almost any smartphone can do that. That is an extremely powerful tool.

Bryan Bishop: Another example is, another way to cheaply create these types of cryptographic secrets is something that I’ve been calling delete the bits, and Adam Back introduce this to the Bitcoin community a long time ago at 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. Then you store the shorter version. What this does is it forces you to do a 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. By doing this, 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.

Bryan Bishop: The task of deleting bits from a string or value is something that any phone can do very cheaply. And suddenly, you have a way to create a $10 million 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.

Stephan Livera: Got it. So, it’s almost breaking a little bit that idea that you should try to increase the security as you go. One good point I’ve heard is really that people have to think in terms of what if their coins are worth 10 times more than what they really are right now. Because that may be the reality given Bitcoin, and 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. Again, this is a topic mentioned in the recent Smart Custody book as 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 involves 62 dice rolls to generate some additional entropy.

Bryan Bishop: Yeah, I definitely like the dice roll protocols. 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 multiple different manufacturers from different nations. Then you combine the entropy from multiple chips. Because if you have a random value, and you add another random value to it, then it’s going to be random. Or if you add something nonrandom to a random value, it’s random. That’s just one of the properties of high entropy values.

Bryan Bishop: So anyway, having multiple chips is an interesting approach. And the thinking behind that is that if you’re paranoid that a government has backdoor of 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?

Stephan Livera: Right, yeah. I suppose, I guess, depends how paranoid you want to get. But even if you’re buying dice, how do you make sure that the dice themselves are not biased?

Bryan Bishop: That’s right. Yeah, I guess you want to mix it with other entropy then?

Stephan Livera: Got you. 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 you how do you think about the idea of… I think this also plays a little bit into, 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 it you’ve got a Coldcard, I know you’ve got Bitcoin. So yeah, but I suppose let’s just start with the value of HSM, versus hardware wallets, versus secure enclaves.

Bryan Bishop: So, okay. Well, other than 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 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 good diversity across multiple supply chains. Coming 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 the system is physically tampered with, it deletes the secret. If it doesn’t have this capability, then I’m not sure it’s as valuable as people think it is.

Stephan Livera: Got you. What about this concept of having an open source secure element? As I understand, that’s one difficulty, right? So, I understood the Ledger has a secure element, however, it’s closed source. There are efforts and thought being put into this idea, but as I understand the cost is perhaps at this point prohibitive.

Bryan Bishop: 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 want to 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 their primary utility there. The idea is that even from power analysis, voltage analysis, or other tightening techniques to gather data, you won’t be able to extract internal state from those machines. Ideally, secure elements shouldn’t be doing speculative execution, so Spectre and Meltdown and other attacks that depend on speculative execution don’t work, which is a very fascinating one itself.

Bryan Bishop: If you’re not aware of it, in 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 motherboard. And so, as a result, computers are constantly executing code that shouldn’t be executed. Then 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 should not be using speculative execution.

Bryan Bishop: One of the interesting trends in the community is seeing the very beginnings and can’t emphasize that enough, it’s still very nascent, but 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 will be based around RISC V. But yeah, I mean, part of the problem is that to get a chip manufacturer, you’re looking at many thousands of dollars. Although, it depends. I mean, for secure element, for the purposes of Bitcoin and transaction signing and hardware wallets, you actually don’t need 16 nanometer or lower node resolution. You can actually get away with 180 nanometers or something like that, which is a few generations old, and therefore much cheaper. In fact, many University labs have micro mechanical engineering and semiconductor manufacturing facilities on campus.

Stephan Livera: Oh, there you go. So switching it up a little bit. There was recently a bit of… It’s not that reason now, I guess. There was this alert key saga, and I know you were involved with that. Do you want to tell us a little bit about what happened there?

Bryan Bishop: Well, okay. Sure. So the short story is that I released the alert key, which was a secret passed down from Satoshi for the Bitcoin system. 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 can verify that this message was signed by the alert private key. And this message to be displayed to users such as in the event of, I don’t know, the hash function being broken, or elliptic curve cryptography being broken or the Diffie-Hellman assumption breaking down or something, or even the discrete logarithm problem.

Bryan Bishop: Anyway, 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 Mt. Gox long story there. And just over time, the question was, well, who actually has this key. A lot of people ended up having this key. Furthermore, another problem was that all of these copy copycat forks of Bitcoin that just forked Bitcoin and changed the name, and whatever, a lot of them copied the original alert key. So, if there’s a message on one network, you 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.

Bryan Bishop: 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 completely get rid of everything here. Because there is still the secret, and the secret, the concern about it is that by having the secret, there is the opportunity for certain fraudulent behavior like people claiming to be Satoshi or something. If they have the alert key, then maybe they’re Satoshi or whatever. And so, the idea was to release the private key so that everyone can 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.

Bryan Bishop: It took quite a while for the community to be willing to release the older key because the concern was of 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 going to have negative things happen to them as people use this key to conduct fraud on these other networks or something, to trick users into… There’s your all sorts of edge cases that you can come up with, and attacks, and so on. And so, it was a number of years, and a large amount of certainty that it was time to release the secret. Then it was, and I did that on stage at a conference, and the rest is history. It’s completely gone now.

Bryan Bishop: But that brings up another subject though, which is that’s a fact where all these altcoins had copied something from Bitcoin. As a consequence, they had to had basically code rod or something. 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 all the other related software. Well, unfortunately, 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 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 forces of Bitcoin.

Bryan Bishop: 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 difficult to reason about and there’s a fine line, and yeah, I mean, it’s all related to responsible disclosure, right? What does responsible disclosure really mean? It’s a term from the security industry, and info-sec industry, cybersecurity, or whatever you want to call it. But what’s responsible is not disclosing responsible. If you fix it, and don’t disclose it is that responsible? If you disclose immediately, there’s a lot of people that could be negatively affected. In the future, as Bitcoin becomes more valuable, as the whole crypto ecosystem becomes more valuable there’s a lot of money on the line.

Stephan Livera: For sure. And I think even here, there have been concerns raised by people like for example, Angela Walch around how centralized is Bitcoin? And say 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 is not just openly disclosed to the world and sundry because obviously, that is going to expose a lot of people to a great level of risk.

Bryan Bishop: That’s right. Yeah. I mean, some of these are just really tough decisions. And there’s, sometimes there might not even be a right answer really.

Stephan Livera: Yeah, there’s no easy answers on these sometimes. Also, I had another one I was going to ask you about. Shamir’s Secret Sharing. So, obviously, this is a popular thing. It has enjoyed a fair level of discussion within the Bitcoin community over the years, and recently that the team behind Trezor SatoshiLabs came out with SLIP 39, which is their own proposal or standard for the use of Shamir’s Secret Sharing. Now, I understand there are some 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?

Bryan Bishop: Yeah. So, I’ll start with that in 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 also set up the scheme in a way 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 three of four, or two of five, or five of 10. It’s very common to multisig in that sense. But there’s important differences. And these important differences contend to reduce the use cases for Shamir’s Secret Sharing.

Bryan Bishop: 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. In Shamir’s Secret Sharing, unfortunately, even if it’s a five of the 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 going to be revealed to a single party, and that single party recomputes the secret. As a consequence of this, an area where I think Shamir’s Secret Sharing is particularly useful is something like password recovery for a user, where you don’t want to write down your password. Instead, you write down multiple shares, then you can distribute the shares to either friends family, or different places in your house, or whatever it is. Then when you need to recover your password, you go to them, you recover the shares, and you recompute it.

Bryan Bishop: The other thing to point out is that, besides the single person that goes around 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 air gap, and things like that. Otherwise, maybe it’s actually trading the secret. So you can there’s a bunch of dangerous elements to this to consider. So yeah, SLIP 39, it’s great to see that deployed by Trezor. People can go and use this now with their hardware wallet.

Bryan Bishop: 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. The benefit of this is, the idea is, it’s very nascent, I should emphasize is that it might be useful to have another standard for Shamir’s Secret Sharing that goes beyond SLIP 39. Because SLIP 39 is limited in a few ways that totally makes sense for what SLIP 39 is designed for. But in particular, Shamir’s Secret Sharing doesn’t actually have a limit of 16, right? 16 of 16, that was something from SLIP 39, really. If you want, you could have a 30 of 50 secret, you could create 50 shares.

Bryan Bishop: 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. Then in this kind of standard with the bag of elements that you need are things like serialization formats, encoding and decoding, and you have to have it written down in the public document and things like… Anyway, that’s a nascent early stage at the moment. Oh, and the other important thing is an actual implementation, of course.

Stephan Livera: 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 Shamir’s into three of five or whatever you want. Another option might be you might have a multi-signature, and one of those keys might be kept in a Shamir’s share for some sort of redundancy, backup reasons. Then I guess another context that I’ve heard it explained was my earlier interview with Michael Flaxman, where he explained his idea of, you might do something like… 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 11, 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?

Bryan Bishop: Well, yes, so an interesting observation there. Okay. So, you do the three of five multisig on Bitcoin, on chain. And then each of those keys is an 11 of 12, or something like that. 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, 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 have your three of five, so it’s a team of five or something. The idea is that maybe if someone leaves the company, and they still have that secret, technically, you should assume that they do.

Bryan Bishop: And so, the procedure is you take the other remaining numbers, and they come together. 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. 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 the way of doing team rotation.

Bryan Bishop: This use case is particularly important to Unchained Capital. They recently released a software project called Hermit, that does Shamir’s Secret Sharing with encryption. The idea is that each user types in their decryption passphrase on a single machine that’s air gapped and uses QR codes to communicate with the outside world. The interesting thing about the Hermit project that I really like is that when you type these secrets into this machine, it unlocks the secret, for presumably the private key, but only for 15 seconds at a time. I really like that. So, it’s a 15 second timeout. And if you’re… After that time, if you’ve looked away to get a cup of coffee briefly or something, then time runs out, then it deletes the secrets. I think that’s a really good security practice.

Stephan Livera: Fantastic. Yeah, as part of this series actually, I will be getting Dhruv as well so I’ll make sure to go into that with him. But yeah, so I suppose just to summarize some of the thoughts around Shamir’s. Essentially, the main risk with Shamir’s is that essentially, at the point you are reconstituting the seed all together, that is the point that you are vulnerable. And so, you would have to try to do it in a very secure location. Then at that point, you might then need to do whatever your new setup is. So otherwise, you might be leaving yourself vulnerable to getting attacked at that point, physically attacked. Perhaps what you could do is set up the new setup in advance and spend… And then get together and do your Shamir’s combination, and then spend at that point into the new secure setup, if you will.

Bryan Bishop: One of the things to watch out for in the future on the research front is a variation of Shamir’s Secret Sharing called Verifiable Secret Sharing, or Linear Secret Sharing. 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 shares together into the same room or same computer.

Bryan Bishop: This is obviously advantageous from a security perspective, and then they still retain the property where if you want to recover the original master secret, you can get the shares all together and recover the secret. So, it 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 quite ready, and it’s just in the incubation phase, I guess you could call it

Stephan Livera: Got it. One of the things that just came to my mind, I meant to ask you this earlier, but just around this idea of the vaults construction or your vaults proposal, and the idea of having many, if you will, spending the 1% for each portion of the UTXO or 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?

Bryan Bishop: Well, 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 the scheme to change it from lose at most 1% to lose at most 0.1%. But the problem is that this requires 10 times more outputs. That’s problematic, but if you’re willing to pay the fee, then you can do it that way. Sure.

Stephan Livera: Yeah, and it may make sense for someone with a lot of money, right?

Bryan Bishop: Yeah, absolutely. Absolutely. Yeah. I mean, when I made the proposal on the Bitcoin Dev mailing list, for whatever reason, I just chose 1%. It’s a simple number, I guess.

Stephan Livera: Yeah. I mean, theoretically, you could just do 10%, and just leave it like that. It’s not really that big of a… Yeah, I guess it’s [inaudible 01:00:31].

Bryan Bishop: At 10% though you’re going to look back and be like, “Why did I set it so high?”

Stephan Livera: True. I mean, they could set that number anywhere. They could say, “Why at 1%? Why not 0.1? And then, so on. But yeah, I suppose it’s about setting a threshold that you’re comfortable, and going with that, I suppose.

Bryan Bishop: Yeah, yeah.

Stephan Livera: All right. Let’s talk a bit about… I know, you mentioned around Smart Custody, that is a book that you have contributed to with Christopher Allen. I know there’s a workshop on with that. Was there anything else you want to you mentioned about that? Just for the listeners who are curious, they’re interested to know more about it?

Bryan Bishop: Yeah. I mean, if you’re interested in learning more about it check it out, smartcustody.com. A lot of materials on there. A lot of 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.

Stephan Livera: 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, just how do you do it?

Bryan Bishop: 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 have a website, 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 just a fast typist, I guess. I’ve competed 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 30. So, I’m not the fastest in the world, but I’m pretty damn fast.

Stephan Livera: Right. Because I think the average news reader speed is say 180 words per minute. Something like 80 to 100 words per minute for a typist is considered relatively fast. Typically, transcription typists might be anywhere like 120, 140 even. I guess that’s kind of like the rough ranges that a transcription typist might be operating at, whereas you’re operating higher than that even.

Bryan Bishop: I type at around, on a really good day, I type at 200 words a minute, which is pretty fast. But court stenographers type even faster than that. They’ve been known to do 250 words a minute, or even 350 words a minute, and higher. That’s because of specialized hardware they have, and then also a whole system of abbreviations that they use. It’s actually interesting. Turns out court stenographers are actually paid quite a bit actually. It’s kind of interesting,

Stephan Livera: Fantastic. There’s a backup career there. 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. I would sit there with a pedal and stuff. I thought I was fast, and I’m like 120 words per minute. Nowhere near your level.

Bryan Bishop: I started doing transcripts all the way back in high school as a freshman. It was based on this idea that I wanted to prove to… I think it was to the principal of the school or something, that all of these classes were a total waste of time. And if you actually looked at the spoken content in a day, 80% of it was just garbage. It’s just a total waste of time or something. Anyway, admirable goal. I certainly typed a lot, but it turns out nobody cared.

Stephan Livera: You’re not transcribing this conversation right now, are you?

Bryan Bishop: No, not right. Personally-

Stephan Livera: I’m kidding.

Bryan Bishop: No. It’s a real problem, though, I can type what other people are saying, but when I’m speaking, I can’t type that down. I ended up recording everything else that everyone says except for what I say. 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, that’s beyond my skill.

Stephan Livera: Well, I guess you could record it and retype it. But then it’s a question of time. Ultimately, your time is worth more doing other things than literally sitting and typing.

Bryan Bishop: Well, exactly. The value of time is one of the reasons why I do this at conferences is if I’m sitting there in the audience, and I’m listening to the presentation, I might as well be taking very elaborate notes, and the transcript. And furthermore, it means that in the future, if I want to go and revisit this talk, I don’t have to watch the video. Many people find that to be 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 because it’s imposing on your time as a professional. Whereas the transcript it’s so much easier to skim and read and extract the important parts from. If there is something that’s really confusing, like someone pointing to a diagram in the transcript, which I can never get that right, because I would have to transcribe the diagram, which is impossible then they can go check the video or something.

Stephan Livera: Right. Yeah. I mean, it is a difficult thing, because there’s a lot of important information that’s being conveyed through these talks, and even sometimes on podcasts. So, even with my podcasts, lately I’m trying to make sure we get transcripts going for it so that people can quickly get to the part they need.

Bryan Bishop: Yeah. I’ve actually been quite curious about that because I do see the transcripts on your podcasts, and I’m wondering who makes them. Do they get all the Bitcoin terms right on the first pass?

Stephan Livera: No. Definitely not. I use this website called rev.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.com I think they do all right, at least they’ll try to Google terms and try to get them. But there will 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, multi signature or whatever, different terms, Shamir’s, so they know what to Google or search. I think they quickly do a quick search. But obviously, it’s not perfect. I spend a bit of time going back through the transcript to fix it up, and get it ready for when I actually post it on my website. But hopefully that’s valuable for people. I’m not really sure, we’ll see.

Bryan Bishop: No, I certainly find it valuable. Funny story, a few years ago, I think it was Mark Friedenbach tapped me on the shoulder at a conference and said, “Bryan, you know, you’re a fast typist, sure, and it’s impressive and all. 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 conferences, and just automate this whole thing?” 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 Baidu’s Deep Speech. Since that time, Mozilla has actually done a really fantastic implementation of that in an open source [inaudible 01:07:23] at that. The problem with my version was that I had a 20% error rate with words. So, it didn’t quite work out. But the idea though, was that I was training on audiobooks because with audiobooks you have text, and then you have the audio. So, it’s a really good training source.

Stephan Livera: Yeah, I think that’s the difficulty. I think the guys at Rev do a decent job considering if you’re not a Bitcoiner it’s 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 are not really… They’re not in books. So, you kind of… I guess it’s a bit of model training, or whatever there has to happen before it gets to that level.

Bryan Bishop: 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.

Stephan Livera: Yeah, I mean, for me, I try to… 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 going. But it does add a bit more admin time, and so on of me correcting the transcript, and so on, and getting it ready to go. But yeah, I mean, hopefully people find value out of that. 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?

Bryan Bishop: Yeah. So, in Tel Aviv 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 lot of debate occurred over the travel role. Then there was a Bitcoin Edge Dev++ 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. All those videos will be posted, and there’s transcripts for everything there. Then there was Scaling Bitcoin, which was a two day conference at Tel Aviv University again. Scaling Bitcoin, of course, is more focused on academic research and advanced prototypes and concepts. It’s a good pairing to have training, and then more advanced concepts. I think that’s a good format for this.

Stephan Livera: Fantastic. I know, Bryan, you’re also involved with administering the Bitcoin Dev mailing list. So can you tell us a little bit about that?

Bryan Bishop: Yeah. This is somewhat janitorial work, I suppose. Anyway, for a few years now, I’ve been part of the team that’s been helping email get through the mailing list, and kicking out the spam and things like that. One of the 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 premier links are the same. And thankfully, Linux Foundation has agreed to that, to make all the premier links for the current mailing list archives, which many people reference in presentations, and papers, and around the web. It’s so important for me to have those hyperlinks remain there.

Bryan Bishop: In fact, if you look around the internet, the half life of any given link is less than a few years at this point. But in theory, it should be simple to maintain text email archives indefinitely. So, let’s hope that, that continues to be the case. But anyway, yeah, there’s 10s of thousands of subscribers on the Bitcoin Dev mailing list. One of the concerns when migrating, it’s like, should really all these email addresses be copied over to a new mailing list when the other one closes? It’s sort of a privacy thing, maybe not everyone wants that. But at the same time, a lot of people might be subscribed for the sake of security updates whenever those updates do occur.

Bryan Bishop: Recently, as an example, on the Lightning Dev mailing list, there was a signed message from Laolu saying, upgrade your nodes, there’s a vulnerability. If the mailing list was migrated to another server and people weren’t subscribed, nobody would have received that message. So, there’s trade offs on both ways of doing this.

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

Bryan Bishop: Yeah, I mean, that’s my current thinking, yeah.

Stephan Livera: Yeah. Okay. Well, yeah, I mean, I definitely appreciate being able to see some of the discussions live as they’re happening. Although sometimes, it’s Bitcoin, it feels like you’re drinking from a fire hose. Because if you subscribe to Bitcoin Dev mailing list, and the Lightning Dev mailing list, and you’re trying to follow what’s going on, it can be a lot to get into. Let’s talk about one of your other passions. 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?

Bryan Bishop: 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 academic labs at colleges. There’s all sorts of systemic effects for why other people are interested in this. For example, there’s a huge number of biology students and grad students out there that get disenfranchised from the academic system. Then they realize that some of the projects they want to work on they can pursue at home with their own means and resources without working with the university.

Bryan Bishop: In this area of biohacking and genetic engineering, I certainly have talked about my interests here before. I suppose though, for people who are unfamiliar, 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 very typical biohacking project. And this was the project to make some something called the Slybera, which is actually a knockoff piracy version of Glybera. Glybera is well known as being the most expensive drug in the world at $1.2 million as a gene therapy to fix lipoprotein deficiency, and it works. The problem is that it costs $1.2 million. Well, Slybera is the garage biohacker version. The presentation went on to show that a lot of this work can be replicated in your own garage for about $7,000 approximately, and that’s a million dollar drug.

Bryan Bishop: As drug prices rise, you look at these prices, and then 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 abiding entirely by regulatory agencies and what they decreed to be available to the general public is the best way to fix health problems that might be rapidly leading to end of life scenarios.

Stephan Livera: Absolutely. I think, to my mind, this is calling one of the big intellectual influences on my mind is the work of Stephan Kinsella. He is well known for being anti intellectual property. I think also from a libertarian point of view, we would be anti the FDA. We would have free market regulation of things as opposed to government regulation of who may ingest what drug or take whatever procedure. But perhaps in the Bitcoin future, we might see a lot more jurisdictional competition, then 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 Slybera there, that kind of thing.

Bryan Bishop: 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 sand boxes where people can opt in into the Wild West, or rating agencies where they do very thorough investigations and get a rating based off of their findings. But other than that, I don’t think that should be able to just outright ban things or prevent people from getting access to the medicines that they think they need.

Stephan Livera: Right. I suppose… Now, again, I’m with you on this, but I suppose the person who’s pro-intellectual property at this point may say, “But this company and 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 having regard for that?” I think the concealer response, or so might be that, look, you can’t own that. It comes to what is their property right in? But what’s your view there?

Bryan Bishop: Well, in my opinion, I actually think that the claim that 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 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 can operate a business where you offer this information, and then these systems for utilizing whatever this pattern really is, and people will gladly do business with you, if that makes sense. But if there’s either unreasonable licensing requirements or whatever it is, then yeah, of course people are going to try to do it themselves. Of course, they are. It completely make sense.

Stephan Livera: 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. At the start, something is only available to the rich, but then over time, it very quickly becomes available for everyone. I think that’s potentially a model that we may see with biohacking, and biotech. Do you have any thoughts on that idea?

Bryan Bishop: Yeah, I mean, absolutely. It comes back to exit and voice. If you don’t have a voice, then you exit the system, and that’s really what medical tourism is. It’s this idea that, in the US healthcare is broken, and especially healthcare billing for that matter. The idea is that you can get cheaper prices by going overseas to get your procedures. I think 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.

Stephan Livera: Fantastic. I know, obviously, I probably have many shared listeners with Marty Bent, and I know you recently did an episode with him on that, on Marty’s great show as well, so I recommend listeners to check that out. I guess also 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 going to happen?

Bryan Bishop: I think that extremely long lifespans are definitely physically, and theoretically possible. The question is when are we going to 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 something very hard to guarantee. No one knows if something will really live literally forever. In fact, forever in a physics context might not be a real thing. It said though, I mean, yeah. I think that in the future, it might be possible that humans will be able to have a 1,000 year lifespan, or a 10,000 year lifespan. I think that biologically, if you remain healthy, and relatively young throughout your lifespan then indefinitely age should be achievable.

Stephan Livera: Wow. Yeah. I guess 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 at what point, how old are you? Can they reverse age you? I guess that’s an even more tough question there to take someone who’s already healthy and keep them healthy.

Bryan Bishop: Yeah, so I have an interesting perspective here. I mean, everyone wants some sort of gene therapy that’ll reverse their aging process or something. And yeah, that would be great. Unfortunately, that’s a magic trick that people really don’t know how to make happen yet. I mean, the best ideas that we have are things like make synthetic organs or grow organs and things and replace all of your organs once every 10 years when you get up there in advance years, and hope that these replacement organs will keep you ticking. Maybe these replacement organs will be genetically enhanced in some way. But this is all quite speculative.

Bryan Bishop: 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 benefits apply to the next generation of people, your children mainly. People have concerns about that. One of the most frequent concerns I hear is, “Well, I want to live forever. I don’t care if my child has the 20% longer lifespan. I want a 20% longer lifespan.” Well, I mean, unfortunately, the time that we’re living in, 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 children have just better genes, different genes, being able to choose those traits than we are being able to extend a person’s lifespan, a person who is already an adult, their lifespan by 20%. That’s just, in my opinion, a significantly harder task.

Stephan Livera: Right. 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 they would then be able to invent the technology for everyone else to live longer as well.

Bryan Bishop: Oh, absolutely. Yeah it’s a feedback process.

Stephan Livera: Excellent. All right. Well, look, is there anything else you wanted to touch on today that we’ve missed?

Bryan Bishop: No, no. Not at all. This has been great actually. I’ve really had fun here.

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

Bryan Bishop: Oh, yeah, find me online at twitter.com/K-A-N-Z-U-R-E.

Stephan Livera: Fantastic. And also, I’ll put the links for your website, your personal website, that’s heybryan.org, and also your transcripts website, obviously, because people need to be aware and able to soak up that Bitcoin conference and also podcasts 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 out of this.

Bryan Bishop: Yeah, absolutely. It’s been fun. Thanks for having me on.