Collaborate with bitcoinhodler's fork

[secinthenet]

proof-wallet and the fork of @bitcoinhodler seem to be the only active Glacier forks, and both seem to have similar goals. I plan to review the code of both forks and as a result I may propose some changes. So, I'm thinking it makes sense to try to collaborate. There's two options I see here:

• Move to a single canonical repo, and use branches for experimental changes and quick changes one of you want to make. This will add some overhead when merging to master.
• Keep the repos separate, but make them more consistent, so that it's easier to merge changes that benefit both repos. For example, keeping the Python formatting consistent, and separating shared utility functions to separate files will make it easier for one of the repos to import changes from the other. It will also make it easier for me and other people to review the code of both repos, since the shared code will be cleanly separated.

Another benefit of doing this is that it will be easier to build a community around the projects, and hence get more scrutiny.

Thoughts?

/CC @bitcoinhodler

[hodlwave]

Hi @secinthenet,

Apologies for the delay, I totally missed this issue. I would be happy to collaborate on some joint effort of this nature. I haven't looked through the other repo's code that thoroughly, but I think @bitcoinhodler and I have taken some different design decisions. For example, I use the BIP39 reference implementation and implement HD multisig whereas his repo just deals with single keys like the original glacierscript. Further, I wanted Proof Wallet to break out of the monolithic nature of Glacier Protocol, and instead have it be interoperable with other offline signers in a heterogeneous quorum. I thought that this would be beneficial to attracting users that didn't want to only have to rely on Proof Wallet in case it had some flaw/bug.

In any case, I'm interested, and I would really appreciate any review of the code. Thank you!

[secinthenet]

Hi @hodlwave AFAIK @bitcoinhodler also has some interest in HD, though they may not use it yet because of the added complexity.

I also think it's important that Proof Wallet will be interoperable with other offline signers such as hardware wallets. My understanding is that this is nearly fully achieved by using HD and PSBT, but the missing piece is multiple QR codes? Hopefully there will soon be a standard for using multiple/animated QR codes to pass data that doesn't fit in a single one (I read somewhere that Cobo are working on it, and I recall something related to Blockchain Commons).

Back to the core of this issue: even with the HD/non-HD difference, I think the majority of the code can be shared. I can try to create PRs to both projects that try to do this, but I want to check if you're onboard so that the PRs have a chance to be merged (@bitcoinhodler will need you to nod here as well). The best approach I see to maintain this shared code going forward is to separate all the common functionality to a separate repository (say libglacier), and referencing it as a git submodule in both forks. This way, both you maintain control over your own forks (including the version of libglacier which will be pinned in both projects to the commit hash). I can also try to set up CI to verify that changes to libglacier don't break tests.

Do you have any thoughts with regards to how to split functionality across files? personally I don't like many small files, but huge files are also somewhat unelegent (and linters won't catch issues like calling functions that should be private if they were placed in another file).

[hodlwave]

Just added issue https://github.com/hodlwave/proof-wallet/issues/5 to implement support for UR.

I did a quick comparison of the functions that appear to be the same or essentially the same between the @bitcoinhodler fork and proof-wallet:

Hashing functions
* hash_sha256
* hash_md5

RNG
* validate_rng_seed
* read_rng_seed_interactive
* validate_dice_seed
* read_dice_seed_interactive

Private key generation
* xor_hex_strings

Bitcoin utils
* ensure_bitcoind_running
* require_minimum_bitcoind_version

QR code utils
* decode_one_qr
* decode_qr
* write_qr_code
* write_and_verify_qr_code

User sanity checking
* safety_checklist

Entropy
* unchunk
* chunk
* entropy

Subprocess helper functions
* _verbose -> verbose
* _run_subprocess -> run_subprocess
* call -> bitcoin_cli_call
* checkoutput -> bitcoin_cli_checkoutput
* json -> bitcoin_cli_json
* bitcoind_call -> bitcoind_call

Base58
* b58encode_int
* b58encode
* b58encode_check

I'm a tentative ACK on your libglacier submodule suggestion. In an ideal world, anyone interested in using something like Glacier would just work on a single repo (especially given how few of us there seem to be...), but at least this way we preserve some amount of collaboration. @bitcoinhodler, would like to get your thoughts on the matter.

Regarding how to split the files, creating one file per section in the comparison list above seems reasonable to me. We could probably put Bitcoin utils + Subprocess helper functions in the same file and RNG + Private key generation + Entropy as well. So that would result in the following files...

