Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does an extra key protect against theft? #18

Open
GraniteKeep opened this issue Nov 20, 2018 · 2 comments
Open

Does an extra key protect against theft? #18

GraniteKeep opened this issue Nov 20, 2018 · 2 comments

Comments

@GraniteKeep
Copy link
Contributor

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?

@bitcoinhodler
Copy link
Collaborator

Your thinking sounds correct to me, but I suspect the text was referring not to a thief targeting your keys specifically, but (for example) a residential burglary where a thief steals the contents of a home safe that includes one of your keys. The thief won't have a clue what to do with it, or to whom it belongs, so it's effectively the same as a lost key.

@GraniteKeep
Copy link
Contributor Author

GraniteKeep commented Nov 20, 2018

Got it. It's a defence against an opportunistic theft rather than a pre-meditated one.

I'll close this in a couple of days if there's no more input.

Thanks.

GraniteKeep added a commit to GraniteKeep/glacierprotocol.github.io that referenced this issue Nov 21, 2018
See Github issue GlacierProtocol#18 for justification of removal of "loss"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants