A review of the Multisig Self-Custody Scenario

[fresheneesz]

I reviewed the procedure laid out in the simple path in Multisig Self-Custody Scenario. I didn't pay much attention to the optional steps.

My main takeaway is that the guide as written has the following primary properties:

• Security / Theft resistance:
  • A theif needs to compromise 2 secure locations to steal funds (primary + secondary).
  • A theif willing to put you under diress only needs to visit your home to steal your funds.
• Loss resilience:
  • Normal: If no devices are broken/lost, all passwords are remembered, and you carry your phone on your person at all times, you can still recover even if any 2 storage locations are lost. All 3 main secure storage locations can be lost if you use the cloud backup addition.
  • Broken devices: considering only secure resilient backups (not electronic devices), you can still recover if 1 of your storage locations is lost.
  • Forgotten passwords: Forgotten passwords don't affect these things. Even if the passwords were not written down, this would be basically still true, except for as much as they might affect your access to cloud backups.

In general, this seems like a reasonably secure guide. My primary complaint with the guide is the recommendation to write down pins and passwords. I don't think this gains the user anything significant, but it introduces significant additional paths for the user to be compromised (eg writing down their apple account credentials means someone might be able to compromised their apple account if the location that's stored in is compromised).

The other issues I found are either opportunities to reduce complexity or minor improvements / questions.

Feedback in no particular order:

• QR Codes - I don't believe QR codes provide significant extra security. Shiftcrypto has a great article about this. It seems misleading to me to call fully QR code devices "second generation" as if its a breakthrough advancement. Eg QR Codes do not necessarily protect against buffer overflow. A bug can always enable buffer overflow with any data size. If animated QR codes, it becomes a fully active communication mechanism and doesn't have almost any related benefits over a fully connected channel - it is a fully connected channel at that point. QR codes are fine, and its fine to use them in this guide. My main complaint is about the explanation around QR codes is a bit misleading.
• I recommend considering using metal backups (like the Blockplate or Steelwallet) a seed storage medium vs paper. It doesn't add too much risk of process fatigue, and you know those backups are not going to be destoyed by fire or water or anything. That said, I think the choice of paper is interesting. I am currently recommending acid-free alkaline or archival paper, which should last for hundreds of years, however I don't know how resilient that kind of paper is to water or fire. I would be curious how long lasting the waterproof paper is that this guide recommends. I guess that fact that this guide relies a lot on printers, maybe the resilience of the paper isn't very important, because the printer ink won't last very long anyway. I recommend using an india ink pen which should last decades.
• The recommended Amazon Basics safe is not a good recommendation. It is not secure (can be opened with scissors and BIC pens, as you can see from reviews), its not fireproof, its not waterproof. So what does it give you? There are almost no secure home safes, but at least some of them have a proper locking mechanism. I'd recommend at least a safe that's waterproof and fireproof, since those risks are more likely than home theft. And being able to be bolted down is important.
  • This seems like a much more recommendable safe: https://www.amazon.com/SentrySafe-SFW123DSB-Fireproof-Waterproof-Combination/dp/B005P12F2K