• hashes.py
• rng.py
• bitcoin_cli.py (per the @bitcoinhodler naming convention)
• qr.py
• checklist.py (can this one function go somewhere else)
• base58.py

[secinthenet]

Thanks for running that comparison. Your file splitting suggestion seems reasonable to me. I agree it would be simpler and more efficient to avoid libglacier and have all of us work on a single repo. But from my understanding, there are two main differences between the forks that would prevent this:

• Maintaining backward compatibility with the original Glacier (AFAIK @bitcoinhodler wanted to preserve this)
• Adding BIP32/BIP39 support (AFAIK @bitcoinhodler avoided it due to extra complexity)

@bitcoinhodler when you get a chance, please let us know what you think about all of this.

[bitcoinhodler]

I'm not keen on spending any time on this myself. I developed my fork not as a fork but as improvements to be submitted upstream to the official Glacier Protocol. Since that's now abandoned, I maintain it as a fork only for my own use.

Glacier is obsolete as a wallet system due to the lack of HDM. I would like to switch to HDM myself eventually, at which point my Glacier fork will be abandoned too. But I don't think any of the current HDM systems match the security of Glacier (yet).

[secinthenet]

@bitcoinhodler by not spending time, do you also mean you don't want to accept PRs?

Re the (in)security of HDM systems, did you already document your concerns? I'd like to understand them

[bitcoinhodler]

I would consider PRs.

My concerns about the HDM systems are mostly around the fast pace of ongoing development, which is great to see, but I don't want to spend the time/money/effort to set up a new wallet system and then have it become obsolete in a year. Once there are solid standards and an understanding in the community that coins stored using this standard will remain accessible for the foreseeable future, I will consider it.

I'm also skeptical of using hardware wallets, for the reasons explained in the Glacier Design doc. I like the idea of Proof Wallet and Yeti. But I would like those to be interoperable so that I don't have to trust either one of them. They just become two different signatories in my one wallet.

Or maybe I should just buy three ColdCards and stop being so pedantic.

[secinthenet]

Would you consider PRs with the changes mentioned above to make the forks more similar? What about the libglacier suggestion?

As for the lack of solid standards in HDM, the two issues I'm aware of are:

• BIP32 paths for multisig
• QR codes for large transactions

Am I missing something?

For the BIP32 paths, I think there won't be a widely adopted standard anytime soon, since wallets will be concerned about compatibility for their users. QR codes standards may arrive faster (there's Blockchain Commons and Cobo doing some work).

I didn't look much into Yeti (mostly because it wasn't easy to test it without actually following the steps). If you're looking for interop (which @hodlwave and I are also interested in), HDM seems like the way to go. Regarding the two concerns about hardware wallets mentioned in Glacier, let me try to address them:

• USB connections (primary concern): this is no longer true, there are hardware wallets like Cobo that have a full airgap via QR codes, and ones with partial airgaps via SD cards (but stills more secure than USB). Also, it's possible to use the USB ones in an air-gapped computer (and while that requires an airgapped general general purpose computer like in Glacier, you don't need to secure it as strongly to achieve the same level of risk).
• Verification: all sensible hardware wallets have integrity verification mechanisms, general purpose computers are actually more lacking in that regard (though they are a less profitable target). It's possible to make supply chain attacks extremely difficult with secure chips, but I'm not sure whether most hardware wallets actually do this.

As mentioned by Flaxman in btcguide, when you use a diverse set of hardware wallets, you also significantly reduce your exposure to such attacks.

[bitcoinhodler]

I'm thinking more of things like account maps, privacy of keys/backups, and software like Specter and Gordian. All of these look very promising but are still in heavy development and (IMO) not stable enough for production use. And the hardware wallets are also making frequent changes for better multisig. I don't want to be a pioneer when it comes to storing my life savings.

I will reluctantly support libglacier but I'm skeptical because I don't think anyone should care about Glacier anymore, at least not for much longer. I'm maintaining it only for my personal use. Our development efforts should be focused on HDM, but introducing HDM into my Glacier fork means introducing lots of additional dependencies, which I would like to avoid. Let Glacier be its old, boring, safe self, and do the pioneering work in some other repo.

I understand you want to review my Glacier code, and separating out a common library would ease that. But I think the common stuff is all pretty simple code. The bulk of the review will be elsewhere.

