Goals and style of this project

[fresheneesz]

Responding to https://github.com/GlacierProtocol/glacierprotocol.github.io/issues/42#issuecomment-558951127 to move the conversation here, since its about this repository.

The official maintainer Diogo shows up every 6-8 months for a day and then disappears again.

Ah I see. Yeah I did notice the backup of pull requests.

That's fair. I'm also interested in making something for my own use. What I'm envisioning when I say "user friendly" are actually some protocols that aren't quite as paranoid and so don't have nearly as many steps as Glacier does. In particular, a large portion of Glacier's steps involve setup and management of airgapped computers. By allowing the user to choose less complex wallet storage devices (like hardware wallets), the protocol could be vastly simplified. And manually created airgapped machines have dubious benefits over a hardware wallet that supports PSBTs, the main one I can think of being that since the hardware is more general, it might be less likely to be compromised in a way that would affect usage of your wallet. As bitcoin becomes more common tho, even that seems dubious.

In any case, the user friendliness I'm talking about comes not from meticulously detailing all the information in a big list, but from simplifying the protocol itself. In addition to that, there's a lot of 'teaching' going on in the Glacier Protocol that reminds the reader of important things that are just clutter for people who are already very aware of them. I think that teaching is important but should be separated from the protocol itself (other than short notes that link out to more info). Similarly, there's a lot of important rationale for why the protocol is the way it is, which I think should also be separated so as to not clutter up the actual instructions for what to do.

I'm also noticing a lot of superfluous steps that are ultra obvious even to people who aren't tech savvy (like how to extract stuff from a zip file). I would actually consider things like that anti-user-friendly, since it makes the protocol harder to read and almost nobody needs those steps.

I want to build a system based on the bigger principles, and not specify every little detail

I think that meshes very well with what I want to create. By creating modular methods, we can remove the details and create methods at a higher level, while still linking to the details for people who aren't familiar with how those higher level things work. If you worked on the Tordl Protocols, you certainly wouldn't have to specify every little detail. You could exclusively work on the higher level methods if you wanted to.

For example, Glacier's setup sections Prepare non-quarantined hardware, Prepare quarantined hardware, and Create boot USBs can all be summarized by a single line:

1. Create 2 airgapped machines, Q1 and Q2

That line would then link out to details on how that could be done. But for experts who already know how to do that, they can just do it how they're used to, or use airgapped machines they already have.

leaving that up to the user to figure out.

I would generally prefer to have things complete in some way, shape, or form. However, linking out to external websites is ok, when other resources sufficiently explain important concepts, steps, or details that some people might not know.

Also, there are benefits to having a repository with multiple different protocols - it means we can each work on the type of protocol(s) we're interested in, and simply not work on the others. I'm curious to know what you think of the modular approach.

[bitcoinhodler]

I'm skeptical of the modular approach. How do you guide the user towards choosing what's best for them? Inheritance also seems compromised: how does the user explain to his heirs what storage system his bitcoins use? Right now I can leave a message in my will saying "I used the Glacier Protocol."

What I saw last week in this repo felt more like general bitcoin storage education, which is valuable, but not the kind of thing I'm looking to build.

It seems like someone wishing to learn about all the options for bitcoin storage would find this useful, but they would want to read all of it to learn about all their options. I found it really cumbersome to click around all the different pieces versus having one linear document.

I hope this is useful feedback. Thank you for your efforts!

[fresheneesz]

How do you guide the user towards choosing what's best for them?

I'd imagine like anything else, provide some information and let people reason it out for themselves. Part of it is up to them. They can read through the summary info of each option, and can look at the details of everything if they want to. I would imagine most people would choose a level of difficulty they're willing to put up with, and do the most secure options that match that level.

Inheritance also seems compromised: how does the user explain to his heirs what storage system his bitcoins use?

Each method would simply have parameters that would need to be written down. Just like a function call - everything you need to know to execute a function is contained in the source code of the function (and its dependencies) and the passed parameters.

Right now I can leave a message in my will saying "I used the Glacier Protocol."

Even with the Glacier protocol, you still need to record where you stored your backups and prepare those locations so they can be legally obtained by your heirs. Since all you'll ever need to inherit bitcoin is to have a way to find the seed and know what format its in, inheritance shouldn't really be much different for any particular protocol.

this repo felt more like general bitcoin storage education

That's not my intention. My intention is to create modular components that are used in a few different combinations for a handful of holistic methods with different levels of difficulty and security.

I found it really cumbersome to click around all the different pieces versus having one linear document.

You're certainly right. It would be nice to put them into a form that's easier to peruse. Right now, since its just basic github markdown files, all you get are text and links. If this was made into a full fledged website, we could do something that assembled a much easier-to-use interface from the pieces. For example, a module entrypoint could be used to generate a page that allows a user to input arguments and view the protocol as a single page, perhaps with collapsible sections or other controls that make it easier to use. That's just an example, but my point is that its current form doesn't have to be its final form.

I hope this is useful feedback.

It was thanks!

In any case, it sounds like the Glacier Protocol isn't built in your favorite way either. I'm curious to know what you'd ideally like to work on?

[bitcoinhodler]

I like writing software much more than I like writing English, which is why I've mostly focused on improvements to GlacierScript.

[fresheneesz]

Gotcha. Well I have an idea that I think would make wallets far more secure and less error prone without much additional effort. I'm curious to know how you would go about creating supporting software for it.

