On Mon, Jun 9, 2014 at 11:13 AM, Richard Moore <m...@ricmoo.com> wrote: > Hey all again, > > I am implementing BIP38 wallets right now, and had another idea I would like > to put out there for discussion. > > Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was > wondering if it would make sense to include an extra byte in the address > which would encode the parameters used? For now, they are fine, as it takes > over 3 minutes to to hash once in my pure-Python implementation in CPython (3 > seconds in pypy). But with all the latest scrypt mining ASICS hitting the > market, and the difficulty rising of the scrypt alt coins, it may become more > profitable in the future to try hacking wallets to gobble up their funds. > Currently all the hardware is tuned for (1024, 1, 1) and with adaptive-N, it > only targets upgrading the N value, so having p =r = 8 certainly means that > hardware won’t affect BIP 38… But who knows in the future if they start > making Adaptive-N-r-p ASICS. > > It also provides a way to vastly secure more important master keys… Maybe for > a key that is cold storage of millions of dollars that won’t be touched for > multiple years, I don’t mind waiting an hour on commodity hardware to decrypt > it.
See the not yet finished proposal at https://bitcointalk.org/index.php?topic=258678.0 It's generally a lot more sound and well thought out than BIP38. Though right now I believe it's being revised to support secret sharing. ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