In the long term, I'm a little conflicted about the future of cold storage. Glacier has very high security but low privacy. (And its address reuse indirectly hurts security.) I would love to help develop an HDM system that is comparable, but it seems inevitable that will introduce new security risks that Glacier today does not have. Today's Glacier has very few dependencies; there will necessarily be many more to fully implement HDM. Also the necessity to run software on each end of the air gap introduces a risk that Glacier never had (see my PSBT security analysis for more). Though that can be mitigated by using software from different vendors on each end of the airgap.

[secinthenet]

I'm thinking more of things like account maps, privacy of keys/backups, and software like Specter and Gordian. All of these look very promising but are still in heavy development and (IMO) not stable enough for production use. And the hardware wallets are also making frequent changes for better multisig. I don't want to be a pioneer when it comes to storing my life savings. I also think these projects are promising, but I'm not sure they will be a viable replacement for Glacier anytime soon. For example, Specter looks like it's focused on being a multisig coordinator, but it doesn't implement offline signing for general purpose PCs. Gordian is focused on MacOS/iOS and most certainly won't have an offline signer that's as easy to audit as Glacier.

Out of curiosity, why do you think Specter is not stable enough? Did you run into issues testing it?

I will reluctantly support libglacier but I'm skeptical because I don't think anyone should care about Glacier anymore, at least not for much longer. I'm maintaining it only for my personal use. Our development efforts should be focused on HDM, but introducing HDM into my Glacier fork means introducing lots of additional dependencies, which I would like to avoid. Let Glacier be its old, boring, safe self, and do the pioneering work in some other repo.

If you're unmotivated by the libglacier refactoring, I'm not sure it's a good idea. Anyway, if you want Glacier+HDM in a separate repo, why not join forces with Proof Wallet? Proof Wallet can be a Linux offline co-signer based on Galcier that is interoperable with Specter, Gordian Wallet, etc. (though we may need to send PRs to these other projects to make sure the interop is smooth).

I understand you want to review my Glacier code, and separating out a common library would ease that. But I think the common stuff is all pretty simple code. The bulk of the review will be elsewhere.

All the Glacier code is simple, the heavy lifting is done by Bitcoin Core or in the case of Proof Wallet the HDM libs (by design), but it's still 1000+ lines including comments.

In the long term, I'm a little conflicted about the future of cold storage. Glacier has very high security but low privacy. (And its address reuse indirectly hurts security.) I would love to help develop an HDM system that is comparable, but it seems inevitable that will introduce new security risks that Glacier today does not have. Today's Glacier has very few dependencies; there will necessarily be many more to fully implement HDM. Also the necessity to run software on each end of the air gap introduces a risk that Glacier never had (see my PSBT security analysis for more). Though that can be mitigated by using software from different vendors on each end of the airgap.

I'm not worried about the risk you mention in the PSBT security analysis. Like you say, that can easily be eliminated (compared to today's Glacier) by running independently maintained software on the online side. The online side has a very simple task: decode the QR code, verify the details with the user, and broadcast it. Since you're dealing with a standard format (PSBT), it shouldn't be hard to find such software.

[bitcoinhodler]

To support all the features I would like to see, the online side will need to be more complicated. The current coordinators (from what I recall) are designed for use with hardware wallets as the signing devices. Using commodity laptops Glacier-style with seed phrases stored on paper has some unique needs.

• Privacy from nosy signatories
• Honeypot/canary wallets watching each seed phrase

Many months ago I wrote about the future of Glacier (skip over the Shamir section) and tried to document there all the different workflows that we'd need to support. The online side has quite a bit of work to do.

[secinthenet]

Both of the features (privacy and honeypot) seem somewhat orthogonal to HDM, since you can implement them in old style glacier:

• Privacy: encrypt each private key with password, shard public keys and passwords using Shamir, and store each shard in a packet as well
• Honeypot: just deposit to the multisig key as if it's a single sig key

Why are both of them unique to commodity laptops? What issues are you thinking about with integrating current coordinators with a Glacier style signer?

BTW, in the "Options" section, you consider either HDM or non-sequential Glacier, by why not sequential Glacier?

[bitcoinhodler]

Yes they are orthogonal to HDM, but we're talking about what is needed from the coordinator.

I say they are unique to commodity laptops because hardware wallets do not make the wallet information so readily accessible to the keyholder. It is reasonable in many use cases to assume that the keyholder is not going to be doing any hacking on the hardware wallet to extract key information. It's possible that some of these features could still have some benefits even to hardware wallet users, but I haven't really thought about it. If there's paper backups, then obviously these are applicable there.

If you don't care about the privacy and honeypot features then the only issues with integrating will be following the standards for things like the account map (descriptor) and PSBT fields. Maybe those are already standardized enough? It doesn't seem like it.

