Re: [Bitcoin-development] BIP38 Encrypted Address Discussion

[Gregory Maxwell <gmaxwell@gmail.com>]

On Mon, Jun 9, 2014 at 11:13 AM, Richard Moore <me@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.