• The guide doesn't have a way to verify the authenticity of the guide itself. You should be able to download the guide and verify it with a signature in the same way users are instructed to do so for Sparrow.
• It seems like the primary benefit of sharding the recovery is so that there is no single storage location that has in plaintext all the information to recover. It looks like it works pretty well for this setup.
• During setup, is checking all three combinations of the SSKR shares necessary? Isn't just checking 2 combinations enough?
• Does the Gordian Seed Tool have a debiasing process for the dice rolls recommended for creating Active Seed #1? If not, you might want to include a debiasing scheme in your instructions, like the one in Andrew Poelstra's Codex 32.
• Why do you instruct people to write down their iphone pin and apple account info and store it in Primary Storage? Seems unnessary and exposes your apple account to being compromised. Passwords and pins should be remembered, not written down. If you're trying to reduce the opportunity for someone to lose access to the seed on the phone, this is not going to be very effective. Its far more likely that a person breaks their phone and therefore loses access to the seed. If the user does not store any pins or passwords, the primary security and loss resilience properties don't change.
• Same thing with recording the Passport pin. You should not do this (the user might use this pin elsewhere, so compromising it might compromise other things). What's the point anyway if you're storing it in the same place as the passport backup?
• Nit: I found the image captions very confusing on github - they always look like section labels for the next section, when they're actually labeling what's above them. Maybe put the caption above the image it relates to?
• Note 48 says adding a password introduces a single point of failure. However I don't think that's true in this case because, like it says, its only encrypting the watching only wallet, so even if you forget that password you should still be able to recover just fine. I'm not saying you should recommend encrypting it, but it doesn't seem like a significant factor in this case.
• What's the purpose of backing up the sparrow wallet. Is that just for backing up transaction history metadata? And it mentions to do this "particularly if you decide to put a password on the wallet" - I don't see how the use of a password is related to backing up sparrow.
• Re note 52 about being specific or vague in your inheritance letter, a good middle groud in the case of a safe deposit box is to say the name of the bank your box is in, and then they would need to go to the bank with certification of your death in order to even know what specific location your deposit box is in. For a friend's safe, you can just say "This person has it" but not where they have it (home, bank, etc).

I have an interest in self custody solutions, especially multisig ones. I think guides like this one are very important and hopefully using and sharing guides like this will one day become standard practice for people storing any significant amount of bitcoin. I wrote The Tordl Wallet Protocols and I work for Unchained Captial. I would be very appreciative of a review of Tordl by anyone involved in Blockchain Commons.

[fresheneesz]

I thought of one other thing. This guide has a significant central point of failure: the Gordian Seed Tool. That tool handles two of the keys, meaning that theft could happen in any of the following scenarios:

• the Gordian Seed Tool's codebase or release process is compromised,
• Apple is compromised and uploads a malicious version of the tool,
• the Gordian Seed Tool's Apple account is compromised and the attacker uploads malicious releases,
• Github is compromised and injects malicious code or malicious releases,
• the user's network or machine is compromised, they decide to build from the source from github, and the attacker MITMs in a malicious version of the source code,
• The developers of the Gordian Seed Tool accidentally introduce a security bug, or
• The developers of the Gordian Seed Tool become malicious.

I would highly recommend that a different application than Gordian be used on the active seed. Electrum maybe? This seems to be the weakest link in this guide.

The other single point of failure is Apple, but it seems this was an intentional decision to trust Apple in order to simplify the guide for Apple users.

[ChristopherA]

@fresheneesz wrote:

I reviewed the procedure laid out in the simple path in Multisig Self-Custody Scenario.

Thank you! This is exactly the kind of detail we hoped to get from this early scenario draft.

@shannona and I plan to respond point by point, and either revise the scenario, explain better, or offer a rationale.

-- Christopher Allen

[ChristopherA]

I thought of one other thing. This guide has a significant central point of failure: the Gordian Seed Tool. That tool handles two of the keys, meaning that theft could happen in any of the following scenarios:

Actually, I had really hoped that Unchained Capital would update Hermit for the SSKR 1.0, as your team contributed code to the SSKR project. We were somewhat forced to use Gordian Seed Tool for the creation of offline seeds as we didn't have many other choices (yet). Maybe you can persuade Chris Howe to upgrade it?

Also related to Unchained, I was really hoping that we would have an update to Caravan for doing crypto-request QR URs and PSBTs. I'd love to have another scenario which is Caravan, Gordian Seed Tool, Passport, and maybe something like SeedSigner for offline keys (our summer interns are investigating adding QR UR support to it.)

-- Christopher Allen

[shannona]

Thanks very much for comments, @fresheneesz.

