I think a standard format for encrypted backup of the key material (not the hierarchy) is useful.

The heart of any password-based encryption is the KDF -- in this case you've chosen scrypt with n=2^14, r = 8, p = 8.  Just a quick benchmark on my desktop shows this runs at about 25 iters / sec, using about 12MB of RAM per thread, which may be "slow enough", but hard to say definitively. By comparison n=16, r = 16, p = 16 which runs at about 2 iter / sec, using 100MB of RAM for per  thread...  or even n = 18, r = 16, p = 16 which runs at 0.5 / sec, using 500MB of RAM per thread.

Since we're talking about backing up 128 bits, I think it's reasonable to assume the end-user could either just memorize a 128-bit mnemonic (e.g. BIP39), and then they don't need a password (or a backup) at all, or alternatively they would use a password with most likely, significantly less than 128-bits of entropy.

The trade-off of using stricter 'scrypt' parameters is some devices may not be suitable for running even a single iteration. The problem is, if you target your settings to make these devices usable, you're throwing away a lot of the benefit of 'scrypt' -- to make brute-force attacks expensive across a wide range of devices, including GPU and ASIC.

A couple possible options:

  1) Do nothing -- Keep 14/8/8 as the standard hard-coded settings for the KDF as it's "slow enough"
  2) Increase difficulty -- Then we need to decide what the "right" settings are, including what the maximum RAM requirement should be
  3) Provide some means of using different difficulties since there's no one-size-fits-all

Ultimately #3 would come down to somehow encoding the KDF/difficulty -- there are a few ways to do it...

  3a) Add a one or two byte KDF enum -- 00 could mean "scrypt/14-8-8".  01 = "scrypt/16-16-16", 02 = "scrypt/18-16-16", etc.  This has the advantage of allowing us to keep the format and use KDFs other than scrypt if desired. Possibly include a default of "scrypt/14-8-8" if these bytes were not present.

  3b) Hard code assumption that the KDF is scrypt, and give a 2 or 3 byte encoding of the scrypt parameters that were used.  Possibly include a default of 14-8-8 if these bytes were not present.