Right now there are also people simply taking base58-encoded private keys and running them through ssss-split.
It has a lot going for it, since it can easily be reassembled on any Linux machine without special software (B Poettering's Linux command line SSSS implementation[1] seems to be included in most Linux distros). roy [1] http://point-at-infinity.org/ssss/ On Sat, Mar 29, 2014 at 12:59:19PM -0400, Alan Reiner wrote: > > Armory has had "Fragmented Backups" for over a year, now. Advanced > users love it. Though, I would say it's kind of difficult to > standardize the way I did it since I was able to implement all the > finite field math with recursion, list comprehensions and python > arbitrary-big-integers in about 100 lines. I'm not sure how "portable" > it is to other languages. There's obviously better ways to do it, but I > didn't need a better way, because I don't need to support fragmentation > above M=8 and this was 100% sufficient for it. And I was the only one > doing it, so there was no one to be compatible with. > > I won't lie, there's a lot of work that goes into making an interface > that makes this feature "usable." The user needs clear ways to identify > which fragments are associated with which wallet, and which fragments > are compatible with each other. They need a way to save some fragments > to file, print them, or simply write them down. They need a way to > re-enter fragment, reject duplicates, identify errors, etc. Without it, > the math fails silently, and you end up restoring a different wallet. > And they need a way to test that it all works. Armory did all this, > but it was no trivial task. Including an interface that will test up to > 50 subsets of make sure the math produces the same values every time > (which still is not sufficient for some users, who won't be satisified > til they see they're wallet actually restored from fragments. > > Also I put the secret in the highest-order coefficient of the > polynomial, and made sure that the other coefficients were > deterministic. This meant that if print out an M-of-N wallet, I can > later print out an M-of-(N+1) wallet and the first N fragments will be > the same. I'm not sure how many users would trust this, but we felt it > was important in case a user needs to export some fragments, even if > they don't increase N. > > You might consider loading Armory in offline mode, create a wallet, and > then do a fragmented backup to see how we did it. I am extremely > satisfied with the interface, but it's most definitely an "advanced" > tool. But so is Armory ... which made it a good fit. But it might not > be for everyone. > > -Alan > > > > On 03/29/2014 11:44 AM, Matt Whitlock wrote: > > On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote: > >> https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/ > > Thanks. This is great, although it makes some critical references to an ACM > > paper for which no URL is provided, and thus I cannot implement it. > > > > A distributed ECDSA notwithstanding, we still need a way to decompose a > > BIP32 master seed into shares. I am envisioning a scenario in which I might > > meet my sudden and untimely demise, and I wish to allow my beneficiaries to > > reconstruct my wallet's master seed after my death. I would like to > > distribute seed shares to each of my beneficiaries and some close friends, > > such that some subset of the shares must be joined together to reconstitute > > my master seed. Shamir's Secret Sharing Scheme is perfect for this use > > case. I am presently working on extending my draft BIP so that it also > > applies to BIP32 master seeds of various sizes. > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > ------------------------------------------------------------------------------ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