As @Christopher said, we were very appreciative of your comments, and at various times have taken the opportunity to better explain, to add rationalization, or to modify the text. Here's a run-down of about the first half of that, with more editing planned for next week week when I'm available again.

First, a few comments on your overall take-away:

I.

A thief willing to put you under duress only needs to visit your home to steal your funds.

Yep. we cover this in our Adversarial appendix, but I've added some text to better explain why we ignore some current options:

We are aware of some solutions, such as the fact that the Keystone wallet can create passphrase wallets that only become visible if you know the passphrase. Generally, we feel these accentuate other problems, specifically: (1) there is higher chance of loss for an "invisible" wallet, especially to heirs; and (2) there is a real chance of personal death for refusing to turn over a secret wallet under coercion. As with everything, it's a question of balance, and we balance vulnerability to this adversary as less important than loss or death.

II.

Forgotten passwords: Forgotten passwords don't affect these things. Even if the passwords were not written down, this would be basically still true, except for as much as they might affect your access to cloud backups.

In general, this seems like a reasonably secure guide. My primary complaint with the guide is the recommendation to write down pins and passwords. I don't think this gains the user anything significant, but it introduces significant additional paths for the user to be compromised (eg writing down their apple account credentials means someone might be able to compromised their apple account if the location that's stored in is compromised).

We obviously need to clarify this, because forgotten passwords absolutely do lead to loss of assets. We know of real cases where forgotten PINs for Ledgers or Trezors endangered millions of dollars in Bitcoin assets. In our scenario, loss of the Passport PIN causes the loss of the Passport data, and loss of your Apple PIN causes loss of the GST data. Now, you can get the Passport via another means if you have the backup (and password), but the loss of Apple login info can be absolute.

This is particularly critical for situations where heirs may need to recover your funds. Without written passwords and PINs they cannot. But, I've certainly forgotten enough passwords and PINs over the years to consider it a threat even to my own holdings.

The flipside of this is that the whole setup is carefully designed so that you never have a PIN/password and the thing it unlocks in the same place. (And if you think we messed that element up anywhere, please let us know.)

So, better explanations were needed for all of that, and let me know if there's anything that you find incorrect or unbelievable.

Writing Passwords. We suggest the recording of passwords and PINs, but you should be aware this does create a potential danger. Our purpose is twofold: (1) we don't want you to lose your own PIN or password, and we've lost enough over the years to know this is a real danger; and (2) we want your heirs to be able to recover your funds. We consider the latter particularly important, because heirs will have no guaranteed way to otherwise know your access info. (How many times has my wife told me the PIN to her phone? Pretty much every time I have to use it.) If your heirs don't have your Passport PIN, they cannot access your Passport (though maybe they can access the Passport backup, with that password); if they don't have your Apple PIN, they have no way to access your Gordian Seed Tool key. Basically, every lost password can result in a lost key, though that's not guaranteed because of our other backups, and with two lost keys, it's game over. We offset the danger of recording your PINs and passwords in two ways: (1) by never placing an object and the key that unlocks it in the same place; and (2) by the implicit conceit of the scenario, that two keys are required to do anything. The biggest danger in this setup is that you're leaving bare an Apple login that might be used for other purposes, so consider that, but also consider the dangers if you're killed or incapacitated (or just forgetful).

III.

QR Codes - I don't believe QR codes provide significant extra security.

