Re-reading the post, i think my solution is for a different problem, using nsecs accross devices and platforms, not ease of use.

Reply to this note

Please Login to reply.

Discussion

I think that's what he wanted. Conveniently migrate to some other system/platform. Make the nsec available there. What I understood from you was: why not derive a key to use there. Which could work equally well. Only, I then realized that this key would endanger the original nsec. So I may (also) be thinking of the wrong goal. 😅😂

The sub key would not, because it is derived accross one way cryptography. Like the way sub addresses or GPG keys can be derived from a single secret but not hint at the seed itself. (Otherwise we would all be screwed) Think of it like having two identical cups made of glass. You break one, throw away the larger pieces and use the dust from that as an address that matches with the one you keep hidden. There is no easy way to recreate the glass based on the dust, but the dust finds a matching place in the unbroken cup.

What i realized is that if we could do that with nsecs, it would still be a huge clumsy number that's not easy to send to a desktop application. As the OP suggested, something like a QR code is easier.