This is the opinion editor of Shinobi, a self-taught educator and tech-oriented Bitcoin podcast host in the Bitcoin space.
Before reading this, I suggest you read the previous article that explains what Nostr is and how it works at a high level. You should then have a good idea of the basic design of the system, so let’s now look at some of the problems that might arise in its adoption. As the platform has become a popular platform for the Bitcoin community, it is important to be aware of these issues.
As I discussed in a previous article, a user’s public/private key pairs are integral to how Nostr works as a protocol. There are no usernames or any type of identifier that the relay server controls to associate with individual users. Simply put, users’ keys are completely under their control.
This acts as a tight seal between the actual user and how they are identified by others, preventing any relay server from bridging the two, i.e. giving someone’s ID to another user. This solves one of the biggest fundamental problems of platforms used for human-to-human communication: users’ lack of control over their identities. But it also introduces all the key management issues that someone with a private key faces. Keys can be lost and keys can be compromised, and if that happens, users have no one to turn to for help like they do with Bitcoin. There is no customer support to restore anything. You lose it, that’s it.
This will inevitably require a scheme for users to rotate from one pair of keys to another in a way that is verifiable and detectable to other users with whom they interact via the protocol. The entire protocol is based on proving that the event came from a specific user (authentication key), so once someone’s keys are compromised, all those guarantees go out the window.
How do you manage it? Just go check out their Twitter account? Well, then it’s not a very decentralized system, as a result, if you require Nostr to use a centralized platform where they don’t control their identity to verify their identity.
Do other users confirm the legitimacy of the new key? It doesn’t address situations like massive key compromises or not knowing everyone close to them well enough to trust their attestation.
Nostr needs an actual cryptographic scheme that binds one key rotation to another. There is a proposal from the fiatjaf developer for a basic scheme that can solve this problem. The basic idea would be to take a long set of addresses derived from a single primary seed and create a set of “tweaked” keys similar to how Taproot trees are connected to a Bitcoin key. Taproot takes the root of the Merkle tree of the Taproot tree and “appends” it to the public key to create a new public key. This can be repeated by appending the root of this Merkle tree to the private key to obtain the corresponding private key for the new public key. The idea behind fiatjaf is to chain commits end-to-end so that each modified key contains a proof that the next modified key was actually used to create it.
So imagine starting with the Z key, which is the last in the chain. You would fix it with something, then go back and create a tweaked version of the Y button using the tweaked Z button (Z’ + Y = Y’). From here you will take Y’ and then use it to draw X (Y’ + X = X’). You would do this up to the A key to get the A’ key, and from there you should start using that key. When it is compromised, the user can broadcast an event with an unmodified A key and a modified B key. This will contain all the information needed to show that B was used to create A’, and users can immediately unfollow A’ and follow B’ instead. They will know for sure that B is that user’s next key and follow that instead.
This proposal still has some problems. First, you have to create all the keys you’re going to use ahead of time, and there’s no way it’s going to rotate to a whole new set of keys. This can be solved in this scheme by committing to a master key that can notarize such rotations, or by simply generating a very large set of keys from the beginning. Either path would be a valid course to take, but would ultimately require keeping the root key or key material secure and only providing individual hotkeys to Nostr clients.
However, this scheme does nothing to protect users or offer an identity recovery mechanism in case the root key material is lost or itself compromised. Now this isn’t to say that fiatjaf’s scheme doesn’t have any benefits, it definitely does, but it’s important to note that no one solution solves every problem.
To give you some idea of potential solutions, imagine that instead of a chain of keys fixed as he suggests, a key is configured with a key cold key that should be used to sign an event that rotates from one key to another. You have a key A’ obtained by adding A and M (primary key) and the rotation event will be A, M, and B’ (created by adding B and M) with M signature M. multisig threshold key — two out of three, three out of five, etc. . This opens the door to using services to help with recovery or distributing some of these keys to trusted friends. It offers the same convenience of multisig as Bitcoin itself.
NIP26 is also a proposal that can be very useful in solving this problem. This defines a protocol extension to events that allows a signature from one key to allow another key to send events on its behalf. The “token” or proof of delegation signature will then be included in all events sent by the second public key on behalf of the first. It can even be time-limited so that representation tokens expire and renew automatically.
As a result, this problem is solved there is will be solved for Nostr in the long run. A protocol based entirely on public/private key pairs used as identities cannot gain traction and adoption unless the integrity of those identities can be preserved for users. This will eventually mean that when something is lost or compromised, you will have to constantly use out-of-band and centralized platforms to verify new keys and connect people to your new identity, and at that point, other platforms will become a tool for confusion. and engage in censorship.
Basic management and security issues are huge challenges with a very large design space, but they are issues that need to be addressed in the context of Nostr to make it work. In my next article, I will summarize some of the issues that arise with the relay server architecture and the scaling issues that Nostr developers will have to deal with given the underlying data structures Nostr is built on.
For anyone reading and wondering why I didn’t mention Decentralized Identifiers (DIDs): Yes, this is a potential solution to these problems, which I think are pretty comprehensive. However, Nostr developers are very hesitant to integrate DIDs into the protocol or clients, as this may create external dependencies outside of the Nostr protocol. If you are not familiar with how DIDs work on a technical level and are interested, this article by Level 39 is a very well written summary of how they work.
This is a guest post by Shinobi. The views expressed are entirely their own and do not necessarily reflect the views of BTC Inc or Bitcoin Magazine.