We definitely disagree on that. I think there's room for considered and fair argument on how great the security improvement is, but I'm pretty sure something is there. I think the buffer flow bug is a fine example: yes, a QR code can still buffer-overflow a badly written hardware wallet, but without an interactive possibility for back-and-forth the damage is much more limited and much harder to take advantage of. Take the example of the classic buffer overflow, when the Morris Worm attacked fingerd. Basically, a buffer overflow allowed the creation of a new worm on the remote machine. If that occurred in an airgapped situation, the user would then have to agree to let his device talk to another fingerd (basically, a connection he didn't request) and then he'd have to OK the sending of a worm-QR (which would require the info-reporting software on both sides of the gap to be compromised). That's very different from a situation where communications can occur without user OK on both sides. And, even if an export were successful, the speed of the attack would be so slow that it would be detected before major damage was done, at least for the overall ecosystem.

I've added some notes on this, to better explain our rationale behind our belief:

Airgap Security. Are airgaps really more secure? We believe so, and we believe that's why the newest generation of hardware wallets is using them rather than the linked but limited connections of the first generation. For us the biggest security gain of airgaps is bilateral control. The user makes the decision to affirm and send the data from his computer to his signing device and from the signing device to his computer. Assuming good UX designs, he should get confirmation on what's contained in the message on each side for each transfer. The second biggest gain is the lack of connected interactivity. Though a buffer overflow is certainly still possible through a QR code, the lack of direct interactivity makes it much harder for an attacker to see the results of that overflow, to gain information from that overflow, or to gain control due to that overflow. It's like controlling army battalions with letters rather than a walkie talkie: possible, but at a much higher level of difficulty. Finally, we see gains in the fact that an airgap massively slows down any attack. The infamous buffer-overflow of the Morris Worm crippled the internet because of its high speed of spread. Airgapped attacks spread only at a user's speed of transfer. There are certainly people in the space who have decided not to implement airgaps because they believe otherwise. And, they do point out some continued vulnerabilities, like the attack surface of firmware upgrades. But we believe that multiple and important security improvements exist due to airgaps, and that there is fundamentally no loss of convenience (possibly even a gain, with there no longer being a need to hunt up cables).

IV.

I recommend considering using metal backups (like the Blockplate or Steelwallet) a seed storage medium vs paper.

Yep, that's clearly a superior choice, since it's water-proof and fire-resistant. But we do also thinks there's a real cost in convenience every time we require an additional purchase (let alone the time required to etch or lay in tiles, as we've experimented with both), and the threat is always that we tell users to do too much and so they do nothing.

In any case, we do have "metal storage" in our alternatives section, and based on your suggestion, we've highlighted it better:

Finally, see Additional Steps for some additional purchases you could make to improve resilience even more, at the cost of some complexity. We think that fire-resistant bags, tamper-evident bags, and metal storage can all give notable improvements without a lot of cost.

V.

I am currently recommending acid-free alkaline or archival paper, which should last for hundreds of years, however I don't know how resilient that kind of paper is to water or fire. I would be curious how long lasting the waterproof paper is that this guide recommends. I guess that fact that this guide relies a lot on printers, maybe the resilience of the paper isn't very important, because the printer ink won't last very long anyway. I recommend using an india ink pen which should last decades.

I'd be happy to get any specific recommendations you have for archival paper and India Ink, particularly if the paper can be used in a printer and if they're available online.

We've also added notes to all the Storage reviews that the user should ensure the readability of all of his written data, which means he'll be looking at all that paper and assessing it ever year. And that even for tamper-evident bags, a user should open them every five years or so to take a look. Personally, my oldest tax records currently on hand, from 2013, printed off a cheap-o inkjet, still look crisp and new, so I suspect it's a minimal problem unless things are being left in the sun, but definitely one that should be considered from time to time as some people will do that. Thanks!

VI.

The recommended Amazon Basics safe is not a good recommendation

Thanks, I've added your rec as a safer option.

I've also added some notes on our philosophy:

Which Safe? Our fundamental belief is that the main purpose of a safe is to deter casual theft, so that someone doesn't idly pick up one of your keys or signing devices and make off with them. Even for a break-in, all a safe has to do is be more than 8-12 minutes worth of trouble, and it'll keep your material safe. On the flipside, if a burglar is purposefully going after your key material, no safe, not even one bolted down, will keep it protected from a determined attack. So which safe do we recommend? A cheap safe is likely to meet most of the basic criteria, but if you've got a substantial cryptocurrency holding, then obviously you should spend the money on a more expensive safe to help protect it.

