Do you think a 24-word list is a way better to store/transmit your private key than our current nsec1... code?
Pros:
1. It's easier to copy a word list from a phone to a computer by hand.
2. Currently understood as a "private"/"don't let other people see it" thing
Cons:
1. Confusion with other word lists?
2. Too long?
If going the word route, why not 12? 24 is too long and 12 is secure enough for practical purposes.
Nostr uses 32 byte private keys, which requires 24 words with the usual wordlists we see out there.
Maybe 12 words...? Generally I would prefer word lists to be able to write it down / hammer it into steel for long time storage.
12 words over nsec all the time. The problem with nsec is that you really can't handle it well other than by copy/paste and on Android, all the apps have access to your clipboard without extra permissions.
How about 24 words? Nsec is 32byte which, for a 2048 word dictionary, requires 24 words. :(
6 lines of 4 words each is borderline doable in terms of manual typing
that long ass number ? i'm not typing that out - forget it.
Just like Bitcoin, you should generate the private key (the 32 bytes), from the words, not the words from the private key. Bip-39 feeds the words as a string into a PBKDF2 using SHA-512, which provides the master seed for HD wallets (64 bytes). So whether it's 12, 17, 24, or 102 words, it will all work, however any more words then 12 doesn't add any extra security.
Btw, why not implement a Bip-32 like hit hierarchical deterministic nostr accounts? This way you could have the master account that can access it's subordinate accounts.
We can implement. But we don't have the seeds for any of the keys people are already using today. And no one will want to migrate to a new key and lose everything just because of seed words. We have to find a way to make it work with the current keys.
That's "easy". For non seed keys, use a different type, and encrypt the non-seed key under the seed key (and store it). You could do that for seed keys as well to have only a single type.
Sure, but then we will def need more than 12 words.
Why? I'm not exactly sure what Custom Designed meant but it sounded to me like you could store old keys encrypted with the new keys. So when migrating to HD mnemonic based key backup, you use a certain key derivation for a symmetric key and then store your old key(s) in a special event but encrypted with the new key. So when you restore from the mnemonic, the client could ask you which of your accounts to use. It could show you mentions of your legacy account even after switching to a new pubkey etc. The client could sign notifications that the legacy key was rolled over to the new key (whichever sub-key currently is active).
If you encrypt the old key with the new key you would have to store the key + an encrypted payload. There is no way to create recreate a seed from one the keys it could generate. And because of that, you have to save both the words and the encrypted payload which given that the private key is already 32 bytes, requires more than 24 words for the two things (payload + seed) combined.
I meant you store the legacy key(s) in a nostr event. After all we trust our crypto. This event of course would be fatal if it went lost but as this could be a special kind, it might get special care on relays.
Get a new 12 words mnemonic M. Generate the master seed. Use m/12'/12' as encryption key for your kind-1212 event where legacy keys get stored.
Ohhh saving nsecs on Nostr feels dangerous.
What the other guy said. The standard should not encode the current keys with mnemonics. 12 words is plenty secure. At least until people start losing their Bitcoins secured by 12 words nostr should not bother using 24 words.
I would love for us to have a 24 word option. It is very convenient to save and restore NSEC keys. What I don't know, friend, is if we can reverse an NSEC to get its 24 words so as not to lose our data.
Imo nsecs should stay, it makes the distinction clear which is for money and which is for social.
I'd like to be able to easily write down my private key so backups don't have to be stored on something connected to the internet, so I really like this idea.
Perhaps provide it as an option to reveal the 24-word seed phrase at the same place in the app where one would copy their nsec?
Whichever way gets nsec rotation here sooner...
I'm ok with nsec. And this way the chance of mixing with wallet seeds is slim
i think 12 word codes would be plenty, but they don't give you vanity option, 24 words is required to have vanity keys
there is a NIP for word keys and nobody implements it, because you all are crypto n000bs and don't understand cryptography or encoding schemes
100% 12 words is a great option
personally i think that 18 words is a nice in-between size that has very high entropy but it's not in BIP-39 for whatever retarded reason
i'd be willing to propose a nostr native 18 word key derivation scheme, it's not a big job for me to devise something like this
Words are easier to handle and also store. It’s harder to hide nsec string and claim it’s something else. Also harder to memorise or type by hand.
Npub and words are also different formats so accidental pasting of nsec instead of npub should disappear.
Nsec would be fine if there a way of storing it offline/attaching cold signage (e.g. yubikey).
But I'm no developer so idk how you'd begin to do that.
If I had to choose 1, I'd choose the nsec.
The 24 words could be an optional way to back up & restore your identity. It shouldn't be the only way though.
The copy & paste functionality is the main reason I'd go with the nsec. This isn't money & currently is just the keys to a social identity.
In time the nsec might become more critical to protect & offline storage of this secret might make more sense.
I really would love the option to store my nostr private key with the help of a BIP39 mnemonic.
The real game changer is BIP85 which let's you derive infinite 12/24 seed words for different use cases. You only need the backup the master seed by stamping it into steel for example and can note that the first derived seed is your cold storage, the second your lightning node, the third your nostr identity etc.
does nostr support tls ，ip mixture？
I am fond of the nsec code.
Just follow in btc foot steps we’ve had this discussion before
I think nsec1 is fine. I back it up with keepass2android. Very secure and convenient backup.
Don't know about the rest. Not clear if it's stored online in a client somehow. Been looking at Amber. But need to look closer.
Trying to understand Nip43..¯\_(ツ)_/¯
Base64 stored in a vault where it cannot be touched, with plenty of encryption and regular backups. No copy/paste, ever.
nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z how can I manage it without a password manager ?
I'm happy you brought this up for discussion. I think most new people may confuse this with other word lists if they don't have a general understanding of Bitcoin, Nostr, and cryptography. This would probably be even more confusing if they are new to Bitcoin and Nostr at the same time.
