Author

Topic: BIP Draft - Standardized/Protected/Multi Private Keys (Read 996 times)

vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
who not use standard BIP11 addresses?

These are a different transaction type altogether.  Not much supports these transactions yet.

I propose different ways to encode a normal private key. They can all be turned back in to a normal private key for a normal address with a utility and imported anywhere.
hero member
Activity: 668
Merit: 501
who not use standard BIP11 addresses?
full member
Activity: 140
Merit: 100
should use erasure coding or ssss (Shamir's Secret Sharing Scheme, http://point-at-infinity.org/ssss/), not home-made recovery records Smiley

Edited: erasure coding reduces the security expectations, so only ssss is usable.
legendary
Activity: 1358
Merit: 1003
Ron Gross
Watching
vip
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
I am drafting another potential BIP and wanted to solicit comments.

https://en.bitcoin.it/wiki/User:Casascius/Base58Check-encoded_objects_proposal

With the increasing popularity of the use of paper wallets as offline Bitcoin storage, there is a growing demand for ways to make that offline storage more secure, for various reasons of the user's choice.  Currently, there exists no straightforward way to encrypt a paper Bitcoin wallet.

There is also growing demand for paper wallets that can be split and saved in redundant geographical locations or with different trusted parties, or which are generated in individual parts by multiple machines so that no single machine ever has access to the entire private key prior to redemption.  This proposal introduces a standard based on elliptic curve multiplication where Base58Check-encoded strings and/or QR codes can be used to represent parts of a multi-part key.  This proposal also introduces a simple standard format for denoting a RAID-like recovery record, so that a multi-part key can be distributed and redeemed in a fashion that tolerates the loss of any one part of the key.

This proposal also seeks to define unique prefixes on Base58Check-encoded strings so that they convey useful visual information to a user, and requests that other developers maintain awareness of the string prefixes and maximize their usefulness to the user.
Jump to: