On the "Prepare non-quarantined hardware" page, step 4 is to run virus scans. However, it says that doing this on linux is unnecessary. Linux isn't immune to viruses tho, and I think if this step is indeed unnecessary on linux, some convincing reasoning should be given on that page.

More info about virues on linux: https://www.linux.com/tutorials/myth-busting-linux-immune-viruses/

When creating entropy for private keys the protocol now generates dice entropy first and then computer entropy.

I think it would be better to switch the order - generate computer entropy first and then generate dice entropy. That way you can be more sure that dice entropy you type to scratchpad does not affect computer entropy later.

The protocol currently states:

If privacy is very important to you, you might consider using a service like Shapeshift to exchange your Bitcoins for an more anonymous cryptocurrency, such as Monero, and then exchange them back to Bitcoins. However, this will cost you fees, and importantly, it requires you trust the operator of the exchange service not to steal or lose your funds.

Comments:

1. Shapeshift's privacy has recently been reduced (eliminated?) with KYC/AML requirements and similar services are likely to follow
2. Shapeshift has exchange limits far below the levels Glacier is aimed at

Also, just below that:

This guide gives additional detail about how to increase Bitcoin anonymity using Monero & Tor.

Link is dead.

With the design document clearly stating that privacy is not a primary design goal of Glacier, are both suggestions better removed? Passing on the community's trust in Glacier to a third party like Shapeshift, or what will inevitably become an out-dated bitcoinnewsmagazine.com article, may not be wise.

I suggest we mention that bitcoin>monero>bitcoin is an option for privacy without giving any more detail, and that anything as specific as the link to the bitcoinnewsmagazine.com article is removed completely.

I tried to run the setup process using an old laptop with only 2GB RAM. The requirements for the setup PCs are stated in the doc:

Two computers with Internet connectivity, administrator access, and about 2GB of free disk space. Each computer must be running Windows 10, macOS, or Linux.

The setup PC is used to boot into Ubuntu Live, download the Ubuntu ISO, and write it to the Q1 BOOT USB. In a Live system, the only writable filesystem is a RAM disk. The Ubuntu ISO is about 1.4GB. On my 2GB laptop the download got to about 1.3GB before aborting with "No space left on device."

We should update the doc to require at least 4GB RAM on the setup PCs. (3GB might be enough, but who has a 3GB laptop to test it out? 4GB is certainly sufficient.)

Consider updating _docs/extend/security.md, because ...

The "hardware random number generator" link at bottom of "Digital software security" section doesn't land on a helpful Wikipedia page. Maybe it should point to:

https://en.wikipedia.org/wiki/Hardware_random_number_generator

?

Consider updating _docs/overview.md, because

Glacier is a step-by-step protocol for storing bitcoins in a highly secure manner.

"step-by-step protocol" is not defined nor explained. And the introduction does not clarify what glacier is.

This protocol generates raw private keys, which make using the funds unnecessarily difficult. If HD wallets are created, you don't have to reuse the same address, which increases privacy.

Consider updating _docs/extend/improvements.md, because ... We should use Electrum instead of Bitcoin core because it has multisig, qr codes, and can be backed up with a seed phrase which can be written on paper. Also you can have an xpub which will generate an unlimited number of addresses. Electrum also comes preinstalled on tails, so only two usbs and two computers are needed.

Consider updating _docs/setup/verify.md, because ...

Raised for discussion after @bitcoinhodler's pull request comment:

A protocol should be very strict in its implementation. A Glacier user should be able to declare that his/her funds are stored according to The Glacier Protocol without any ambiguity over how that's been done or the standard that's been achieved.

I propose that the "Lower-security Protocol Variants" section is either removed entirely, or is at least moved to an appendix appropriately marked as being outside the Glacier standard, similar to the "Extend Glacier security" section with the "We do not recommend considering these measures..." statement.

GlacierProtocol/GlacierProtocol#49 (comment)

Consider updating _docs/check-balance/overview.md.

Should the guidance encourage running your own node to check balances rather than using a public block explorer that can leak information such as IP address. Or at least discuss the downsides of using a public block explorer?

Consider updating _docs/deposit/transfer-to-paper.md, because many people are interested in using (possibly memorizing) 12/24 seed words, could you please cover this option in your protocol?

It's in the paragraph above this.

https://github.com/GlacierProtocol/glacierprotocol.github.io/blob/master/_docs/before-you-start/overview.md#lower-security-protocol-variants

The relation between glacierprotocol.github.io repository and GlacierProtocol repository is not clear. It would be great to document what is the purpose and relation of these 2 repositories.

