This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and host of a tech-oriented Bitcoin podcast.
I suggest, before reading this, that you read the previous article I wrote to explain what Nostr is and how it works at a high level. You should then have a good idea of the core design of the system at that point, so now let’s take a look at the possible problems that will happen when it grows in adoption. With the platform becoming popular for the Bitcoin community, the issue is worth noting.
As I discussed in previous articles, the public user/private key pair is integral to how Nostr works as a protocol. There is no username, or any type of identifier controlled by the relay server, to be associated with an individual user. This is the only key the user can control.
It functions as a tight binding between the real user and the way he is identified by others that prevents the relay server from unbinding the two, that is, giving the person’s identifier to another user. This solves one of the biggest fundamental problems in platforms used to communicate between people: the lack of control over the user’s own identity. But it also introduces all the key management issues that people with private keys have to deal with. Keys can be lost and keys can be compromised and when that happens, users have no recourse, just like Bitcoin. There is no customer support to refund anything. You’re lost, that’s it.
This of course requires a scheme to allow users to rotate from one key pair to another in a way that is verifiable and discoverable to other users interacting with them through the protocol. The entire protocol is based on proving that an event came from a specific user (identity key), so all those guarantees go out the window if someone’s key is compromised.
How to handle that? Just checking your Twitter account? Yes, so this is not a decentralized system, in the end, if you need a centralized platform that does not control the identity to verify the identity of Nostr.
Can other users prove the legitimacy of the new key? That doesn’t deal with situations like mass key compromise, or not knowing anyone close enough to trust them.
Nostr requires an actual cryptographic scheme that connects the rotation of one key to another. There is a proposal from the fiatjaf developer for a basic scheme that can solve this problem. The basic idea is to take a long set of addresses derived from one master seed, and create a set of “tweaked” keys similar to how the Taproot tree is committed to Bitcoin keys. Taproot takes the root of the Merkle tree from the Taproot tree and “appends” it to the public key to create a new public key. This can be replicated by adding the root of the Merkle tree to the private key in order to obtain the corresponding private key for the new public key. Fiatjaf’s idea is to create commits backwards from end to beginning so that each modified key will contain evidence that the next tweak key was used to create it.
So, imagine starting with the Z key, which is the last in the chain. You will tweak this with something, and then go back and make 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 tweak X (Y’ + X = X’). You’ll do this all the way back to the A button, to get A’, and from there, start using that button. If compromised, a user can broadcast an event containing an untamperable A key and a B’ key. It will contain all the data needed to show B’ was used to produce A’, and the user can immediately stop following A’ and follow B’. They always know that B’ is the user’s next key and follow that.
This proposal still has some problems. First, you have to generate all the keys you will be using before and there is no way to roll to a new set of keys. This can be handled by implementing a master key in this scheme that can notarize the rotation, or simply create a large set of keys from scratch. Either path will be the correct path, but ultimately requires a root key or key material to be secure and only open individual hotkeys to the Nostr client.
This scheme, however, does nothing to protect the user or offer an identity recovery mechanism if the root key material is lost or compromised. Now, this is not to say that there is no point in fiatjaf schemes, they are, but it is important to make the point that no single solution can solve every problem.
To pontificate a bit on the potential solution here, imagine instead of a chain of tweaked buttons as he proposed, that tweaked button with a cold button master that must also be used to sign events play from one button to another. You have a key A’, which is derived by adding A and M (the master key), and the rotation event will be A, M and B’ (created by adding B and M) with signature from M. M can be a multisig threshold key – two out of three, three out of five, etc. This has the potential to increase redundancy against loss as well as provide a safe mechanism for key rotation. It also opens the door to using services to help with recovery, or distributing some of those keys to trusted friends. It offers all the same flexibility that multisig has with Bitcoin itself.
NIP26 is also a very useful proposal to solve this problem. It defines a protocol extension for events that allows a signature from one key to authorize another key to send an event on its behalf. The “token,” or proof-of-delegate 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 the delegation token automatically expires and needs to be renewed.
In the end, however, this problem has been solved already to be solved for Nostr in the long term. Protocols based on all public/private key pairs used as identities cannot gain traction and adoption if the integrity of these identities cannot be protected and maintained for users. That will eventually stop using a single, centralized platform to verify new keys and coordinate people following your new identity when something is lost or compromised, and at that point, the other platform becomes a means to spread confusion. and engage in censorship.
The issue of key management and security is a big problem with a very large design space full of trade-offs and pain points, but it is a problem that needs to be solved in the context of Nostr to make it work. In the next article, I’ll summarize some of the issues I’ve seen with the relay server architecture and scaling issues that Nostr developers have to face because of the underlying data structures built into Nostr.
For anyone reading and wondering why I didn’t mention decentralized identifiers (DIDs): Yes, this is a potential solution to the problem that, in my opinion, is quite comprehensive. However, Nostr developers seem very hesitant to integrate DID into their protocol or client due to the fact that it will create external dependencies outside the Nostr protocol. If you don’t understand how DID works on a technical level and are interested, this article by Level 39 is a well written overview of how it works.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.