When I wrote that future.md doc I was comparing Glacier as it currently was: there was no sequential signing capability, though I later added that in my fork.

[secinthenet]

I'm not following you, if we're talking about the requirements from the coordinator, how are these two features relevant? Why does the coordinator need to support them? They seem like optional features you could use, regardless of whether you use commodity laptops or hardware wallets, and without involving the coordinator at all.

Yes, I'm assuming that you want paper backups for hardware wallets as well, so that aspect is the same. This seems like the assumption for almost any multisig hardware wallets system (for example https://btcguide.github.io/backup-wallet/seeds).

[bitcoinhodler]

Perhaps I'm considering a broader definition of "coordinator". I'm referring to everything on the online device except for Bitcoin Core. There is a lot of work for that coordinator to support those two features.

Today a coordinator takes as input an xpub from each signer. Under my proposal they would also need to accept a BIP39 password and a canary xprv from each signer. They would need to set up the canary wallets and alert system. They would need to include all BIP39 passwords in the account map. They would need to shard the account map using SSS. They would need to provide a process for recovering the account map from M-of-N shards.

If hardware wallets wanted to fully support these features, we'd need the hardware wallets to understand the account map, including the BIP39 passwords. We'd also need them to generate a BIP39 password and canary xprv when creating a new key, and export those two along with the xpub.

All of this is to say that I think there's still a lot more development work on HDM systems before I'd consider them complete.

Anyway I think this discussion has gone way off the reservation.

[fresheneesz]

Sorry to barge in here but...

I wanted Proof Wallet to break out of the monolithic nature of Glacier Protocol, and instead have it be interoperable with other offline signers in a heterogeneous quorum

I like this idea a lot. I think there are plenty enough pieces that need to be put together in a wallet setup that wallet storage protocols could strongly benefit from modularity. I wrote The Tordl Wallet Protocols with the purpose of providing modular instructions that others could use in their guides, to break the monolithic nature of these protocols in general.

I have been planning on writing the glacier protocol in Tordl style using some of the pages in there that I've already written, and adding new pages to support Glacer (eg instructions on creating air gapped machines).

I'm looking for collaborators and reviewers. I'd love to collaborate with you guys if we can find some common ground. I'm also pretty wary of Glacier's lack of HDM, that's pretty critical for a modern wallet. As far as hardware wallets, I understand there's a lot of differing opinions there, I would err on the side of giving people a choice for controversial things like that. Glacier and Yeti are both anti-hardware wallet, and they have their reasons. I'm pro-hardware wallet, but I don't think protocols I write should assume hardware wallets will be used.

Glacier has very high security but low privacy

I'm curious about this. What other than the single-address reuse makes it have low privacy.

[bitcoinhodler]

Glacier doesn't use a full node (or any other online software), instead relying on services like blockchain.info to find UTXOs, goqr.me for printing QR codes, and coinb.in for broadcasting transactions, any one of which could compromise privacy.

Another privacy concern is that anybody who finds one of your Glacier packets now knows your Glacier address and can see all of your transactions, even if they don't have enough keys to spend the coins.

[fresheneesz]

Ah I see.

anybody who finds one of your Glacier packets now knows your Glacier address and can see all of your transactions, even if they don't have enough keys to spend the coins.

How do you prevent this? Since you need all the public keys to create your wallet, the only thing I would think is possible is to store all the public keys with each seed backup - which means any one seed backup being compromised means your privacy is compromised. Is there another way? Perhaps some cleverly arranged lists of public keys such that any M locations contains all the public keys, but no single location contains all?

[hodlwave]

I like this idea a lot. I think there are plenty enough pieces that need to be put together in a wallet setup that wallet storage protocols could strongly benefit from modularity. I wrote The Tordl Wallet Protocols with the purpose of providing modular instructions that others could use in their guides, to break the monolithic nature of these protocols in general.

Thanks, @fresheneesz. I'll take a look at Tordl when I get some time. I think some information / instructions on creating an airgapped machine would be cool. I'm planning to add more detailed proof-wallet docs about doing this as well as performing wallet operations on the airgapped laptop.

How do you prevent this?

See Privacy from nosy signatories, linked above.

[fresheneesz]

Ah, Shamir, of course. That's a great idea!

[secinthenet]

Perhaps I'm considering a broader definition of "coordinator". I'm referring to everything on the online device except for Bitcoin Core. There is a lot of work for that coordinator to support those two features.