VII.

The guide doesn't have a way to verify the authenticity of the guide itself.

That's a good point. I was going to add in a procedure for signing it, but then I realized that all of the commits from myself and Christopher are actually Verified, so at least for now we can rely on that. (It might still be good to sign it, or possibly the whole SmartCustody guide, for full releases.)

You can verify the authenticity of this scenario by looking at the history of this file and seeing that all recent commits were made by @shannona or @ChristopherA and that they are Verified, which means they were signed with a registered GPG key. We may offer a more formal signing of this file or the #SmartCustody book in the future.

VIII.

During setup, is checking all three combinations of the SSKR shares necessary? Isn't just checking 2 combinations enough?

I don't know that we can provably say that A+B = seed and B+C = seed means that A+C = seed. If we've checked all three shares in the two combinations, then it seems extremely extremely likely that we're safe, but I wouldn't want to create a situation where somehow we found there was a bug and the last combo didn't combine correctly. So, since users could return any two of the three shares (and might only have two out of the three), I'd like that to be pre-tested. But, it's an excellent question that allows us to talk a bit about our philosophy.

The Third Check. But is the third check really necessary when we already know all three shares are valid from our previous checks? Probably not in any reasonable situation. But responsible key management means checking out the unreasonable situations when it's reasonable to do so. We don't just want to know that all three shares are valid in some situations, but that all three shares are valid in all situations, and that there's not some bizarre bug that keeps the third combination from being combined. Because there's a 1/3 chance that it might be the combination you need to restore your recovery key. So, in this situation, where we can scan QRs back into Gordian Seed Tool in 60 seconds or less, we take the time to do so.

More in a few days! Thank you for the comments and improvements!

[fresheneesz]

@ChristopherA

update Hermit for the SSKR update to Caravan for doing crypto-request QR URs and PSBTs

Ah interesting. Do you know worked on SSKR stuff? Was it Chris? I believe Caravan does work with PSBTs already. But as far as feature requests, it'd probably go a long way to write a couple feature requests on github issues, and wouldn't hurt to ping some people over here. As far as Chris, he's got his hands full at the moment, so not sure when he'd have time to look into this. But I let him know you mentioned him.

forgotten passwords absolutely do lead to loss of assets

In our scenario, loss of the Passport PIN causes the loss of the Passport data, and loss of your Apple PIN causes loss of the GST data. Now, you can get the Passport via another means if you have the backup (and password), but the loss of Apple login info can be absolute.

though maybe they can access the Passport backup, with that password

Ah i see, the "Passport Words" is really a password that protects the passport backups. Is that right? I missed that. Might be clearer to call it a "passport backup passphrase". Or if that conflicts too much with Passport terminology, maybe write "Passport words (backup passphrase)"? I thought the passphrase was to unlock the passport device.

Is there any other non-device backup that's password protected that I missed?