It seems to me that there is ongoing effort to move Glacier.pdf (which is Google Document originally - see GlacierProtocol/GlacierProtocol#3 (comment)) to HTML format at https://github.com/GlacierProtocol/glacierprotocol.github.io. But I didn't find this stated anywhere and therefore I am a bit confused when trying to contribute to the project:

• should I focus on glacierprotocol.github.io primarily as it will be single point of truth in the future and the protocol documents will be generated from it or
• do you plan to maintain glacierprotocol.org site in glacierprotocol.github.io repo and related documents in GlacierProtocol repo (and therefore not easy to contribute as there are no PR available for the Google doc)

Also there are many open issues in GlacierProtocol some of them old and easy to fix (GlacierProtocol/GlacierProtocol#2) which makes me wondering if current maintainers do have time to address them or whether they need community help. @diogomonica, @NathanMcCauley - can you please comment on this?

Thank you!

Hey everyone, I'm pretty sure this is a personal problem and not an issue with Glacier, but I can't find any solutions online. I get this error whenever I try to run create-deposit-data or create-withdrawal data. Any suggestions?

Traceback (most recent call last):
File "./glacierscript.py", line 871, in
deposit_interactive(args.m, args.n, args.dice, args.rng)
File "./glacierscript.py", line 635, in deposit_interactive
ensure_bitcoind_running()
File "./glacierscript.py", line 311, in ensure_bitcoind_running
bitcoind_call("-daemon", "-connect=0.0.0.0")
File "./glacierscript.py", line 143, in bitcoind_call
_, retcode, _ = run_subprocess("bitcoind", *args)
File "./glacierscript.py", line 108, in run_subprocess
pipe = subprocess.Popen(cmd_list, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, bufsize=1)
File "C:\Python27\lib\subprocess.py", line 394, in init
errread, errwrite)
File "C:\Python27\lib\subprocess.py", line 644, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

The protocol currently states:

"For distributed custody, we recommend a 2-of-5 withdrawal policy. The extra key (5 keys, rather than the recommended 4 keys in Option 1) is recommended since you have less control over whether a signatory effectively protects their key against theft or loss"

I agree that an extra key protects against loss, but I would suggest that it increases the opportunity for theft:

In a m-of-n system, a thief's intention is to procure m of the n keys. As n increases, without a corresponding increase in m, the opportunities the thief has to acquire m keys increases.

As an extreme example:

A 2-of-3 system has a much smaller attack surface than a 2-of-100. 2-of-100 provides excellent contingency for a lost key, but the opportunity for a thief to select the two easiest targets out of 100 is far greater than 2-of-3.

Is my thinking correct?

Consider updating _docs/deposit/deposit-execution.md, because insure and ensure mean different things.

"This is to insure" should read "This is to ensure"

Citation: https://www.grammarly.com/blog/assure-ensure-insure/

Blockr is mentioned throughout the protocol (page 18, 52, 62, 65, 69) as the goto explorer, but the service has been shut down for a while now. It should be replaced with a new blockchain explorer such as:

• https://oxt.me/
• https://blockstream.info/
• https://live.blockcypher.com/btc/

The following issues are still unresolved from the test site. Filing here so they are not forgotten:

joaofnfernandes#8 (despite being marked as closed)
joaofnfernandes#11 (despite being marked as closed)
joaofnfernandes#12
joaofnfernandes#14

As mentioned in #11 I would like to start discussion whether Markdown should be replaced by AsciiDoc. AsciiDoc has following advantages over Markdown:

1. It supports conversion to HTML and PDF out of the box. Current solution with weasyprint can be avoided.
2. It supports includes. Current catmd solution can be avoided.
3. Rich editor AsciidocFX is available.

I played with it for a while and I liked PDF export quite a lot. There is a difference between native and AsciidocFX PDF export though. Native is more like from web, AsciidocFX uses DocBook in between so result looks more like a book - footnotes are back! :-) Please see example below.

Example:

• source for verify.adoc - https://gist.github.com/another-hodler/717a3bb71c0a5c52d9b42833f93b23d8
• exported PDF from AsciidocFX - http://ge.tt/6g4Sumr2

If we decide AsciiDoc is a way to go I can start working on the conversion. What needs to be investigated is:

• Highlighting as used for critically- and moderately-sensitive data.
• Full site HTML export as required for https://glacierprotocol.org/

Consider updating _docs/setup/verify.md, because the instructions are out of date and the link to keybase.io does not contain public key.

Consider updating _docs/overview/key-concepts.md, because ...

"see below" should reference next section , as on website , it is not "below"
In Paper Key Storage section

Consider updating _docs/extend/improvements.md, because ...

Consider leaving a relatively easy accessible loaded honeypot-wallet on each supposedly secure location (e.g. a paper printed with the seed and QR-Code of the xpriv/xpub for quick sweep-access).
When using a m-of-n multisig constallation with passphrase for the real funds, load up each single wallet originating from each cosigner's seeds (w/o passphrase) with "f*ck-up-money" and set up a notification process when the honeypot is emptied (e.g. IFTTT).
Do the same with the multisig-wallet w/o the passphrase and the trap is set.

Drawbacks:

• a honeypot could trigger an attacker to "go for more"
• a honeypot could be identified as such from the attacker and not be emptied, leaving the originator in a false sense of security

After written, the disk will be read-only, which means you can use it for any computer you need to boot. This means you only need 1 disk rather than 4 USB drives (leaving only 1 USB required for each quarantined computer. There's also much less opportunity for malware to infect things. There's no possibility for malware to bring data back over from an airgapped machine if the user accidentally re-uses the USB drive or gets them mixed up.

In the "Hardware required" section, the protocol states that one of the two unquarantined computers should be

a computer that you do not own (unless purchased brand new), or that has not spent much time on your home or office network

How much is "much"? Can we come up with a more definite statement? I imagine a user scratching their head while looking at a laptop, thinking "well, it hasn't spent much time on the network... Has it?"

The protocol later states

It’s not technically ownership that’s important. But computers you own are more likely to
run the same software, have visited the same websites, or have been exposed to the same
USB drives or networks – and therefore to have the same malware.

So is the requirement:

The computer is not to be one used by the person implementing the protocol

or

The computer is not one that has been connected to the person's home/office network

or both?

For example, A user's son's laptop could spend all day on the user's network (different user, same network), or the user's laptop could spend all day on a workplace network (same user, different network). Both could satisfy protocol requirements as it stands.

With 3rd party javascript blocked the site fails to function.

It should gracefully degrade or host these assets locally to avoid 3rd party trust issues on this type of site.