SwBratcher on Nostr: This is the response to Abhay when he asked, "So for every event, a client needs to ...

This is the response to Abhay (npub1cgd…kfex) when he asked, "So for every event, a client needs to check wether the event is from a root key or a delegated key? I feel like this has been brought up before."

quoting note1kfu…j5zf

Goal is not to (or at least minimally) impact compute requirements. Intent is that relays do not need to perform additional computational checks for every event unless delegation proofs are involved. Here’s a breakdown of how computational requirements are distributed:

For events signed by root keys (nsec), relays only need to verify the signature using the associated npub. This is the same Computational Demand as currently, requiring a single cryptographic signature verification.

For events signed by subordinate keys (nsub), relays must verify the event’s signature using the subordinate key (nsub) and check if a valid delegation proof exists for the subordinate key, signed by the root key (nsec).

Steps:
- Verify the event’s signature using the nsub public key.
- Verify the delegation proof’s signature, which ties the nsub to the nsec:
Check the proof’s conditions, such as event kinds and expiration.
This adds a second cryptographic signature verification for events signed by subordinate keys only.

Optimized Relay Behavior thoughts:
To minimize computational overhead, relays could cache Validated Delegation Proofs. Once a delegation proof is validated, it can be cached to avoid revalidating it for every event from the same nsub. This reduces the need to repeatedly verify the delegation proof signature. Or maybe a relay can do selective validation, relays only validate delegation proofs when an event is signed by a key that is not recognized as a root key (nsec).

Relays will be able to differentiate between events signed by a subordinate key (nsub) and those signed by the master key (nsec) through the delegation proof mechanism.

Events signed directly by the master key (nsec) do not include a delegation proof. Relays process these events as they currently do: verifying the event signature against the public key (npub). Events signed by a subordinate key (nsub) must include a delegation proof that links the nsub to the master key (nsec), and defines the conditions (e.g., event kinds and expiration) under which the nsub is authorized. The delegation proof is stored in the event’s tags (e.g., as a delegation tag).

Event Example with Delegation Proof

An event signed by a subordinate key might look like this:

{
"id": "",
"pubkey": "",
"created_at": "",
"kind": 1,
"tags": [
["delegation", "", "", ""]
],
"content": "This is a delegated event.",
"sig": ""
}

pubkey: Indicates the key (nsub) that signed the event.
tags:
Contains a delegation tag with:
The master_npub (public key of the nsec).
Delegation conditions (e.g., allowed event kinds, expiration timestamp).
Signature of the delegation proof (signed by nsec).
sig: Signature for the event content itself, signed by nsub.

Relay Processing
1. Check the pubkey Field:
Relays first verify the event signature using the public key in the pubkey field.
If the event is signed by nsec, it passes validation directly.
2. Look for a Delegation Tag:
If the pubkey is not recognized as a nsec-level key, relays check for a delegation tag in the event.
If a delegation tag exists, relays:
1. Validate the delegation proof (signed by nsec).
2. Verify that the event conditions (e.g., kind, expiration) match the delegation proof.
3. Reject or Accept the Event:
If the delegation proof is valid, the event is accepted.
If the delegation proof is missing, invalid, or expired, the event is rejected.

So, on events signed by nsec, no delegation tag is required and they’re processed directly based on signature verification. While, events signed by nsub must include a valid delegation tag and relays validate the delegation proof before processing.

Relays need to verify whether an event includes a delegation tag to determine if it originates from a subordinate key. This mechanism ensures backward compatibility, as relays can still process events signed by nsec without requiring changes to the current protocol for root-level events.

This is the thought. But I’m barely qualified to conceive it since I’m not a dev in this env. Poke holes in my inaccurate assumptions please.