It would be very useful to add recovery steps: what to do in various recovery cases (you've lost a storage location, a key was compromised, you died and you heirs want to recover your coins). Take a look at the "Actions and Events" section in one of the Tordl guides for what I mean. I certainly could do a better job desscribing recovery scenarios, especially inheritance, but I think its a good idea to give clear steps to the user on how they should handle various uncommon or infrequent situations, since those are always going to be more prone to error. If instructions for this were there, it would have been much clearer to me exactly what's needed to restore funds.

In any case, revising my understanding, here are the properties as I see it now:

Security / Theft resistance:

• Normal: A theif needs to compromise 2 secure locations to steal funds (home + primary/secondary)
• Diress: A theif willing to put you under diress only needs to do it at your home. Loss resilience:
• Normal: If no devices are broken/lost, all passwords are remembered, and you carry your phone on your person at all times, you can still recover even if any 1 storage location is lost. 2 secure storage locations can be lost if you use the cloud backup addition. Broken devices: considering only secure and resilient backups (not electronic devices), you can't necessarily recover if even 1 of your storage locations is lost (your home location with the passport backup passphrase). If you have the cloud backup addition, you can lose up to 1 storage location and still recover (assuming its possible to sign into your cloud backup with a new device). Forgotten passwords: If you've forgotten all your passwords (pins etc), you can recover even if 1 of your storage locations is lost. The cloud addition doesn't help much here (since if the primary storage is lost, you won't be able to access your cloud storage. Broken devices + Forgotten passwords: Same as with just Broken devices.

The primary difference between my new understanding and what I thought the guide was saying is that my new understanding is that this setup is less resilient. Fewer storage locations can be lost while still preserving recoverability. Am I still misunderstanding something? If not, it seems like perhaps the guide could be improved by doing things the way I misundertood the guide to be: don't password protect the passport backups. It doesn't seem like password protecting the Passport backups gain you any security, and it seems you're losing a significant amount of loss protection by doing that.

without an interactive possibility for back-and-forth the damage is much more limited and much harder to take advantage of

Agreed. But QR doesn't have a monopoly on limiting interactivity. A connected line could also be programmed to be non-interactive (eg by hard wiring it to only be able to send data when a user manually presses a button). And while I agree a QR code situation does make it harder even for malicious firmware to communicate with the outside world, it certainly isn't impossible. For example, if there's any kind of controllable light source in front of the device and a camera in back of it, that's a potentially unbounded open channel. So while yes, its more limited, I would say its pretty debatable how significant that really is in terms of security. A properly built device that uses USB should be just as secure. That's not to claim that any particular device is properly built enough to have a comparable surface area to QR devices tho.

the speed of the attack would be so slow that it would be detected before major damage was done

Similarly to the above, a connected usb plug can also build in this kind of speed limitation. QR isn't the innovation here, but more of an accident of how QR works. Faster things can always be made slower.

In any case, we don't have to agree : ) And your elaboration there seems reasonable to me, especially since it notes that there are those that disagree.

I'd be happy to get any specific recommendations you have for archival paper and India Ink, particularly if the paper can be used in a printer and if they're available online.

It looks like the TerraSlate paper you recommend is acid-free as well. This reference to Rite in the Rain All-Weather paper says its acid free as well, tho most listings don't mention that. Here's some info on the benefits of acid-free paper. Both paper says they don't support inkjet printers btw, there's people complaining about that in reviews.

In any case, as far as resilience, the paper types you're already recommending look like quite good archival paper already. I might swipe those recs for Tordl ; )

[shannona]

IX.

Does the Gordian Seed Tool have a debiasing process for the dice rolls recommended for creating Active Seed https://github.com/BlockchainCommons/SmartCustody/pull/1? If not, you might want to include a debiasing scheme in your instructions, like the one in Andrew Poelstra's Codex 32.

It does not. We've added a mention of how to improve dice-rolling randomness.

[^debias]: Debiasing Dice. Dice can be biased! (So can cards and coins for that matter, but especially dice.) You can improve the quality of your dice by buying Casino-Quality Dice or Gamescience Dice. If it's a large concern, you can also (or alternatively) debias your rolls as Andrew Poelstra describes in this paper. However, the main goal here is for you to use a safe means to generate the entropy for this seed, so if any of that sounds reasonable do it, and if any of that doesn't, then just use your dice rolls as they come.

X.

Why do you instruct people to write down their iphone pin and apple account info and store it in Primary Storage? Seems unnessary and exposes your apple account to being compromised. Passwords and pins should be remembered, not written down. If you're trying to reduce the opportunity for someone to lose access to the seed on the phone, this is not going to be very effective. Its far more likely that a person breaks their phone and therefore loses access to the seed. If the user does not store any pins or passwords, the primary security and loss resilience properties don't change.

I've forgotten password, I've forgotten PINs, and when I die, there's no one around to remember them at all. So, we consider them pretty important. Without them, a user can pretty rapidly start losing access to devices, and if a few problems occur simultaneously, seeds. Without the passwords, only the sharded SSKR seed is available.

Also, the user doesn't lose access to his seed when he breaks his phone. He restores it from Apple Cloud to his new phone provided he knows the password to his apple login and the PIN for one of his past devices. So that's actually the exact reason this is required. Anyway, this should be well-covered by the new "Writing Passwords" not previously.

XI.

Same thing with recording the Passport pin. You should not do this (the user might use this pin elsewhere, so compromising it might compromise other things). What's the point anyway if you're storing it in the same place as the passport backup?

The Passport backups are probably the most fragile part of the setup because the backup words aren't going to be as easily remembered as a PIN. But the main point is redundancy and ease of use. If a user forgets his PIN, yes he can unzip his file and read it as long as he has the backup file and the backup words. But for an heir, that's not going to be nearly as easy to use, and greatly increases the chance of loss.

I think that's the main thing that the procedure concentrates upon that might not be obvious: the ability for heirs to recover money in case of death or disability.

We added a few mentions of this:

• A holder who cares about leaving assets to heirs or trusted parties in the case of death or disability.

And:

Even if you feel like you'll remember your passwords and PINs (and both case studies and personal experience say that's not the case), we want to make sure those secrets are available to heirs in case of death or disability.

