 The next question comes from Brisbee, I believe, in not your keys, not your coin. But is the keyless, seedless, threshold signature cryptography stuff any better or safer for hot wallets? Good question. So let's talk about keyless, seedless, threshold signature cryptography. This is based on a recent paper that was published by a doctoral student at Princeton University... ...that suggests a mechanism for doing threshold signatures in ECDSA, which is directly applicable to Bitcoin. ECDSA is the digital signature algorithm on an elliptic curve that is used in Bitcoin. Threshold signatures allow you to construct a signature as a sum of parts of signatures that can be distributed to different devices. So it's effectively multisig without the multisig. You can create threshold signatures where you require certain thresholds to be met. If you have three of the five parts or two of the three parts of a key, you can sign a transaction with that threshold signature. What is the advantage of a threshold signature versus a multisignature? When you sign the multisignature transaction, you broadcast to the world exactly what the multisignature scheme is. Within the signature, you also provide the script-sig, which is the script that you are signing. What that contains is the exact prescription or recipe of the multisig. We will say, here is a script that expects two out of three of the following three public keys. Here is a signature that belongs to one of them, and here is another signature that belongs to another one of them. Therefore, we have satisfied this script. Every time you sign with a multisig, you reveal what the scheme is. You show what the K of N or M of N scheme is, so you know it's two out of three. You also show all of the public keys that are involved, even the one that didn't sign. That's a lot of privacy-leaking information. Someone who is watching the blockchain can now construct a pattern and see that this was how it was signed. They know a lot about it. They may know what wallet created it based on the type of scheme it's using. They may also, over time, if you are reusing multisig, be able to see that it's the same person and do statistical analysis. That is one of the disadvantages of multisig. With threshold signatures, it looks like a straight public key signature. What you don't know is that in order to construct the public key and the signature, you had to add together several public keys and signatures to achieve a threshold that is not visible to anyone. But all you know is that the signature satisfies the public key. It looks like a straightforward pay-to-public key, which is a standard payment. You can't even tell that it's a script. This was implemented, a threshold signature cryptography was implemented recently over ECDSA, and some projects have implemented wallets that allow you to do a special type of multisig, which is multi-factor multisig. You can think of multisig as being useful in two ways. One is three people get together, and they have one key each, and they create a two-of-three multisig. You have a multisig that is a multi-user multisig for three people. Another way to use multisig, which is very interesting, is multi-factor multisig. That's where, let's say, I have two devices and a backup key, and I construct a two-of-three multisig, where I own all three keys, but I own them on different devices. So let's say I have one key on my laptop, I have one key on my phone, and then I have a third key that I simply back up and put in a vault. I can do this also with mnemonic seeds instead of keys, so that I can have multiple keys coming out of them. Now, if I do that, then if I want to do a transaction, I have to sign on my laptop, and then I have to sign again the same transaction on my mobile or smartphone, so that I get two out of the three. If I lose one of the two devices, I go to my backups and pull out the third key, and I use it to move all of the funds and construct a new two-of-three multisig, in which I actually still have all the keys. Multi-factor multisig is a very useful security mechanism, but if you do it with traditional multisig, you reveal the fact that you are using multisig every time you use it. So this was a recommendation and a project to do that with threshold signatures, which do not reveal that. Unfortunately, the security of ECDSA threshold signatures is not exactly proven yet. In fact, I think there is a much better way of doing threshold signatures, and that is using Schnorr signatures. With Schnorr signatures, there is formal proof that threshold signatures are actually equivalent in security to regular signatures. So you can actually prove the security model with a formal proof. So we will be able to do threshold signatures with Schnorr, and together with tap-routes and tap-scripts, which are two new proposals, you can do this kind of multisig that looks like a single signature payment to a normal payment. But it is actually multisig behind the scenes. You can do that with the combination of technologies. It's great for security, it's great for privacy, it gives you that perfect balance. I think we are going to see more use of threshold signatures, especially for the use case of multi-factor multisig, where a single user is using multiple devices, to increase their level of security. I hope we see it with Schnorr signatures, which are not only more compact, but where that threshold signature scheme is being proven to be secure. Key storage, best practices for organizations. Hi, Andreas, what are the best options for organizations to securely store their digital assets long-term, where multisig is required to spend? Thanks, Dave. This is a very difficult question to answer, primarily because the needs of different organizations vary so much, that it's difficult to know exactly what the best option is. But I think a general good recipe is to use industry best standards and best practices that already exist, that are well understood, and not try to do some kind of weird implementation where you only know how it works. What would I mean by industry best standards? I would, for example, consider building a solution based on a combination of technologies, such as BIP39 mnemonics, that produce BIP32 hierarchical deterministic wallets, that are used under a BIP43 scheme to produce hierarchical multisig wallets, under, for example, BIP48. And these are then backed up on paper, and the seeds themselves are produced and stored on hardware wallets, preferably not a single vendor's hardware wallets, but a number of different vendors' hardware wallets to have a bit of variety. And then with sufficient backups and sufficient number of keys that the organization can survive, the kind of accident that might take out, for example, two directors at the same time. If you have a big organization and there's lots of directors, you want to carefully construct a scheme, so that there's enough redundancy, but you don't have so many keys that it's trivial to break them. Then you have to consider how you do the signatures themselves. Generally speaking, it's best to use signing in different locations, where the different directors can use, for example, a hardware wallet, on to a computer that is not connected to the internet, where they transfer what's called a partially signed Bitcoin transaction, or PSBT, sign it, and then pass it along to the next person in the chain until it's properly signed and transmitted to the network. This is a common scheme that's used by a lot of exchanges. So, a lot of exchanges will have their cold storage in some kind of multi-sig, maybe a two-of-three, maybe a three-of-five, maybe a four-of-seven, or five-of-eight, or some scheme like that. And some keys will be in vaults, some keys will be given to directors, they'll be on hardware wallets, also backed up in vaults, and they'll pass a transaction for signing, authenticating that the transaction actually is a legitimate one, with multiple people getting involved, so you don't have a single point of failure, and you have sufficient backups. This is the kind of thing that requires a very careful consideration of what are the specific threats you're protecting against, what are the threat vectors, what kind of attackers are you protecting against? Is this for protecting against state-level actors? Are you looking at a multi-jurisdictional solution where you want to protect against confiscation of funds by a state-level actor? Are you simply looking to protect against the kind of opportunistic criminal theft? Are you looking to do recovery for business continuity and planning purposes? Are you in the kind of environment where the directors might work in the same office, which might be dangerous, if something happens to that specific location? All of these considerations need to come into how you build an organizational key management policy. But also, there are quite a few complexities that come up when you try to do this. One of them, for example, is that today's multi-signature schemes are static, which means that once you've built it, if you then fire one of the directors, or you have to recycle or change one of the keys, because something happened to one of the keys, what you have to do is sweep all of that cold storage to a completely new set of keys that you construct new addresses from. So there are a lot of challenges to any such scheme. Another approach to use, which is also commonly used, is to use some kind of Chameer secret-sharing scheme where you take a single key and you break it into lots of parts. The problem with that is that every time you sign, you have to bring the parts together. And at the moment when you bring the parts together, that key exists in its entirety in one place, and that's extremely vulnerable to attacks, not the best solution. So those are some of the key storage best practices for organizations. I know I rattled off a bunch of BIPs. BIP39, BIP32, BIP43, BIP48, and you should look those up and see what they're about. But it's kind of the standards we use across hierarchical deterministic multi-sig wallets based on hardware wallets and mnemonic seeds. Matthias asks, how do I turn a single BIP39 recovery seed into a two-of-three recovery seed? In more detail. I've heard on one of the previous videos that you can turn a single BIP39 recovery seed into three BIP39 recovery seeds, where you would need two out of three to reconstruct the original seed. I'm interested, because this can be done without moving a balance into a multi-sig address. What's the best way to do this? So what Matthias is asking about is a way of implementing a Chameer secret sharing scheme on BIP39 mnemonics, that allow you to take a mnemonic and convert it into a K-of-N Chameer secret sharing scheme that can reconstruct the original seed. You could do this manually. You could implement your own scheme for doing this, but that produces results that are difficult to replicate. There's now a standard for doing this, and the standard is called SLIP39. SLIP39. SLIP is a Satoshi Labs improvement proposal, which is a set of improvement proposals coming out of Satoshi Labs, the company that built the original Tresor, and still builds the Tresor. SLIPs define a number of critical components of how BIP39 seeds work, because Satoshi Labs is the company that proposed BIP39 seeds in the first place. What SLIP39 allows you to do is take a BIP39 mnemonic and split it into any K-of-N combination, which is then presented as a series of words. Each of the N shares is presented as a series of words, so they look like mnemonic seeds. It takes two out of three, or three out of five, or whatever K-of-N you've selected, in order to reconstruct the original mnemonic. The mnemonic used for SLIP39 is different from the mnemonic words used for BIP39. SLIP39 uses a different dictionary or word list to produce these words for a number of reasons, which you can read in the specification of SLIP39. This is, at least for now, the standard way of doing a Shamir shared secret. What this allows you to do is take a single mnemonic that you have, for example, for your cold storage, and produce, let's say, five copies of it. You can reconstruct your original mnemonic with any two of those copies. That will give you a lot of redundancy, so you can put these five copies in different places. As long as you can recover any two of them, you can reconstruct your original mnemonic. If someone is able to take one of them, or compromise as one of your storage locations, they've got nothing. You can also combine this technique with a passphrase. You can have SLIP39 shares that produce a BIP39 mnemonic that only leads to your funds if you also have the memorized passphrase. That's another factor that increases your security. That's the standard, SLIP39.