Today a coordinator takes as input an xpub from each signer. Under my proposal they would also need to accept a BIP39 password and a canary xprv from each signer. They would need to set up the canary wallets and alert system. They would need to include all BIP39 passwords in the account map. They would need to shard the account map using SSS. They would need to provide a process for recovering the account map from M-of-N shards.

I don't understand why you need the coordinator to do all of this. You can use an existing coordinator (e.g. Specter) and use additional software to get what you want, the experience will just not be fully integrated. That seems like a very minor issue, since you import the xpubs only once (per online device), and only need to set up the alert service once.

If you follow security best practices, it doesn't make sense to introduce this functionality into a general coordinator, since not everyone will need it, and you want to minimize complexity for the common case. In particular, I highly doubt the canary feature will be implemented as a core feature in any popular coordinator. To make it robust, you will also want to run the alert service in an always-on computer, which essentially means running it in the cloud.

If hardware wallets wanted to fully support these features, we'd need the hardware wallets to understand the account map, including the BIP39 passwords. We'd also need them to generate a BIP39 password and canary xprv when creating a new key, and export those two along with the xpub.

All of this is to say that I think there's still a lot more development work on HDM systems before I'd consider them complete.

How is this worse than non-HDM Glacier?

Anyway I think this discussion has gone way off the reservation.

[bitcoinhodler]

I can see the canary alert service being provided as a one-click app for a Raspberry Pi-based full node like Start9's Embassy or MyNode. It will take minimal system resources, just sitting there waiting for ZeroMQ notifications from Bitcoin Core.

I'm not sure what you mean by "how is this worse than non-HDM Glacier?" My point in all this discussion is that these HDM systems are still evolving rapidly, which is good, but that makes it premature for me to store my life savings using such a system. I'm maintaining Glacier for my own use until things stabilize and coalesce around common standards.

[secinthenet]

Using a RPI is OK if you can live with a non-robust system (electricity, hardware failures).

What I mean is that these don't seem like sensible reasons to choose non-HDM Glacier. The only good reason I see is to avoid HDM is the extra complexity from the HDM libs.

[bitcoinhodler]

I think we agree: there is no reason for anyone to choose non-HDM Glacier. And that's why I don't think there's any benefit in modifying my Glacier fork any further. It's reached a dead end. Like this discussion.

[fresheneesz]

Is there any interest in attempting to deconstruct Glacier (via this repository) into modular pieces in a way that's compatible with Tordl? I would very much like to figure out how we can all collaborate on different pieces of these protocols, potentially in separate repositories, while still sharing "code" (or instructions in general). For example, I would really like to modularize the instructions for creating an airgapped/quarantined machine.

However, I am noticing that the original Glacier protocol repo only really contains the instructions part (what I consider the main protocol) in pdf form, and doesn't contain the web version. And this repo doesn't even contain the pdf. So maybe I should ask: what's the plan for this repo? Will this eventually contain all the instructions on setup, deposit, withdrawal, etc? The helper command line program is only one part of it.

[secinthenet]

I think we agree: there is no reason for anyone to choose non-HDM Glacier. And that's why I don't think there's any benefit in modifying my Glacier fork any further. It's reached a dead end. Like this discussion.

I'm afraid I don't follow again. If non-HDM Glacier is not a sensible choice, it doesn't mean that modifying non-HDM Glacier to be HDM (either via your fork or Proof Wallet) is not a sensible path.

[secinthenet]

Is there any interest in attempting to deconstruct Glacier (via this repository) into modular pieces in a way that's compatible with Tordl? I would very much like to figure out how we can all collaborate on different pieces of these protocols, potentially in separate repositories, while still sharing "code" (or instructions in general). For example, I would really like to modularize the instructions for creating an airgapped/quarantined machine.

After I will review Tordl and do a deeper review of Glacier, I may be able to try that (no promises). It seems that @bitcoinhodler is not interested any development in their fork, which means I'll probably only review and test Proof Wallet. Afterwards, I may propose changes via PRs, but as for modularization Tordl-style, it depends on whether @hodlwave think it makes sense, since I probably won't do any changes that diverges too much from their work.

However, I am noticing that the original Glacier protocol repo only really contains the instructions part (what I consider the main protocol) in pdf form, and doesn't contain the web version. And this repo doesn't even contain the pdf. So maybe I should ask: what's the plan for this repo? Will this eventually contain all the instructions on setup, deposit, withdrawal, etc? The helper command line program is only one part of it.

Maybe it's in https://github.com/GlacierProtocol/glacierprotocol.github.io

