This is an opinion piece by Shinobi, a self-taught educator in the Bitcoin space and tech-minded Bitcoin podcast host.
before reading this In a previous article, I wrote an article explaining what Nostr is and how it works at a high levelAt that point, you should have a good idea of the core design of your system. So let’s take a look at the issues that can arise as recruitment progresses.platform and Become popular with the Bitcoin communitythese issues are something to be aware of.
As explained in the previous article, a user’s public/private key pair is integral to the way Nostr functions as a protocol. There is no username associated with an individual user or any kind of identifier controlled by a relay server. It’s just those users’ keys that are completely under your control.
It acts as a tight coupling between the actual user and how the user is identified by other users, and the ability of the relay server to uncouple the two (i.e. give someone’s identity to another user). ). This solves one of the biggest underlying problems of platforms used for communication between people: the user’s inability to control her identity. But it also brings with it all the key management problems that people with private keys encounter. Keys can be lost or compromised, and in the event of such an event, users have no one to turn to for help, just like Bitcoin. No customer support to recover anything. You lose it, that’s all.
This necessarily requires a scheme to rotate from one keypair to another in a way that is verifiable and discoverable by other users with whom the user interacts via the protocol. The entire protocol is based on proving that an event is from a specific user (the identity key), so all these guarantees are void if someone’s key is compromised.
how do you handle that? Check out their Twitter account. Well, in the end, if you have to use a centralized platform that doesn’t control identities to verify Nostr’s identities, it’s not a very decentralized system.
Have other users attested to the new key? This does not address situations such as large-scale key compromise or not knowing who is close enough to trust their certificate .
Nostr requires a real cryptographic scheme that ties the rotation of one key to another.there is Suggestion from developer fiatjaf For a basic scheme that could potentially solve this problem. The basic idea is to take a long set of addresses derived from a single master seed and create a series of “tuned” keys similar to how Taproot trees are committed to Bitcoin keys. Taproot takes the Merkle tree root of the Taproot tree and “appends” it to the public key to create a new public key. This can be duplicated by appending the root of that Merkle tree to the private key to obtain the private key corresponding to the new public key. Fiatjaf’s idea is to chain commitments backwards from last to first so that each reconciled key actually contains evidence that the next reconciled key was used to create it. is to
So imagine starting with the last key in the chain, the Z key. Tweak this with something, then go backwards and create a tweaked version of key Y using the tweaked Z key (Z’ + Y = Y’). Get Y’ from here and use it to tweak X (Y’ + X = X’). Trace this back to key A to get A’ and start using that key from there. If compromised, the user can broadcast an event containing key A before tuning and key B’ after tuning. It contains all the data necessary to show that B’ was used to generate A’, allowing the user to quickly unfollow A’ and follow B’ instead. increase. They clearly know that B’ is the user’s next key and follow that instead.
However, this proposal still has some problems. First, you have to pre-generate all the keys you want to use, and there is no way to rotate to an entirely new set of keys. This can be addressed by committing such rotations to a master key for this scheme that can be notarized, or by generating a very large set of keys from the start. Either method works, but ultimately you should keep your root key or key material safe and only expose your individual hotkeys to Nostr clients.
However, this scheme does not protect the user or provide a mechanism for identity recovery if the root key material is lost or itself compromised. This is not to say that fiatjaf’s scheme is without merit. It’s definitely worth it, but it’s important to stress that there is no one-size-fits-all solution.
To highlight a possible solution here a bit, instead of a chain of coordinated keys as he suggests, it should also be used to sign the event of rotating from one key to another Imagine adjusting keys with a master cold key. We have a key A’ that is derived by adding A and M (the master key), the rotation events are A, M, and B’ (generated by adding B and M), and the signature from M there is. M is the multisig threshold key — 3 of 2, 5 of 3, etc. This potentially adds redundancy against loss and provides a secure mechanism for key rotation. This also opens the way for you to use the service to assist in recovery, or spread some of those keys to trusted friends. We provide everything.
NIP26 is also a very helpful suggestion for dealing with this issue. It specifies an event protocol extension to allow a signature from one key to authorize another key and post an event on its behalf. A “token” or signature proof of delegation is included in all events posted by her second public key on behalf of the first public key. A time limit can also be set so that delegation tokens automatically expire and must be renewed.
Ultimately, no matter how it is resolved, the problem is have It will be resolved for Nostr in the long term. Protocols based entirely on public-private key pairs used as identities will not gain traction and adoption if the integrity of these identities cannot be protected and maintained for users. Ultimately it means having to constantly use an out-of-band centralized platform to validate new keys and coordinate who follows new identities when something is lost or compromised, and that At that point, those other platforms become vehicles for sowing chaos. Engage in censorship.
Key management and security issues are big questions in a very large design space full of trade-offs and pain points, but these issues need to be solved in context for Nostr to work. In the following article, given the underlying data structures Nostr is built on, I’ll explore some of the issues I see with regards to the relay server architecture and scaling issues that Nostr developers have to face. Summarize.
For those wondering why I didn’t mention distributed identifiers (DID): Yes, in my opinion this is a potential solution to these problems, and a very comprehensive one. am. However, Nostr developers seem very reluctant to integrate DID into their protocol or client. This is because it creates an external dependency for the Nostr protocol. If you’re not familiar with how DID works on a technical level and are curious, This article by Level 39 Very well put together on how they work.
This is a guest post from Shinobi. Opinions expressed are entirely his own and do not necessarily reflect those of his BTC Inc or Bitcoin Magazine.