The idea is to have a timelocked multisig wallet. Any signator could send, but they would have to send to an address that enforces a timelock on funds sent to it. The timeout for the timelock would be lesser for the more keys used to sign the (second) transaction. For example:

• 1 key - 4 months timelock
• 2 keys - 1 month timelock
• 3 keys - 1 week timelock

This way, even if you lost 2 out of 3 keys, you could still recover your funds, while at the same time, if 2 out of 3 keys were stolen (and you still had access to other copies of those keys) you could beat the thief to the punch by withdrawing the funds before they have access to them. Compared to your usual 2-of-3 multisig, it can withstand both more key loss and more key theft without losing funds. It helps in the inheritance scenario too, since you could have a passphrase protected seed that allows you to send the funds faster, but if you die, your heirs can still inherit your bitcoin - they just have to wait for it a bit.

What's needed for this are two things:

1. A way to create the multisig addresses and scripts to enforce this behavior,
2. A watchtower-like way to warn you if your funds have been sent to the timelocked address (and need to be saved).

Item 2 would be ideal as a mobile app. I'm curious what you think.

[bitcoinhodler]

I don't believe there's any way in Bitcoin's consensus rules to enforce any restriction on the destination of a transaction. If a signator/thief is able to move your coins at all, then they can move them anywhere they like.

It does make sense to use time locks for long-term storage, such as you describe. Require a typical 3-of-5 multisig, but after 1 year that relaxes to a 1-of-5. If the owner still has all keys, he would move them to a new address every year, with a new timelock. But in the event of loss of keys he could wait until the timelock expires and access them with only one.

I don't know of any system like this in production today but it's definitely been discussed before. The upcoming taproot/tapscript changes will make this far more powerful, since you won't need to reveal any of the spending conditions except the one you actually use.

Take a look at the miniscript project for a safe way to create complex scripts like this.

[fresheneesz]

I don't believe there's any way in Bitcoin's consensus rules to enforce any restriction on the destination of a transaction.

Ah, that's unfortunate. I asked around and found out that something called "convenants" would enable that. I also found out this idea is known as "bitcoin vaults". https://www.reddit.com/r/BitcoinDiscussion/comments/e740vm/idea_script_opcode_that_puts_constraints_on_the/f9wb79d

upcoming taproot/tapscript changes .. you won't need to reveal any of the spending conditions except the one you actually use

And complex scripts would also be cheaper to spend. Sounds good.

Take a look at the miniscript project for a safe way to create complex scripts like this.

I was planning on testing that out. I'll have to play around with it at some point.

[bitcoinhodler]

Ah, that's unfortunate. I asked around and found out that something called "convenants" would enable that.

I just read about a new proposal called OP_CHECKTEMPLATEVERIFY that sounds like it's making progress. I would assume it's still years away from availability, though.

[fresheneesz]

@bitcoinhodler I've completed a first full version of these protocols. This repo now contains relatively full guides on how to create a hot wallet and 3 kinds of multisig cold wallets. At some point, I'd like to flesh out the experimental protocols, some of which are not easy to do today, and some of which aren't possible without changes to bitcoin itself. I'd also like to translate the guidance in the Glacier Protocol into the form this repo is using.

I'd very much appreciate your thoughts on the current state of this repo. Also, do you know of anyone else that might be willing to review this?

[bitcoinhodler]

It looks much improved, but I find it pretty confusing. For the 3-of-5, you use two hardware wallets, with two keys each (one with password, one without)? That seems novel and therefore questionable. Is the rationale or justification documented anywhere?

It seems particularly dangerous since the password is supposed to be memorized and never written down.

I guess the idea is that one can do a withdrawal with only their mobile key and one hardware wallet. But a thief who gets two hardware wallets can't steal anything, so it's better than a 2-of-3 in that regard.

[fresheneesz]

That seems novel and therefore questionable. Is the rationale or justification documented anywhere?

I see what you mean. The 3-of-5 wallets don't simply use 5 independent seeds. Its interesting to realize the idea of using two wallets created from the same base-seed in a multisig wallet might be novel. I'm certainly not aware of anyone else proposing this set up. I haven't documented the rationale, but I should and I will.

The advantage of this is that you only have to go through the work of backing up 3 seeds. Since backing up seeds in different locations is important, and doing that is a huge pain in the ass (traveling around to different safety deposit boxes, not to mention the cost), limiting the storage locations is important. But also increasing the "n" in "m of n" is also important for security and/or redundancy.

So by using the passphrase to create 2 additional wallets, you can attain triple compromise resilience or double redundancy. Without using passphrases, 3 seeds would only give you double compromise resilience and single redundancy.

I guess the idea is that one can do a withdrawal with only their mobile key and one hardware wallet. But a thief who gets two hardware wallets can't steal anything, so it's better than a 2-of-3 in that regard.

Exactly. Without using the passphrases, the setup would be either substantially less secure, or substantially more difficult to use and maintain. Do you think the passphrase wallets are a bad addition?

[bitcoinhodler]

It seems very dangerous to rely on memory for infrequently accessed cold storage, especially considering inheritance planning. And doesn't each hardware wallet also have a PIN?

[fresheneesz]

It seems very dangerous to rely on memory for infrequently accessed cold storage

None of the multisig wallets rely on the passphrase. If the passphrase is forgotten, the raw seeds themselves can be used to recover funds - you just need more of the seeds (all 3 instead of just 2 of 3).

doesn't each hardware wallet also have a PIN?

Yes. But the PIN doesn't protect the seed.