To supplement the following assumption, already in there:

• Inheritance is Desirable. We assume that the asset holder cares about benefiting heirs after their own passing. Omiting this option would create better security.

The point about PINs is a good one.

Safe PINs. Obviously, you should use different PINs for different device whenever you're able. You especially need to use different PINs for your Apple iPhone and your Passport, so that a single PIN doesn't become a single point of failure. These two PINs should also be different from any other PINs you have (for bank accounts, door entry, etc.) since you're going to write them down.

XII.

Nit: I found the image captions very confusing on github - they always look like section labels for the next section, when they're actually labeling what's above them. Maybe put the caption above the image it relates to?

Yeah, that's fair. Mermaid, which does our diagrams, unfortunately doesn't have a good methodology for captioning them, so I made do.

I've chosen a different methodology (basically p-align-center instead of h4) to create better differentiation.

XIII.

Note 48 says adding a password introduces a single point of failure. However I don't think that's true in this case because, like it says, its only encrypting the watching only wallet, so even if you forget that password you should still be able to recover just fine. I'm not saying you should recommend encrypting it, but it doesn't seem like a significant factor in this case.

Quite true. I've revised that comment:

Why No Password? Passwords create friction for accessing your system. Often that results in a SPOF, where the loss of the password can cause the loss of your secrets. In this case, all you'd lose is access to your read-only wallet, but that might be a crucial loss for your heirs or executors, who could find it much more difficult to access your assets without the ease-of-use of a transaction coordinator that already has your account information preloaded.

XIV.

What's the purpose of backing up the sparrow wallet. Is that just for backing up transaction history metadata? And it mentions to do this "particularly if you decide to put a password on the wallet" - I don't see how the use of a password is related to backing up sparrow.

Good question! Added a note!

Why Backup? Theoretically, this isn't required: there's no secret information kept in your transaction coordinator. The backup is to make it easier to reconstruct your multisig account, particularly if that's done by an executor or heir who might not have the same knowledge of digital assets as you do.

Removed the note about passwords, because yes that's doesn't seem relevant.

XV.

Re note 52 about being specific or vague in your inheritance letter, a good middle groud in the case of a safe deposit box is to say the name of the bank your box is in, and then they would need to go to the bank with certification of your death in order to even know what specific location your deposit box is in. For a friend's safe, you can just say "This person has it" but not where they have it (home, bank, etc).

Thanks, those are some fine examples and have been worked into the text.

