< fanquake>
From memory you need to pick option (1)
< fanquake>
Also, if your not using Ubuntu 18.04, which recently became available in the Windows Store, I'd suggest swapping to that. We have a WIP PR #13246, with simplified build instructions.
< jonasschnelli>
sipa: we once talked about a similar error correction format (more tolerant) for private keys/seeds. Are you still exploring that field?
< jonasschnelli>
(similar to bech32)
< sipa>
i haven't followed up on that
< sipa>
but i can send a mail with the possible trade-offs or os
< jonasschnelli>
sipa: Do you think it makes sense to introduce a bip32 equivalent for xpriv in bech32 with seed birthday?
< sipa>
jonasschnelli: i don't think that the path of trying to encode all of the possible metadata around a key and derivation paths into one string is feasible
< jonasschnelli>
I guess there is a lot of blockchain scans (bandwidth and CPU consumption) due to the fact that seeds have no birthday
< sipa>
perhaps birthdate can be added
< sipa>
but what about subranges
< jonasschnelli>
subranges?
< sipa>
or whether hardened or nonhardened derivation is supposed to be used
< sipa>
or if it's a multisig key, the other chains to combine it with
< luke-jr>
there's too many possible variants to even try to include it IMO
< gmaxwell>
even just versioning so such things could be added later in a compatible way...
< sipa>
or if it's a nonstandard script, do you include some template into the string too?
< gmaxwell>
luke-jr: there is a subset which is much easier, known needed, etc.
< jonasschnelli>
Yes. Maybe a version bit and a birthday is a way to start. Other metadata is also interesting but birthday is most imortant and uses almost no bytes.
< luke-jr>
perhaps just an generic id field of some sort that can include a wallet format/name
< gmaxwell>
e.g. we _know_ a birth epoch is very useful, virtually always.
< gmaxwell>
it would be kinda sad to omit that just because we're not sure on all the other fields we might want to include. :)
< luke-jr>
I'm certainly not arguing against birth epoch
< jonasschnelli>
I'd say the birthday week from 2009-01-01 would be sufficient
< sipa>
to me, eventually these things will be some standard json like description of keys/addresses/templating/...
< luke-jr>
jonasschnelli: year+week might be easier to handle in code
< sipa>
and there may be "optimizations" to it which e.g. pack the private key into the same string as the derivation path (like xprv)
< gmaxwell>
jonasschnelli: I think there was some list post where I gave some figures on resoltion vs size tradeoff.
< sipa>
and perhaps pack the derivation type along with it (bip 158)
< sipa>
and perhaps the date/time too
< jonasschnelli>
gmaxwell: Okay. I'll search for it
< sipa>
but i don't like the current thinking... which is essentially that the private key "string" is all you have
< sipa>
and that everything *must* be inside of it, or it doesn't exist
< gmaxwell>
sipa: that does reflect common backup practices.
< luke-jr>
sipa: agreed
< sipa>
well it could be a single string still - but not all of it needs to be encoded into an opaque blob
< sipa>
you could have something URI like that adds extra data
< gmaxwell>
I cerantly agree with your on that point though-- some things like metadata about your txn _cannot_ be encoded in any string set upfront regardless of how long it is... and that data can be pretty critical.
< jonasschnelli>
I guess one of the problems is, that users have the idea with 24 words they have a complete backup.
< sipa>
that's just silly
< jonasschnelli>
But it is sadly the reality...
< sipa>
there's not even a way to have an version number in it
< gmaxwell>
it's also what e.g. electrum and basically claims.
< luke-jr>
jonasschnelli: we don't have to encourage bad ideas
< gmaxwell>
(I mean claims as a feature)
< sipa>
jonasschnelli: well, i think what i'm thinking is a lower level than a whole wallet
< jonasschnelli>
The Bitbox approach to backup to an SDCard seems to be accepted but people still prefer to "write down words to a paper" for backup.
< gmaxwell>
Not just to a paper, it's relatively easy to make a fire durable backup of a short string.
< luke-jr>
ideally, one would have metadata fully encrypted with a key derived from the seed, and automatically make remote backups of the metadata
< luke-jr>
then one can use the seed to recover the full metadata, assuming it's widely backed up
< gmaxwell>
right I think a better model in general would be some nice integration where your seed also lets you derrive and ID and encryption key for an encrypted backup that could be stored insecurely... and it would have all that metadata other than the most limited needed for a recovery.
< gmaxwell>
and enough data so that if your metadata is lost it's still possible to recover things, though perhaps expensive.
< gmaxwell>
such a process would let backups store things like transaction notes and whatnot that could never be captured otherwise.
< sipa>
that's effectively all the non-volatile metadata you need to describe a (part of) a wallet
< gmaxwell>
and would still let users have a short key to stick in a fire safe.
< gmaxwell>
in any case if "store the metadata elsewhere" were the path, basically the seed would only need versioning and maybe a hint about the kind of derrivation paths that were used.
< gmaxwell>
sipa: one thing that isn't included in your lists, is that user really often want to protect their seeds with passwords, and doing that potentially has some overheads.
< luke-jr>
well, so long as you can derive the backup key(s), you can put the rest of the derivation in the metadata
< gmaxwell>
(alternatively or inaddition to they want to do secret sharing.)
< sipa>
gmaxwell: well this is just describing the part that it's inside the wallet; not how it is to be encoded for exporting/importing
< gmaxwell>
luke-jr: I think the idea I was thinking about there would still admit recovery from only the seed but perhaps only in a very costly manner, e.g. lots of brute force path searching or forensics to figure out what software you used.
< gmaxwell>
sipa: I know, just pointing that serializing that stuff still probably isn't enough.
< sipa>
well this doesn't describe seeds at all
< sipa>
if you want a seed, you'll have some short string and a determinstic way to derive all of this from it
< gmaxwell>
yep not faulting your document.
< sipa>
but i don't expect an ability to encode a seed _from_ that data
< gmaxwell>
luke-jr: if you can (even at some expense) recover without the 'backup' it makes the backup solution much more usable. e.g. don't have to worry much about your backup being randsomed for 50% of your funds.
< luke-jr>
gmaxwell: true
< jonasschnelli>
what alternatives for PBKDF2 with silly static 2048 rounds for seed passphrase derivation would make sense?
< jonasschnelli>
Or are passphrase protected seed just a footgun?
< jonasschnelli>
*seeds
< gmaxwell>
2048 rounds of PBKDF2 really reeks of snake oil. It's not a meaningful amount of hardening.
< gmaxwell>
I think passphrase protected seeds are a footgun, at least if there isn't a recovery mechenism... but people want them anyways.
< gmaxwell>
And a recovery mechenism could be provided totally seperately.
< jonasschnelli>
gmaxwell: with "recovery mechanism" you mean an expensive forensic like approach to recover a lost seed-passphrase?
< gmaxwell>
I'm still fond of offloadable KDFs, which we know how to do. But when I talked to the trezor folks about that they wanted an additional property that they be (cheaply) verifyable, which seems possible but moves it more towards being a research problem.
< gmaxwell>
jonasschnelli: I mean, like, for example, your backup could contain the an encrypted copy of the passphrase in a section accessable with the seed alone, which you could decrypt with the help of a recovery service. E.g. to recover your wallet you need seed+passphrase OR seed + bob's help. (e.g. your backup has an encrypted message to bob, saying that he should give the content to anyone who pr
< gmaxwell>
esents him with a passport with your name on it, and not otherwise).
< gmaxwell>
exactly how password recovery works is a huge rathole, unfortunately.
< gmaxwell>
Which is why I was making the point that even though I think it's unsafe design to prompt users for a password without having one, ... it's fine to design a scheme that allows for passwords, since recovery can be provided by something else.
< jonasschnelli>
Indeed
< gmaxwell>
the problem for passphrases is that they're really kinda dumb without a KDF, if the user provides the password (and if the user doesn't come up with the password they are even more likely to forget it).
< gmaxwell>
but people also want to use these schemes with hardware wallets, which don't have the CPU power to do a KDF that a GPU wouldn't laugh at.
< roasbeef>
jonasschnelli: re-seed stuff, have y'all seen what we made for lnd? it has all the features one would desire in a seed format: reversible mapping between seed+phrase (uses an arbitrary length tweakable block cipher), a versioning scheme (for the encryption and also the internal wallet payload), if you use a passphrase we can detect invalid attempts, and also we have a "birthdate" which is offset from the genesis block in days -- good till 2189 (iir
< roasbeef>
uses proper key derivation (no like 2k rounds of sha2 or w/e lol)
< sipa>
roasbeef: does proper imply variable number of rounds? :)
< roasbeef>
well woudl be able to have diff versions with higher/lower number of rounds to make it easier for say hardware wallets if that's what you mean
< kallewoof>
sdaftuar: When doing coin selection on groups rather than individual outputs, the ancestor/descendant stuff becomes rather messy if you don't unify them to their corresponding maximums. In order to do that, you need the values, since they are tested against multiple limits.