[fresheneesz]

If non-HDM Glacier is not a sensible choice, it doesn't mean that modifying non-HDM Glacier to be HDM

I was hoping he meant that he wanted to abandon his repo in favor of working together on yours?

as for modularization Tordl-style, it depends on whether @hodlwave think it makes sense

That's definitely fair. I'm curious on your thoughts @hodlwave.

Maybe it's in...

It certainly is. I'm wondering if holdwave is planning on branching and updating that as well? Or are you just planning on updating the tool, hodlwave?

[secinthenet]

If non-HDM Glacier is not a sensible choice, it doesn't mean that modifying non-HDM Glacier to be HDM

I was hoping he meant that he wanted to abandon his repo in favor of working together on yours?

Only @bitcoinhodler can answer, but my understanding is that they stopped developing their repo, and aren't interested in doing development before the HDM ecosystem stabilizes.

[hodlwave]

And this repo doesn't even contain the pdf. So maybe I should ask: what's the plan for this repo? Will this eventually contain all the instructions on setup, deposit, withdrawal, etc? The helper command line program is only one part of it.

I haven't prioritized documentation yet largely because there hasn't been that much interest in PW, and also because mirroring the Glacier Protocol's level of detail is a daunting task both in terms of writing and testing (potentially multiple operating systems). Realistically the existing Glacier Protocol doc can be reused by those with enough capacity for basic inference.

I would like the repo to have more documentation, ideally both legible on GitHub and able to be used as a source to generate a pdf.

I think more code review would be a higher leverage activity at the moment; if the code is more well-reviewed, at least more technical people could start using the wallet while less technical users would be able to once more docs are added.

as for modularization Tordl-style, it depends on whether @hodlwave think it makes sense

I browsed the TordlWalletProtocols repo and I'm not quite sure what you mean by this. I am strongly against expanding Proof Wallet's scope to single signature wallets (hopefully that's not too controversial); I would be open to adding an option for users to specify a BIP39 passphrase when constructing the wallet since it enables the kinds of bespoke Shamir schemes like @bitcoinhodler envisioned at little to no cost.

Overall, I want Proof Wallet to stand on its own as an option users can incorporate into their multisig quorums. Personally, I think the space is standardized enough with BIP174, output descriptors, and HWI that HDM is now doable even if there is some awkwardness (no standard for describing the internal and external chains of a wallet).

[fresheneesz]

I think more code review would be a higher leverage activity at the moment

Gotcha.

I am strongly against expanding Proof Wallet's scope to single signature wallets (hopefully that's not too controversial)

I don't have a problem with that. What I was suggesting was that we could collaborate on the docs in a way where specific pieces of Tordl could be linked to (or pulled in, or otherwise depended on) from this repo. The example I gave was a method of creating airgapped machines. So for example, we could extract the procedure for creating the airgapped machines Glacier requires into a standalone guide, and then in the specific docs for this simply link to it from the appropriate part of the instructions here (or pull in the text as part of the release process for this) and also link to those instructions in the Tordl repo as an option for host device (and potentially other protocols that specifically require an airgapped machine). I think there are probably a number of useful procedures that could be extracted and reused by multiple protocols/projects.

[hodlwave]

Hi @fresheneesz

I would prefer to keep all the documentation in Proof Wallet self-contained, as opposed to linking out to Tordl or any other repository; however, if you wanted to write such a guide on e.g. airgapping a computer, I would be happy to review a PR adding it directly to the Proof Wallet docs directory.

[fresheneesz]

I absolutely agree that any critical documentation included in guides like this should be validated and made part of the repository directly in some way, for security reasons. You wouldn't want to link out to another website that becomes hijacked and then provides malicious instructions that compromise the security of your instructions.

What I would like to see ideally is a modular approach where a version of one repository (or part of the repository) is pulled into another, either via a package manager or manually. An example of how this would work manually:

1. Repository A writes a modular guide with some standardized requirements (ie a standard format).
2. Repository B copies that modular guide into a directory called repository-A-versionX.X
3. Reviewers of Repo B validate the addition (that its what they expect and want, and perhaps reviewing changes from the last version of the same guide-module).
4. Repository B internally links from its guide to the guide file pulled in from Repo A or has some process to generate the neccessary artifacts from that pulled-in file to create what is needed in Repo B.

Since Glacier's docs are basically a single page, item 4 could be taking the imported guide, generating html from its content, and inserting that content into the release version of the docs page.

Curious to know your thoughts on that.