Specific or Vague? When you are writing your letter to your heirs, you can be either very specific, listing exactly how they can access your funds, and where all the puzzle pieces to do so are; or you can be vague, saying what they'll need but not where they are. Being specific means that a thief breaking into any of your storage then has a blueprint for where the rest are and how to access your digital assets. Though there's still no Single Point of Compromise, there's now a Single Blueprint of Compromise. Being vague means that your heirs might fail to access your funds if they don't know where all the pieces might be kept. There are compromises. For example, if your Primary Storage is your Bank Safety Deposit Box and your Secondary Storage is at a friend's house, you could be very specific about the bank (because anyone else would need a death certificate to access the box), but just mention your friend by name without saying where he has it. Ultimately, you need to decide whether theft or loss is more likely and plan accordingly. Our general analysis is accidental loss is a lot more common than individual theft, and so we suggest moving toward the "specific" side of the equation.

[shannona]

Re: II

Ah i see, the "Passport Words" is really a password that protects the passport backups. Is that right? I missed that. Might be clearer to call it a "passport backup passphrase". Or if that conflicts too much with Passport terminology, maybe write "Passport words (backup passphrase)"? I thought the passphrase was to unlock the passport device.

Yep. The PIN unlocks the Passport. There was some inconsistency in the naming within the scenario, which I suspect caused the confusion. Hopefully better now, standardized on "Passport Backup Words", with an explanation of what they are.

Is there any other non-device backup that's password protected that I missed?

The Apple Cloud info from GST is only accessible from your current device (usually requiring some type of biometric login) or on a new device with a login to your Apple account and either proof of knowledge of a previous PIN or else Apple Recovery info you've set up.

It would be very useful to add recovery steps: what to do in various recovery cases

I agree. There's a few larger scale additions we want to make to the guide. I've added this one.

Re: Overall model

Broken devices: considering only secure and resilient backups (not electronic devices), you can't necessarily recover if even 1 of your storage locations is lost (your home location with the passport backup passphrase). If you have the cloud backup addition, you can lose up to 1 storage location and still recover (assuming its possible to sign into your cloud backup with a new device).

This is only sort of true, but it's hard to model because of the high number of variables, making it quickly grow to an n-dimensional chart. We largely consider losing a device and losing your home storage as the same, so losing your device AND a primary or secondary storage is very similar to losing two of your storage locations (home + one other), and yes, could result in loss.

Forgotten passwords: If you've forgotten all your passwords (pins etc), you can recover even if 1 of your storage locations is lost. The cloud addition doesn't help much here (since if the primary storage is lost, you won't be able to access your cloud storage.

Again, it depends. I had one version of the scenario that looked at losing your passcodes, and finally decided it didn't matter because your passcodes are all backed up. The bottom line is that of the three locations (Home + Primary + Secondary), you have to lose two to have likely asset loss. Even then, if you have things in the cloud and/or memory you might be able to recover.

Re: III

Agreed. But QR doesn't have a monopoly on limiting interactivity.

Similarly to the above, a connected usb plug can also build in this kind of speed limitation.

I notice you say "QR" and we say "airgap", so that's probably one good point to mention.

Otherwise, you say other methods could introduce these limitations, and we say airgap requires it. So that's probably another.

Going to introduce some additional clarity on that, thanks!

Re: V

It looks like the TerraSlate paper you recommend is acid-free as well. This reference to Rite in the Rain All-Weather paper says its acid free as well, tho most listings don't mention that. Here's some info on the benefits of acid-free paper. Both paper says they don't support inkjet printers btw, there's people complaining about that in reviews.

Thanks, I've added your link on acid-free paper

[ChristopherA]

@imansayadi3 I've deleted your comment to this issue, as I was not able to puzzle out what parts were your comment vs quoted text from previous comments.

Please don't use email to reply to Github comments unless you are careful to remove all the extra material (quotes, signatures, etc.)

[shannona]

Thanks for the comments, @imansayadi3, they've add clarity to the document, helped us to better explain our thoughts and methodologies, and also corrected some issues here and there.

I'm going to leave this open for a bit for any final responses, as I know the last set produced some more good additions.