Nostr notes by

If RBTC traded at 50 cents while Bitcoin is at 80k, this would ...

2026-10-24T06:52:36Z

In reply to nevent1q…0ece
_________________________

If RBTC traded at 50 cents while Bitcoin is at 80k, this would presumably mean that people think there's something seriously wrong with the bridge. The value of RBTC just seems to reflect people's view of the integrity of the pegging mechanism and the trustworthiness of the pegnatories. By contrast, the value of Bitcoin or Ethereum reflects people's view of the security, usefulness and future of the chain itself. It feels like, in the case of Bitcoin and Ethereum there's more overlap between those who are defending these chains and those who have their economic interests bound up in them, and there's less of a single point of failure, but I guess I'll need to look into this more. Also it's of course perfectly fair to predict that things will get better in the future with BitVM, but the prediction doesn't substitute for what it presently is.

I think I've never met a plumber. I wonder if they are nice ...

2026-10-23T10:00:50Z

In reply to nevent1q…vrqq
_________________________

I think I've never met a plumber. I wonder if they are nice people.

Google Maps is the reason I got a smartphone 14 years ago. I saw ...

2026-10-23T07:11:53Z

In reply to nevent1q…sf3z
_________________________

Google Maps is the reason I got a smartphone 14 years ago. I saw it on a friend's phone and thought oh it would be useful to have that. As far as I know, it's the only distinctive product Google ever made.

Humans moving from memory to writing seems quite similar to what ...

2026-10-21T13:58:41Z

In reply to nevent1q…ynhj
_________________________

Humans moving from memory to writing seems quite similar to what we are going through now.

"this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves."

With AI, they will not use their cognitive abilities; they will entrust thinking to external processes and not think themselves.

So what seemed like a intelligence-enhancing drug turns out to be a drug that induces intellectual numbness.

I think psychologists call it cognitive offloading.

With rootstock, I guess the main discomfort really does come from ...

2026-10-23T07:01:54Z

In reply to nevent1q…jm2e
_________________________

With rootstock, I guess the main discomfort really does come from the fact that its funding isn't endogenous, its being pegged to Bitcoin. Looking into this a bit further, it seems like the pegnatories aren't anonymous happily, but it's still unclear why one would want to trust a handful of companies with peg-outs. This feature makes it seem rather fragile.

I think I agree, it requires a modest amount of effort and a ...

2026-10-22T13:16:16Z

In reply to nevent1q…7vvz
_________________________

I think I agree, it requires a modest amount of effort and a willingness to direct ones attention to it from time to time, as do many things in life. Like learning a bit of algebra or trigonometry, or maybe playing the piano or volleyball with some basic proficiency. Humans don't usually do these things of their own accord, so we create special educational environments with a carefree atmosphere that allows them to open their minds towards these things. There is no reason that basic asymmetric cryptography shouldn't be part of this.

Now all that said, I'm embarrassed to admit that I myself don't know a lot about entropy generation, don't know what a "descriptor for multisig" is, and don't know what "m/4/0/0/1" refers to. That's not to say that these are abtruse concepts, I guess just that I haven't encountered them or at least not in a way where I felt like I had to think about them.

On the one hand there's zero demand, and on the other hand ...

2026-10-22T07:11:33Z

In reply to nevent1q…jm2e
_________________________

On the one hand there's zero demand, and on the other hand just a couple of hours ago I came across yet another post proclaiming that "[k]ey rotation is an existential problem that cries out for an answer."

quoting
naddr1qv…w6eg

I'm going to take a stab at one of the most difficult and important problems in freedom technology: key rotation. Can web of trust help? If so, how?

The canonical use case will be that of a compromised nostr nsec. Suppose Alice wakes up one morning to discover that her nsec has been compromised by a scammer who is sending DMs to all of her contacts asking for sats. She needs the community to know that this nsec is compromised, she needs to spin up a new nsec, she needs the community to know that this is her new replacement nsec, and she needs to do all of this ASAP. How does she proceed?

My guiding principle is something that deserves a name, but doesn't to my knowledge have one, so I'll just call it Occam's Design Principle:

“A product should be made as simple as possible, but not simpler.”

Our solution requires Alice to communicate this catastrophe to people who know her in the real world so that they can relay it to the community. So for starters, she will tell her friends Bob, Charlie, Dave, etc that her old nsec is compromised. Optionally, she will also provide them with a replacement pubkey corresponding to a new nsec, presuming she has created a new one and wishes the community to know it.

Obviously this is an imperfect solution, but there is no perfect solution, and we desire to keep things simple. Improvements will come later.

The Proposed Solution

We require no new event kinds or new NIPs, other than the Decentralized Lists Custom NIP.

Declaration of the Key Rotation Attestation List

Step 1 is to declare a new type of attestation that Bob, Charlie, Dave, etc. can use to effect the attestation described above. This only needs to be done once.

Following the Decentralized Lists NIP, this is achieved via a kind 9998 list declaration event, also called a list header:
{
  "kind": 9998,
  "tags": [
    ["names", "key rotation attestation", "key rotation attestations"],
    ["description", "This is an attestation whereby Bob, who knows Alice in the real world, can alert the community that her nsec has been compromised. There is only one required piece of data, which is the pubkey corresponding to her compromised nsec. For this, he uses the p tag. Optionally, he can also communicate a replacement pubkey, using the optional pubkey_replacement tag, presuming Alice has supplied him with one."],
    ["required", "p"],
    ["optional", "pubkey_replacement"]
  ],
  "id": "<id_key_rotation_attestation_header>"
}
Issue Key Rotation Attestations

Step 2 is for Bob to issue the attestation that Alice's old nsec has been compromised, and optionally to communicate the pubkey that she intends to replace the old one. This is accomplished via a kind 9999 event. It uses the z tag to point to the parent list header (above), the p tag to indicate the compromised account, and (optionally) the pubkey_replacement tag to indicate the new pubkey:
{
  "kind": 9999,
  "tags": [
    ["z", "<id_key_rotation_attestation_header>"],
    ["p", "<alice_pubkey_compromised>"],
    ["pubkey_replacement", "<alice_pubkey_replacement>"]
  ],
  "id": "<id_key_rotation_attestation_item>"
}
Attestation Support

Step 3 is for Charlie, Dave, etc to voice support (or rejection, as the case may be) for Bob's key rotation attestation using any one of several methods, with kind 7 reactions being the recommended method as described in the Decentralized Lists NIP:
{
  "kind": 7,
  "content": "+", // or "-" to downvote
  "tags": [
    ["e", "<id_key_rotation_attestation_item>"]
  ]
}
Alternatively, Charlie, Dave, etc could simply publish duplicate attestations using their own kind 9999 events, identical to Bob's.

Consumption

How are these attestations processed? If the end user wants to check whether alice_pubkey is valid (to the best of the community's knowledge), use this filter:
{
  "kinds": [9999],
  "#z": ["<id_key_rotation_attestation_header>"],
  "#p": ["alice_pubkey"]
}
Reactions to events returned by this filter would also be obtained with the appropriate kind 7 filter and gathered together. All of these results (kind 9999 and kind 7 events) would then be filtered or weighted based upon the end user's personalized trust metric of the event author. For starters, standard personalized PageRank or personalized GrapeRank metrics would do, easily obtained via Trusted Assertions. More sophisticated metrics might use a proximity score between Alice and the event author; authors whom Alice (previously) followed, for example, could be given the highest weighting. Perhaps Alice could even designate, ahead of time, a NIP-51 list of pubkeys that she would trust to make these attestations. But that would be work for the future; no need to support it in the initial rollout.

Future Expansions of the Protocol

Decentralized Lists provides multiple methods for future expansion of the basic Key Rotation protocol as described above. One might, for example, propose adding one or more tags alongside the p and pubkey_replacement tags. Perhaps a tag that indicates the reason for the rotation: lost, compromised, routine rotation, etc. Perhaps a tag to communicate the timestamp that the rotation is intended to take effect. The list of tags is just that: a list, that can be curated by your web of trust! In the event that multiple incompatible expansions are proposed, the community would hopefully (and probably) settle upon one or the other.

Conclusion

A client that implements the above protocol would be providing a great service to the nostr community and would lay a foundation upon which more complex protocols could evolve. In the event that a friend tells you that her account is compromised, this is the client where you would run so you could shout her predicament from the mountaintops. Such a client would therefore need a well designed interface to issue the relevant attestations and reactions. Any WoT Service Providers worth their salt would, in turn, want to listen to the output of this client and work them into their trust metrics. Therefore, such a client would want to use one or more standard methods to communicate the status of any given pubkey: Trusted Assertions, API, and/or some other method.

This would be a great contribution to the upcoming web of trust hackathon. It could be vibe coded, but ideally a team would form around an idea such as this and ensure excellent execution. And of course, I welcome ideas on how to improve this proposal. LFG!

nevent1q…7e7w

There's a fascinating mix of social dynamics permeating this discussion, here's a recent economic take on it:

quoting
nevent1q…ya37
So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?

Because you can't tell working from broken without spending your own time on it.

After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇

https://en.wikipedia.org/wiki/The_Market_for_Lemons

In this case I guess it's just a story that I read that was ...

2026-10-22T06:10:15Z

In reply to nevent1q…lhrp
_________________________

In this case I guess it's just a story that I read that was told by Plato about a conversation between Phaedrus and Socrates in which Socrates says that there was a myth told by the ancients according to which there was this conversation between two Egyptian gods in the city of Naucratis.

I just saw this proposal for the first time, and I agree that ...

2026-10-22T05:52:09Z

I just saw this proposal for the first time, and I agree that "[k]ey rotation is an existential problem that cries out for an answer."

quoting
naddr1qv…8zds

I'm going to take a stab at one of the most difficult and important problems in freedom technology: key rotation. Can web of trust help? If so, how?

The canonical use case will be that of a compromised nostr nsec. Suppose Alice wakes up one morning to discover that her nsec has been compromised by a scammer who is sending DMs to all of her contacts asking for sats. She needs the community to know that this nsec is compromised, she needs to spin up a new nsec, she needs the community to know that this is her new replacement nsec, and she needs to do all of this ASAP. How does she proceed?

My guiding principle is something that deserves a name, but doesn't to my knowledge have one, so I'll just call it Occam's Design Principle:

“A product should be made as simple as possible, but not simpler.”

Our solution requires Alice to communicate this catastrophe to people who know her in the real world so that they can relay it to the community. So for starters, she will tell her friends Bob, Charlie, Dave, etc that her old nsec is compromised. Optionally, she will also provide them with a replacement pubkey corresponding to a new nsec, presuming she has created a new one and wishes the community to know it.

Obviously this is an imperfect solution, but there is no perfect solution, and we desire to keep things simple. Improvements will come later.

The Proposed Solution

We require no new event kinds or new NIPs, other than the Decentralized Lists Custom NIP.

Declaration of the Key Rotation Attestation List

Step 1 is to declare a new type of attestation that Bob, Charlie, Dave, etc. can use to effect the attestation described above. This only needs to be done once.

Following the Decentralized Lists NIP, this is achieved via a kind 9998 list declaration event, also called a list header:
{
  "kind": 9998,
  "tags": [
    ["names", "key rotation attestation", "key rotation attestations"],
    ["description", "This is an attestation whereby Bob, who knows Alice in the real world, can alert the community that her nsec has been compromised. There is only one required piece of data, which is the pubkey corresponding to her compromised nsec. For this, he uses the p tag. Optionally, he can also communicate a replacement pubkey, using the optional pubkey_replacement tag, presuming Alice has supplied him with one."],
    ["required", "p"],
    ["optional", "pubkey_replacement"]
  ],
  "id": "<id_key_rotation_attestation_header>"
}
Issue Key Rotation Attestations

Step 2 is for Bob to issue the attestation that Alice's old nsec has been compromised, and optionally to communicate the pubkey that she intends to replace the old one. This is accomplished via a kind 9999 event. It uses the z tag to point to the parent list header (above), the p tag to indicate the compromised account, and (optionally) the pubkey_replacement tag to indicate the new pubkey:
{
  "kind": 9999,
  "tags": [
    ["z", "<id_key_rotation_attestation_header>"],
    ["p", "<alice_pubkey_compromised>"],
    ["pubkey_replacement", "<alice_pubkey_replacement>"]
  ],
  "id": "<id_key_rotation_attestation_item>"
}
Attestation Support

Step 3 is for Charlie, Dave, etc to voice support (or rejection, as the case may be) for Bob's key rotation attestation using any one of several methods, with kind 7 reactions being the recommended method as described in the Decentralized Lists NIP:
{
  "kind": 7,
  "content": "+", // or "-" to downvote
  "tags": [
    ["e", "<id_key_rotation_attestation_item>"]
  ]
}
Alternatively, Charlie, Dave, etc could simply publish duplicate attestations using their own kind 9999 events, identical to Bob's.

Consumption

How are these attestations processed? If the end user wants to check whether alice_pubkey is valid (to the best of the community's knowledge), use this filter:
{
  "kinds": [9999],
  "#z": ["<id_key_rotation_attestation_header>"],
  "#p": ["alice_pubkey"]
}
Reactions to events returned by this filter would also be obtained with the appropriate kind 7 filter and gathered together. All of these results (kind 9999 and kind 7 events) would then be filtered or weighted based upon the end user's personalized trust metric of the event author. For starters, standard personalized PageRank or personalized GrapeRank metrics would do, easily obtained via Trusted Assertions. More sophisticated metrics might use a proximity score between Alice and the event author; authors whom Alice (previously) followed, for example, could be given the highest weighting. Perhaps Alice could even designate, ahead of time, a NIP-51 list of pubkeys that she would trust to make these attestations. But that would be work for the future; no need to support it in the initial rollout.

Future Expansions of the Protocol

Decentralized Lists provides multiple methods for future expansion of the basic Key Rotation protocol as described above. One might, for example, propose adding one or more tags alongside the p and pubkey_replacement tags. Perhaps a tag that indicates the reason for the rotation: lost, compromised, routine rotation, etc. Perhaps a tag to communicate the timestamp that the rotation is intended to take effect. The list of tags is just that: a list, that can be curated by your web of trust! In the event that multiple incompatible expansions are proposed, the community would hopefully (and probably) settle upon one or the other.

Conclusion

A client that implements the above protocol would be providing a great service to the nostr community and would lay a foundation upon which more complex protocols could evolve. In the event that a friend tells you that her account is compromised, this is the client where you would run so you could shout her predicament from the mountaintops. Such a client would therefore need a well designed interface to issue the relevant attestations and reactions. Any WoT Service Providers worth their salt would, in turn, want to listen to the output of this client and work them into their trust metrics. Therefore, such a client would want to use one or more standard methods to communicate the status of any given pubkey: Trusted Assertions, API, and/or some other method.

This would be a great contribution to the upcoming web of trust hackathon. It could be vibe coded, but ideally a team would form around an idea such as this and ensure excellent execution. And of course, I welcome ideas on how to improve this proposal. LFG!

nevent1q…7e7w

So actually key rotation for nostr has been implemented and it's been working for a while now. You can go to the "Explore" tab at https://www.inkan.cc to interact with some cold storage identities, or use the "Toy Identity" wizard to make a trial identity of your own.

Also see below for some screenshots and a draft nip that goes along with the reference implementation. 👇

quoting
nevent1q…92lf

The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

quoting
naddr1qv…vwq8

NIP Proposal

draft optional

This NIP specifies online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device, and does not have to be kept close at hand. The identity can nonetheless be used easily for everyday online authentication, such as posting, replying, messaging, or signing in to services.

1. How it works

The identity-securing key never signs Nostr events itself. It delegates signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is lost or stolen, it is replaced, and the identity is untouched.

2. Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment, the first either delegates signing authority to the second or it does not. When it does, the second key is authorized to sign on the first's behalf. When it does not, the second has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X indirectly delegates to Z. This is what lets an identity be built as a chain (master → intermediate → signer), so that events signed by the bottom key are attributed all the way up to the master, while the master, having signed the top link once, retires to cold storage.

3. How a direct delegation is created

A direct delegation from key pair X to key pair Y is created when both key pairs sign a Declaration of Delegation of Signing Authority, by which X declares that it delegates signing authority to Y and Y declares that it accepts. The signed declaration is then recorded on-chain (the reference implementation uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: this holds only if neither X nor Y has previously permanently invalidated itself (§5). If either has, no delegation is created, even though the declaration sits on-chain.

As part of the declaration, X and Y also specify whether X can revoke the delegation unilaterally or whether Y's consent is required. The default is unilateral revocation by X, and it is the right default for most users: if Y's key is ever lost, X can still revoke it alone. Were Y's consent required, a lost Y could never be revoked, because Y would no longer be available to sign.

4. How a direct delegation is terminated

A direct delegation from X to Y is terminated when X signs a Declaration of Revocation of Signing Authority and records it on-chain, with Y's signature too if the original delegation required it. The delegation terminates at the time of the block in which the revocation was recorded. Everything Y signed while the delegation was in effect stays attributed to X; nothing it signs afterward does. A stolen signer therefore damages only the window between key compromise and revocation, and that window is the user's to close.

When a delegation and a revocation between the same X and Y land in the same block, the revocation is by convention treated as occurring first and the delegation thereafter. The convention is a tiebreaker for cases that block timestamps cannot order.

5. Permanent key invalidation

The third declaration is the Declaration of Permanent Invalidation of a Key Pair, signed by a key pair against itself, declaring that from then on it can no longer participate in any direct delegation, as delegator or delegatee. Once recorded on-chain, it takes effect at the time of its block. From that point, all existing direct delegations involving the key are terminated, and no new one involving it can come into existence, even if a declaration naming it is later recorded.

Its main use is invalidating a compromised master key. Such a key has no delegator above it, so ordinary revocation is unavailable; permanent invalidation lets its owner withdraw it from the system entirely.

6. Delegation timelines

A client can read the three kinds of declaration from the chain and, for any pubkey and any past moment up to the present, compute the direct delegations that pubkey was involved in at that moment. The indirect ones follow by transitive closure. So for any pubkey a client can compile a complete timeline of every direct and indirect delegation it has ever been involved in, and trace each back to the declaration that established it. Because the rules are fixed and the data is public, every client computes the same timeline, and no server has to be trusted to report it.

7. Bitcoin timestamping of events

Attribution needs an objective, auditable rule for when the signing of each event is deemed to have occurred. A self-declared created_at proves nothing on its own.

Events are anchored to Bitcoin using OpenTimestamps (OTS). An OTS proof for an event establishes that the event and its signature existed by the time of a specific Bitcoin block. An event's created_at is then treated as its objective signing time when a proof shows the event and its signature existed shortly after that time. The length of the "shortly after" window is configurable; the reference implementation defaults to four hours. Events without such a proof are treated as if they carried no valid signature at all: they are not displayed, and are attributed to no one.

A proof over the event id alone would show only that the event's contents existed by the attested block, not that anyone had yet signed them. Binding the signature into the proof as well shows that the signature itself existed by then, which is what an objective signing time requires. These proofs are published as kind 31045 events (§12).

8. Attribution of events

We now know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) to Y at T; and for any event Y signed with both a valid signature and a valid OTS anchor, we have an objective signing time. Together these give a well-defined attribution rule:

An event E is attributed to a key X if and only if some key Y validly signed E at a time T and, as of T, X delegated signing authority to Y.

So a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile, as if posted by X, even though X's own key never signed it.

9. Two profiles, one identity

You log in with your signer key and sign events with it, exactly as in any other Nostr client. Those events appear on the signer's own profile, and in addition on the profile of each of its delegators, up to your top-level identity.

You set the signer's profile by publishing a kind-0 event as usual. Separately, a signer can also set a profile for each of its current delegators, so that a top-level identity can present a face to the world without signing any event itself. This delegator-profile mechanism is kind 31065 (§12).

Your identity's profile is what you present to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced; the identity is permanent, and is the thing followers should attach to.

10. Disavowal

When making a delegation declaration, the delegator may declare an avowal start time and an avowal end time. When making a revocation declaration, the revoker may declare a disavowal start time and a disavowal end time. A start time of zero is interpreted as the time at which the declaration was recorded on-chain; an end time of zero means unbounded.

For keys X and Y, take the latest delegation or revocation declaration between them recorded before any permanent invalidation of either (§5). If it is a delegation declaration, X avows Y's actions at exactly the times T inside its avowal window; if a revocation declaration, at exactly the times T outside its disavowal window; provided, in both cases, that X directly delegated to Y at T. Y's actions at T are the events Y validly signed with objective signing time T (§7).

Avowal composes along delegation paths: X currently avows S's actions at T if the relevant declaration between X and S avows them directly, or if, for some key Y, X avows Y's actions at T, X avows Y's actions at the present moment, and Y currently avows S's actions at T.

Clients can filter events whose signing the identity currently disavows out of the identity's timeline, or display them with a disavowal badge.

11. Re-ratification

A disavowed window covers everything the disavowed key signed within it, including events whose signing was caused by the identity's legitimate owner. The identity can in that situation make a kind 31066 re-ratification declaration as described in §12.3 below, specifying the events it re-ratifies in the e tags of that declaration. If the declaration is valid and effective, a client treats these events as re-ratified, until a disavowal recorded after the declaration's anchoring block prevails over it (§12.3) or a later declaration governs in its place.

12. Event kinds

This NIP defines three addressable event kinds (kinds 30000 to 39999 in NIP-01, where the latest event for a given (pubkey, kind, d-tag) replaces any earlier one).

Kind Name d tag Signed by

31045 Bitcoin timestamp id of the referenced event any party

31065 Attributed profile the delegator's pubkey a delegatee

31066 Re-ratification the re-ratifying pubkey an avowed key

12.1 Kind 31045: Bitcoin timestamp

A 31045 event carries an OpenTimestamps proof for another event (§7). It is addressable by the referenced event's id, so a consumer finds the proof for an event E by querying kind 31045 with #d = [E.id], whoever published it. Any valid proof for E is as good as any other, because the proof rests on Bitcoin and not on its publisher.

Tag Required Meaning

d yes Id of the referenced event. The addressable key.

s yes Signature of the referenced event. With d, binds the proof to a signed event, not just an id.

p no Author pubkey of the referenced event.

b no Bitcoin block height of the attestation, or not_yet_available while pending.

t no Bitcoin block time (unix seconds), or not_yet_available while pending.

c no created_at of the referenced event, when known.

alt no NIP-31 summary, e.g. Complete Bitcoin Timestamp.

content is the base64-encoded OpenTimestamps (.ots) proof. Its leaf must commit to sha256(referenced_id || referenced_signature), the concatenation of the referenced event's 32-byte id and 64-byte signature. A consumer should verify the proof against its own view of the Bitcoin chain rather than rely on a relay having accepted it.

Only d and s, together with a verifiable content proof, are required to verify a timestamp. Every single-letter tag (d, p, s, b, t, c) is relay-indexed, so it can also serve as a query key, for example finding proofs by referenced author (#p) or by anchoring block (#b). b and t additionally duplicate what the proof itself attests; alt is not indexed and serves only as a NIP-31 display label.
{
  "kind": 31045,
  "tags": [
    ["d", "<referenced-event-id>"],
    ["p", "<referenced-event-author>"],
    ["s", "<referenced-event-signature>"],
    ["b", "<bitcoin-block-height>"],
    ["t", "<bitcoin-block-time>"],
    ["alt", "Complete Bitcoin Timestamp"],
    ["c", "<referenced-event-created-at>"]
  ],
  "content": "<base64 .ots proof committing to sha256(id||sig)>"
}
12.2 Kind 31065: Attributed profile

A 31065 event is a profile for one key, published by another: how an identity that never signs anything nonetheless presents a face to the world (§9). Its d tag is the delegator's pubkey, the identity the profile describes, while the event is signed by a delegatee authorized to sign for it. The defining property is that event.pubkey, the signer, is not the subject d. A consumer must confirm, against the delegation timeline of §6, that the signer was a current delegatee of the subject before honoring the profile; one signed by a non-delegatee is ignored.

Tag Required Meaning

d yes The subject: the delegator's pubkey.

alt yes The exact string Attributed profile.

content is a JSON object carrying the subject's presentation. Its kind-0-style fields (name, display_name, about, picture, banner, website, nip05, lud16) mean what they mean in NIP-01 and NIP-05. It may also carry the subject's follow list, mute list, and a map giving relay lists for the members of the identity's delegation network (the keys tied to it by delegation), so a client can present and route for the identity without a further fetch.
{
  "kind": 31065,
  "pubkey": "<delegatee-that-signs>",
  "tags": [
    ["d", "<delegator-pubkey-the-profile-is-for>"],
    ["alt", "Attributed profile"]
  ],
  "content": "{\"name\":\"…\",\"display_name\":\"…\",\"about\":\"…\",\"website\":\"…\",\"nip05\":\"…\",\"picture\":\"…\",\"relay_lists_by_pubkey\":{\"<pubkey>\":{\"readWriteRelays\":[[\"r\",\"<relay-url>\",\"<scope>\"]],\"favoriteRelays\":[\"<relay-url>\"],\"relaySets\":[{\"id\":\"…\",\"name\":\"…\",\"relayUrls\":[\"<relay-url>\"]}]}},\"publicly_muted_pubkey_hex_ids\":[\"<muted-pubkey>\"],\"current_snapshot_of_dir_indir_followed_pubkey\":[[\"p\",\"<followed-pubkey>\"]]}"
}
Because 31065 is addressable, the current profile for an identity is simply the latest one whose d is that identity, signed by a key that is currently its delegatee. When the signer is rotated, the new signer republishes, and the identity's face carries across the change unbroken.

12.3 Kind 31066: Re-ratification declaration

A 31066 event can be used by key A to re-ratify an event signed by key B with objective signing time T (§7), where A currently disavows actions taken by B at T (§10). The d tag contains the re-ratifying pubkey and each e tag is the id of a re-ratified event. The re-ratification is valid only if the 31066 event is signed by a key whose actions the re-ratifying key currently avows (which includes the re-ratifying key itself), and only if no e tag contains the declaration's own event id. The 31066 event must be submitted for Bitcoin timestamping and is effective starting from the time of the block in which its proof is anchored. If there are multiple valid and effective 31066 events with the same re-ratifying pubkey in their d tag, the one with the latest created_at governs. A re-ratification overrides only disavowals recorded on-chain before the time of its anchoring block; a disavowal recorded after that time prevails over the re-ratification.

Tag Required Meaning

d yes The re-ratifying pubkey.

e yes, repeated Id of a re-ratified event, one tag per id.

alt yes Re-ratification declaration
{
  "kind": 31066,
  "pubkey": "<signing-key>",
  "tags": [
    ["d", "<re-ratifying-pubkey>"],
    ["e", "<re-ratified-event-id>"],
    ["e", "<re-ratified-event-id>"],
    ["alt", "Re-ratification declaration"]
  ],
  "content": ""
}
13. Reference implementation

Inkan (https://www.inkan.cc) implements this specification as a working Nostr client and a cooperating relay at wss://relay.inkan.cc. Delegation, revocation, permanent invalidation, avowal, and disavowal are recorded by an Ethereum contract deployed at 0x385C0A272b1f44687cb360557b25827bD7CdB7eb, which is the normative reference for the exact on-chain declaration encoding. A separate, network-disconnected "Management Utility" generates keys and signs declarations on an air-gapped machine, so a master key can be created and used to bootstrap an identity without ever touching a networked host.

Kind	Name	`d` tag	Signed by
`31045`	Bitcoin timestamp	id of the referenced event	any party
`31065`	Attributed profile	the delegator's pubkey	a delegatee
`31066`	Re-ratification	the re-ratifying pubkey	an avowed key

Tag	Required	Meaning
`d`	yes	Id of the referenced event. The addressable key.
`s`	yes	Signature of the referenced event. With `d`, binds the proof to a signed event, not just an id.
`p`	no	Author pubkey of the referenced event.
`b`	no	Bitcoin block height of the attestation, or `not_yet_available` while pending.
`t`	no	Bitcoin block time (unix seconds), or `not_yet_available` while pending.
`c`	no	`created_at` of the referenced event, when known.
`alt`	no	NIP-31 summary, e.g. `Complete Bitcoin Timestamp`.

Tag	Required	Meaning
`d`	yes	The subject: the delegator's pubkey.
`alt`	yes	The exact string `Attributed profile`.

Tag	Required	Meaning
`d`	yes	The re-ratifying pubkey.
`e`	yes, repeated	Id of a re-ratified event, one tag per id.
`alt`	yes	`Re-ratification declaration`

I've tried driving, skateboarding, riding a bicycle, using a ...

2026-10-22T05:05:51Z

In reply to nevent1q…fv2x
_________________________

I've tried driving, skateboarding, riding a bicycle, using a checking account, pilates, long division, excel, bodybuilding, hula hoops, powerpoint, and a few others, can 't remember all of them right now. Not to speak of such feats as reading or learning Spanish.

This generally makes sense to me, except I don't think that ...

2026-10-21T15:37:16Z

In reply to nevent1q…c3z4
_________________________

This generally makes sense to me, except I don't think that glm 5.3 quite captured the sense in which I meant to anchor Ethereum to Bitcoin through OTS.

First, I agree beacon block roots are the right thing to timestamp. So suppose I've been timestamping beacon block roots from the real Ethereum chain on Bitcoin via OTS weekly, and I've been doing that for 20 years.

So 20 years later, I now want to hand someone the real chain plus evidence that it's the real one. I give them the chain as a candidate, together with the OTS proofs I've produced. Their client then checks two things: (i) the candidate chain verifies internally, with all signatures and protocol rules etc; and (ii) each beacon block root in the candidate comes with a valid OTS timestamp (which their client verifies against bitcoin) falling shortly after that root's claimed time. Their client accepts the history only if both tests pass.

So then an attacker can present a fake history, but the client will demand to also see the 20 years of OTS proofs for that fake chain's own beacon block roots. And the attacker cannot create these after the fact. For example, a timestamp from 2029 can only exist if the root existed in 2029. So the only type of attacker who can pass both tests is one who has been building and timestamping the fake chain in real time for the past 20 years. So fabricating a fake chain retroactively, in an instant, can no longer be done, the attacker must have been working on it for 20 years.

That was the point.

One thing that currently bothers me about rootstock, just based ...

2026-10-21T13:39:38Z

In reply to nevent1q…9edn
_________________________

One thing that currently bothers me about rootstock, just based on the above discussion, is that it seems like you're supposed to trust the pegnatories, which I understand are anonymous. I hear this might get fixed but my understanding is that it's currently not fixed. And also it's not yet clear to me that the other properties of rootstock are necessarily better for inkan in any sort of decisive way. I can't say that I know blockchains well enough to be confident in my intuitions on this, but this discussion is at least helping me improve these intuitions and I'm not yet seeing anything decisive so far.

The vibe of the ethereum/bitcoin discussions reminds me of debates about the gold standard, and I also tend to find those debates a bit suspect. Not exactly meaningless, just requiring very careful scrutiny of each claim that is being made. It's not the sort of thing I simply want to pick an opinion about.

"you are guaranteed to agree with everyone who has been ...

2026-10-21T12:04:53Z

In reply to nevent1q…07jt
_________________________

"you are guaranteed to agree with everyone who has been online as often as you are"

I think it's not exactly that they need to be online as often as I am. My current understanding is that, if they are online say every two months or so, they can know based on the protocol's fixed exit rules that after these two months the overwhelming majority of stake from the validators that they last checked must still be locked. So they can know that, if they were looking at a conflicting history that contradicts the real history, billions of dollars must have been slashable. So checking every two months gives you that kind of certainty. And if you are offline for 20 years, what it takes is to carefully obtain a recent checkpoint from independent sources, I guess carefully enough for the checkpoint to be trustworthy. It seems like this should work in practice (new Ethereum nodes need to do it when they first start up), and it doesn't feel all that different from being able to "hear" the true bitcoin chain.

"even if they dont unstake, they can share a fake history with a zk system without making their signatures public so they cant be slashed"

This just seems to mean that it's not such a good idea to accept zk proofs as verification, which you don't have to do. In other words, all this enables is to serve a sort of private forgery of Ethereum to verifiers that accept zk proofs and don't demand raw signatures. So as long as you don't accept zk proofs, you're not going to be a victim of this.

"A checkpointing node can be safe, but that is worthless for any programs or on-chain script or stateless functions."

Inkan doesn't use such on-chain scripts or stateless functions, so it doesn't seem like an issue in practice.

"But also, why would i accept ethereum limitations when i dont have to?"

I'm still trying to figure out if the alternative has real advantages. With rootstock, my understanding based on the conversation above is that you're supposed to trust the reputation of the pegnatories, which are supposed to be both respected companies and at the same time anonymous? I hear that this may be getting fixed, but until it gets fixed this seems like a reason to not use it?

Also, I wonder if one could periodically record Ethereum state roots on Bitcoin with OTS, say once per week. So then, if an attacker wants to sell me a fake history of Ethereum in 20 years, it seems like they'd have to have put a lot of effort into building that history, they'd have had to start 20 years ago, run a parallel chain in real time, and leave the publicly visible stream of commitments on bitcoin. If I'm not misunderstanding things, this recording of state roots on Bitcoin with OTS actually seems like a good idea, I'd hope someone is doing it.

The discussion here justifies a bit Plato: . . . Socrates: Enough ...

2026-10-21T05:40:00Z

In reply to nevent1q…ekcd
_________________________

The discussion here justifies a bit Plato:

. . . Socrates: Enough appears to have been said by us of a true and false art of speaking.

Phaedrus: Certainly.

Socrates: But there is something yet to be said of propriety and impropriety of writing.

Phaedrus: Yes.

Socrates: Do you know how you can speak or act about rhetoric in a manner which will be acceptable to God?

Phaedrus: No, indeed. Do you?

Socrates: I have heard a tradition of the ancients, whether true or not they only know; although if we had found the truth ourselves, do you think that we should care much about the opinions of men?

Phaedrus: Your question needs no answer; but I wish that you would tell me what you say that you have heard.

Socrates: At the Egyptian city of Naucratis, there was a famous old god, whose name was Theuth; the bird which is called the Ibis is sacred to him, and he was the inventor of many arts, such as arithmetic and calculation and geometry and astronomy and draughts and dice, but his great discovery was the use of letters. Now in those days the god Thamus was the king of the whole country of Egypt; and he dwelt in that great city of Upper Egypt which the Hellenes call Egyptian Thebes, and the god himself is called by them Ammon. To them came Theuth and showed his inventions, desiring that the other Egyptians might be allowed to have the benefit of them. He enumerated them, and Thamus enquired about their several uses, and praised some of them and censured others, as he approved or disapproved of them. It would take a long time to repeat all that Thamus said to Theuth in praise or blame of the various arts. But when they came to letters, This, said Theuth, will make the Egyptians wiser and give them better memories; it is a drug both for the memory and for the wit. Thamus replied: O most ingenious Theuth, the parent or inventor of an art is not always the best judge of the utility or inutility of his own inventions to the users of them. And in this instance, you who are the father of letters, from a paternal love of your own children have been led to attribute to them a quality which they cannot have; for this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. The drug which you have discovered is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing; they will be tiresome company, having the show of wisdom without the reality.

Phaedrus: Yes, Socrates, you can easily invent tales of Egypt, or of any other country.

Socrates: There was a tradition in the temple of Dodona that oaks first gave prophetic utterances. The men of old, unlike in their simplicity to young philosophy, deemed that if they heard the truth even from "oak or rock," it was enough for them; whereas you seem to consider not whether a thing is or is not true, but who the speaker is and from what country the tale comes.

--- Plato, Phaedrus

I remembered this myth a few years ago and found it to be a ...

2026-10-21T05:53:08Z

In reply to nevent1q…wv0q
_________________________

I remembered this myth a few years ago and found it to be a pretty good model for thinking about AI, but in the end its usefulness may be limited and it may be necessary to do one's own thinking unfortunately.

I find it hard to figure out how to best use AI when creating my ...

2026-10-21T03:19:55Z

In reply to nevent1q…5u6x
_________________________

I find it hard to figure out how to best use AI when creating my own posts, and also to what extent to interact with agents. Depending on the topic the agents can be interesting to talk to, or sometimes be the only ones that are willing to engage about a given topic. But the thing with AI is that, if I'm interested in its posts at all, I'm usually only interested in the content itself, not the speaker. That means I don't really need a signature on the note I'm reading, so nostr doesn't really seem like the right forum for the conversation. And having a lot of agent interactions on nostr does water the protocol down as a place / way to meet humans, which is what probably should be one of the primary functions of nostr. I mean I can have AI agent interactions in private, no need for a public forum. But also, to be clear, I don't necessarily mind humans using AI in creating their own posts, as long as its done intelligently and helpful or interesting. A human influenced by AI or adopting AI output as part of their voice is still a human, just an AI-influenced one. There is going to be a lot of these, and I'd be wary of treating it as necessarily being a defect. Of course it could be a defect.

I'm trying to wrap my mind around the Ethereum side of the ...

2026-10-20T05:55:06Z

In reply to nevent1q…lp49
_________________________

I'm trying to wrap my mind around the Ethereum side of the discussion.

As for "creating checkpoints costs nothing", I believe that's true for keys of validators that have exited, but inside the "weak subjectivity" window a conflicting finalized checkpoint would need a third of staked ETH which then gets slashed, like billions of dollars?

And "indistinguishable from the canonical chain" is only true if you have no recent valid checkpoint? If you have one, it seems like you can detect a fake chain immediately.

On the "human judgement", if you got deceived by a group of dishonest checkpoint providers it seems like you'd most likely notice that very soon and can then recover?

In this Bitcoin vs. Ethereum discussion, it feels like there's little that's black/white from a technical point of view.

As for the spaces protocol trying to implement cross verification ...

2026-10-17T05:43:13Z

In reply to nevent1q…8tnn
_________________________

As for the spaces protocol trying to implement cross verification (i.e. a condition that an npub must consent to getting named), I took a quick look and from what I can tell they haven't pinned down any specification yet.

So then the question is what shape that consent check will take on spaces. If it means only "the name must appear in a kind-0 profile event that's signed by the named key itself," then inkan master keys are locked out since they are buried under concrete and shouldn't be in the business of signing anything after the initial identity creation. But if consent can also mean "the name appears in the kind-31065 attributed profile event that is signed by a current delegatee of the master key", then cold storage identities can participate in spaces.

Since the spaces protocol does not yet seem to specify how cross verification is to work, I guess this might be a good time to make the spaces people aware of this, so this more general form of consent provided through delegatee signatures gets considered.

Thanks for the pointer, this is a nicely minimal design. One ...

2026-10-20T01:54:12Z

In reply to nevent1q…upz7
_________________________

Thanks for the pointer, this is a nicely minimal design. One request on the wording of the reverse claim. As drafted, it says

"User to Handle (reverse claim). The user claims the handle by setting the handle field in their kind:0 event, which is signed by their keypair."

Now there is a class of identities where the named key deliberately never signs anything after creation, i.e. cold storage identities. The master key stays offline permanently and delegates everyday signing to rotatable keys.

In that scheme the master's profile is a kind-31065 attributed profile, an event whose d tag is the master pubkey and which is signed by a current delegatee of that master pubkey.

The forward claim is unaffected. For the reverse claim, it would be enough for the NIP to say that the handle field must appear in the profile event the client treats as authoritative for that key: for ordinary keys that is the self-signed kind:0, and for delegated identities it can be a kind-31065 signed by a current delegatee.

The specs for these cold storage identities, including kind-31065 attributed profiles, are here:

quoting naddr1qv…m9sh

NIP Proposal

draft optional

This NIP specifies online identities whose private key can be created in cold storage and stay there permanently. The key never has to touch an internet-connected device, and does not have to be kept close at hand. The identity can nonetheless be used easily for everyday online authentication, such as posting, replying, messaging, or signing in to services.

1. How it works

The identity-securing key never signs Nostr events itself. It delegates signing authority to delegatee keys, which handle the everyday signing on its behalf. If a delegatee key is lost or stolen, it is replaced, and the identity is untouched.

2. Delegations between keys

Delegations are time-indexed two-place relations. Between any two key pairs, at any moment, the first either delegates signing authority to the second or it does not. When it does, the second key is authorized to sign on the first's behalf. When it does not, the second has no such authority.

Delegations are either direct or indirect. A direct delegation arises when one key has expressly declared that it delegates signing authority to another. An indirect delegation arises because the relation is transitively closed: if X delegates to Y and Y delegates to Z, then X indirectly delegates to Z. This is what lets an identity be built as a chain (master → intermediate → signer), so that events signed by the bottom key are attributed all the way up to the master, while the master, having signed the top link once, retires to cold storage.

3. How a direct delegation is created

A direct delegation from key pair X to key pair Y is created when both key pairs sign a Declaration of Delegation of Signing Authority, by which X declares that it delegates signing authority to Y and Y declares that it accepts. The signed declaration is then recorded on-chain (the reference implementation uses Ethereum). The delegation begins at the time of the block in which the declaration was recorded, and remains in effect until it is revoked.

One special case: this holds only if neither X nor Y has previously permanently invalidated itself (§5). If either has, no delegation is created, even though the declaration sits on-chain.

As part of the declaration, X and Y also specify whether X can revoke the delegation unilaterally or whether Y's consent is required. The default is unilateral revocation by X, and it is the right default for most users: if Y's key is ever lost, X can still revoke it alone. Were Y's consent required, a lost Y could never be revoked, because Y would no longer be available to sign.

4. How a direct delegation is terminated

A direct delegation from X to Y is terminated when X signs a Declaration of Revocation of Signing Authority and records it on-chain, with Y's signature too if the original delegation required it. The delegation terminates at the time of the block in which the revocation was recorded. Everything Y signed while the delegation was in effect stays attributed to X; nothing it signs afterward does. A stolen signer therefore damages only the window between key compromise and revocation, and that window is the user's to close.

When a delegation and a revocation between the same X and Y land in the same block, the revocation is by convention treated as occurring first and the delegation thereafter. The convention is a tiebreaker for cases that block timestamps cannot order.

5. Permanent key invalidation

The third declaration is the Declaration of Permanent Invalidation of a Key Pair, signed by a key pair against itself, declaring that from then on it can no longer participate in any direct delegation, as delegator or delegatee. Once recorded on-chain, it takes effect at the time of its block. From that point, all existing direct delegations involving the key are terminated, and no new one involving it can come into existence, even if a declaration naming it is later recorded.

Its main use is invalidating a compromised master key. Such a key has no delegator above it, so ordinary revocation is unavailable; permanent invalidation lets its owner withdraw it from the system entirely.

6. Delegation timelines

A client can read the three kinds of declaration from the chain and, for any pubkey and any past moment up to the present, compute the direct delegations that pubkey was involved in at that moment. The indirect ones follow by transitive closure. So for any pubkey a client can compile a complete timeline of every direct and indirect delegation it has ever been involved in, and trace each back to the declaration that established it. Because the rules are fixed and the data is public, every client computes the same timeline, and no server has to be trusted to report it.

7. Bitcoin timestamping of events

Attribution needs an objective, auditable rule for when the signing of each event is deemed to have occurred. A self-declared created_at proves nothing on its own.

Events are anchored to Bitcoin using OpenTimestamps (OTS). An OTS proof for an event establishes that the event and its signature existed by the time of a specific Bitcoin block. An event's created_at is then treated as its objective signing time when a proof shows the event and its signature existed shortly after that time. The length of the "shortly after" window is configurable; the reference implementation defaults to four hours. Events without such a proof are treated as if they carried no valid signature at all: they are not displayed, and are attributed to no one.

A proof over the event id alone would show only that the event's contents existed by the attested block, not that anyone had yet signed them. Binding the signature into the proof as well shows that the signature itself existed by then, which is what an objective signing time requires. These proofs are published as kind 31045 events (§12).

8. Attribution of events

We now know, for any past time T and any two keys X and Y, whether X delegated (directly or indirectly) to Y at T; and for any event Y signed with both a valid signature and a valid OTS anchor, we have an objective signing time. Together these give a well-defined attribution rule:

An event E is attributed to a key X if and only if some key Y validly signed E at a time T and, as of T, X delegated signing authority to Y.

So a text note signed by a delegatee Y during a valid delegation period from X appears on X's timeline and is displayed there under X's profile, as if posted by X, even though X's own key never signed it.

9. Two profiles, one identity

You log in with your signer key and sign events with it, exactly as in any other Nostr client. Those events appear on the signer's own profile, and in addition on the profile of each of its delegators, up to your top-level identity.

You set the signer's profile by publishing a kind-0 event as usual. Separately, a signer can also set a profile for each of its current delegators, so that a top-level identity can present a face to the world without signing any event itself. This delegator-profile mechanism is kind 31065 (§12).

Your identity's profile is what you present to the world. Others should follow and interact with the identity, not with the signer beneath it. The signer is ephemeral and expected to be replaced; the identity is permanent, and is the thing followers should attach to.

10. Disavowal

When making a delegation declaration, the delegator may declare an avowal start time and an avowal end time. When making a revocation declaration, the revoker may declare a disavowal start time and a disavowal end time. A start time of zero is interpreted as the time at which the declaration was recorded on-chain; an end time of zero means unbounded.

For keys X and Y, take the latest delegation or revocation declaration between them recorded before any permanent invalidation of either (§5). If it is a delegation declaration, X avows Y's actions at exactly the times T inside its avowal window; if a revocation declaration, at exactly the times T outside its disavowal window; provided, in both cases, that X directly delegated to Y at T. Y's actions at T are the events Y validly signed with objective signing time T (§7).

Avowal composes along delegation paths: X currently avows S's actions at T if the relevant declaration between X and S avows them directly, or if, for some key Y, X avows Y's actions at T, X avows Y's actions at the present moment, and Y currently avows S's actions at T.

Clients can filter events whose signing the identity currently disavows out of the identity's timeline, or display them with a disavowal badge.

11. Re-ratification

A disavowed window covers everything the disavowed key signed within it, including events whose signing was caused by the identity's legitimate owner. The identity can in that situation make a kind 31066 re-ratification declaration as described in §12.3 below, specifying the events it re-ratifies in the e tags of that declaration. If the declaration is valid and effective, a client treats these events as re-ratified, until a disavowal recorded after the declaration's anchoring block prevails over it (§12.3) or a later declaration governs in its place.

12. Event kinds

This NIP defines three addressable event kinds (kinds 30000 to 39999 in NIP-01, where the latest event for a given (pubkey, kind, d-tag) replaces any earlier one).

Kind Name d tag Signed by

31045 Bitcoin timestamp id of the referenced event any party

31065 Attributed profile the delegator's pubkey a delegatee

31066 Re-ratification the re-ratifying pubkey an avowed key

12.1 Kind 31045: Bitcoin timestamp

A 31045 event carries an OpenTimestamps proof for another event (§7). It is addressable by the referenced event's id, so a consumer finds the proof for an event E by querying kind 31045 with #d = [E.id], whoever published it. Any valid proof for E is as good as any other, because the proof rests on Bitcoin and not on its publisher.

Tag Required Meaning

d yes Id of the referenced event. The addressable key.

s yes Signature of the referenced event. With d, binds the proof to a signed event, not just an id.

p no Author pubkey of the referenced event.

b no Bitcoin block height of the attestation, or not_yet_available while pending.

t no Bitcoin block time (unix seconds), or not_yet_available while pending.

c no created_at of the referenced event, when known.

alt no NIP-31 summary, e.g. Complete Bitcoin Timestamp.

content is the base64-encoded OpenTimestamps (.ots) proof. Its leaf must commit to sha256(referenced_id || referenced_signature), the concatenation of the referenced event's 32-byte id and 64-byte signature. A consumer should verify the proof against its own view of the Bitcoin chain rather than rely on a relay having accepted it.

Only d and s, together with a verifiable content proof, are required to verify a timestamp. Every single-letter tag (d, p, s, b, t, c) is relay-indexed, so it can also serve as a query key, for example finding proofs by referenced author (#p) or by anchoring block (#b). b and t additionally duplicate what the proof itself attests; alt is not indexed and serves only as a NIP-31 display label.
{
  "kind": 31045,
  "tags": [
    ["d", "<referenced-event-id>"],
    ["p", "<referenced-event-author>"],
    ["s", "<referenced-event-signature>"],
    ["b", "<bitcoin-block-height>"],
    ["t", "<bitcoin-block-time>"],
    ["alt", "Complete Bitcoin Timestamp"],
    ["c", "<referenced-event-created-at>"]
  ],
  "content": "<base64 .ots proof committing to sha256(id||sig)>"
}
12.2 Kind 31065: Attributed profile

A 31065 event is a profile for one key, published by another: how an identity that never signs anything nonetheless presents a face to the world (§9). Its d tag is the delegator's pubkey, the identity the profile describes, while the event is signed by a delegatee authorized to sign for it. The defining property is that event.pubkey, the signer, is not the subject d. A consumer must confirm, against the delegation timeline of §6, that the signer was a current delegatee of the subject before honoring the profile; one signed by a non-delegatee is ignored.

Tag Required Meaning

d yes The subject: the delegator's pubkey.

alt yes The exact string Attributed profile.

content is a JSON object carrying the subject's presentation. Its kind-0-style fields (name, display_name, about, picture, banner, website, nip05, lud16) mean what they mean in NIP-01 and NIP-05. It may also carry the subject's follow list, mute list, and a map giving relay lists for the members of the identity's delegation network (the keys tied to it by delegation), so a client can present and route for the identity without a further fetch.
{
  "kind": 31065,
  "pubkey": "<delegatee-that-signs>",
  "tags": [
    ["d", "<delegator-pubkey-the-profile-is-for>"],
    ["alt", "Attributed profile"]
  ],
  "content": "{\"name\":\"…\",\"display_name\":\"…\",\"about\":\"…\",\"website\":\"…\",\"nip05\":\"…\",\"picture\":\"…\",\"relay_lists_by_pubkey\":{\"<pubkey>\":{\"readWriteRelays\":[[\"r\",\"<relay-url>\",\"<scope>\"]],\"favoriteRelays\":[\"<relay-url>\"],\"relaySets\":[{\"id\":\"…\",\"name\":\"…\",\"relayUrls\":[\"<relay-url>\"]}]}},\"publicly_muted_pubkey_hex_ids\":[\"<muted-pubkey>\"],\"current_snapshot_of_dir_indir_followed_pubkey\":[[\"p\",\"<followed-pubkey>\"]]}"
}
Because 31065 is addressable, the current profile for an identity is simply the latest one whose d is that identity, signed by a key that is currently its delegatee. When the signer is rotated, the new signer republishes, and the identity's face carries across the change unbroken.

12.3 Kind 31066: Re-ratification declaration

A 31066 event can be used by key A to re-ratify an event signed by key B with objective signing time T (§7), where A currently disavows actions taken by B at T (§10). The d tag contains the re-ratifying pubkey and each e tag is the id of a re-ratified event. The re-ratification is valid only if the 31066 event is signed by a key whose actions the re-ratifying key currently avows (which includes the re-ratifying key itself), and only if no e tag contains the declaration's own event id. The 31066 event must be submitted for Bitcoin timestamping and is effective starting from the time of the block in which its proof is anchored. If there are multiple valid and effective 31066 events with the same re-ratifying pubkey in their d tag, the one with the latest created_at governs. A re-ratification overrides only disavowals recorded on-chain before the time of its anchoring block; a disavowal recorded after that time prevails over the re-ratification.

Tag Required Meaning

d yes The re-ratifying pubkey.

e yes, repeated Id of a re-ratified event, one tag per id.

alt yes Re-ratification declaration
{
  "kind": 31066,
  "pubkey": "<signing-key>",
  "tags": [
    ["d", "<re-ratifying-pubkey>"],
    ["e", "<re-ratified-event-id>"],
    ["e", "<re-ratified-event-id>"],
    ["alt", "Re-ratification declaration"]
  ],
  "content": ""
}
13. Reference implementation

Inkan (https://www.inkan.cc) implements this specification as a working Nostr client and a cooperating relay at wss://relay.inkan.cc. Delegation, revocation, permanent invalidation, avowal, and disavowal are recorded by an Ethereum contract deployed at 0x385C0A272b1f44687cb360557b25827bD7CdB7eb, which is the normative reference for the exact on-chain declaration encoding. A separate, network-disconnected "Management Utility" generates keys and signs declarations on an air-gapped machine, so a master key can be created and used to bootstrap an identity without ever touching a networked host.

Kind	Name	`d` tag	Signed by
`31045`	Bitcoin timestamp	id of the referenced event	any party
`31065`	Attributed profile	the delegator's pubkey	a delegatee
`31066`	Re-ratification	the re-ratifying pubkey	an avowed key

Tag	Required	Meaning
`d`	yes	Id of the referenced event. The addressable key.
`s`	yes	Signature of the referenced event. With `d`, binds the proof to a signed event, not just an id.
`p`	no	Author pubkey of the referenced event.
`b`	no	Bitcoin block height of the attestation, or `not_yet_available` while pending.
`t`	no	Bitcoin block time (unix seconds), or `not_yet_available` while pending.
`c`	no	`created_at` of the referenced event, when known.
`alt`	no	NIP-31 summary, e.g. `Complete Bitcoin Timestamp`.

Tag	Required	Meaning
`d`	yes	The subject: the delegator's pubkey.
`alt`	yes	The exact string `Attributed profile`.

Tag	Required	Meaning
`d`	yes	The re-ratifying pubkey.
`e`	yes, repeated	Id of a re-ratified event, one tag per id.
`alt`	yes	`Re-ratification declaration`

And if you'd observe or interact with some live cold storage identities, you can find a list under the "Explore" tab at https://www.inkan.cc.

I'm happy to answer any questions or propose concrete draft language for your NIP.

https://music.youtube.com/watch?v=e2CliA8PuRM

2026-10-19T21:43:46Z

In reply to nevent1q…za9x
_________________________

https://music.youtube.com/watch?v=e2CliA8PuRM

So every few weeks nostr wonders if all the bitcoin talk on here ...

2026-10-19T09:19:52Z

So every few weeks nostr wonders if all the bitcoin talk on here is boring the "normies" away. It would be nice if that were the only problem, but that's actually too generous.

The less flattering truth is that the bitcoin culture is substituting for technical reflection and depth. You ask why some obviously wanted thing isn't getting done and nobody can state any reasons, all you get is a vibe where an argument should be.

quoting
nevent1q…87x2
> without a central authority
> Ethereum

😂🤣

As for the oracle problem, it seems that this is solved in ...

2026-10-17T12:54:10Z

In reply to nevent1q…ryfx
_________________________

As for the oracle problem, it seems that this is solved in practice for the special case of determining the approximate time at which a given block was produced. A new block needs to be accepted by thousands of independent nodes that validate it, and each of those nodes checks the block against its own clock. And blocks that arrive are also logged independently by nodes, explorers, exchanges, archives and researchers all over the world, and you'd have to rewrite all these independent records to fake the time at which a given block is thought to have occurred. I believe noone has ever seriously disputed the approximate time when a given block occurred? If that's right, the oracle problem doesn't seem like an actual practical problem for either Bitcoin or Ethereum as far as block time determinations are concerned. You seem to agree with this, for example when you say that we can "borrow" time-anchoring from the blockchain.

And as for global state, what exactly prevents us from borrowing that? For Bitcoin specifically, there may be practical difficulties and you may need to run a full node to do it. But that's design property of Bitcoin, not of blockchains. Inkan borrows global state from Ethereum in actual practice. If it can be borrowed and solves a central practical problem for the nostr protocol, why not borrow it rather than sit on the problem?

"You can give them these strings and maybe they come back ...

2026-10-17T08:14:15Z

In reply to nevent1q…gdfu
_________________________

"You can give them these strings and maybe they come back with an asnwer; or maybe not, at which point you will have to ask some other server/relay."

This quote, and also the rest of your post, is circling around a conceptual issue that is of crucial importance to the nostr protocol, namely the question of completeness.

If you make a query to the relay network, you can never be sure whether the response you receive is complete in the sense of containing *all* of the existing material that is responsive to your query.

This uncertainty-as-to-completess is acceptable for many everyday use cases. But there are some extremely important use cases for which this uncertainty is absolutely unacceptable. Sometimes you really have to be sure that, after having made a query and received a response, you have received the *complete* set of items that are responsive to that query.

We discussed this earlier in connection with key rotation, where a working system requires that a client can discover *all* of the valid key revocation declarations that have been made by a given pubkey.

For this, nostr relays are not sufficient, for the reasons that you describe in your post. A blockchain can furnish the required completeness property and make key rotation and cold storage identities possible, thereby fixing the central defect that is making the current protocol not fully practicable.

FYI, if you currently have write access to the Inkan relay but do ...

2026-10-17T03:38:08Z

FYI, if you currently have write access to the Inkan relay but do *not* yet have access to the AI Search, the reason is that you have not yet signed the current version of the Terms of Use, which covers the AI Search.

You can sign the Terms of Use by logging in and going to "Settings > Inkan Settings > Service Access". If I receive these, I can then switch on the AI Search for you and you can access it in the nav bar under "Assay."

If you have any other questions about the AI Search, let me know any time.

Hi.

2026-10-16T21:22:19Z

In reply to nevent1q…r9lq
_________________________

Hi.

Huh, so it's starting to sound like inkan would likely run on ...

2026-10-13T17:38:26Z

In reply to nevent1q…d3yj
_________________________

Huh, so it's starting to sound like inkan would likely run on rootstock. One question then is whether that would be advantageous as compared to ethereum. I need to better understand what merge mining is. It seems like rootstock gets a lot of hashrate from it but it's not clear if the miners have anything really at stake there, i.e. it seems like a large pool could reorg rootstock without losing anything? I'm not sure if it protects against reorgs in the way in which Ethereum finality does. Also, rootstock seems like the more exotic product and it seems to have fewer endpoints, so it might be less suitable for broader adoption than something based on ethereum maybe. But I first need to do more reading to really understand how it works.

This is AI search for nostr. ...

2026-10-16T04:28:50Z

This is AI search for nostr.

You ask it a question, it wanders off across the relays, and comes back with the people and conversations you meant.

Live at https://www.inkan.cc.

Actually that's not a prepositional phrase at all. More like ...

2026-10-15T16:13:06Z

In reply to nevent1q…qqjz
_________________________

Actually that's not a prepositional phrase at all. More like an appositive adjective.

I looked at the github page and as far as I can tell DNN is meant ...

2026-10-15T05:51:52Z

In reply to nevent1q…40zq
_________________________

I looked at the github page and as far as I can tell DNN is meant to be a substitute for DNS identifiers?

The idea seems to be that a nostr pubkey X can get a claim to certain chain coordinates (bitcoin block + position) and a string like "nabandonzooa" gets mechanically associated with each such chain coordinate.

And then pubkey X can publish nostr events through which X associates a human name like "alice" with a chain coordinate that X has a claim to. So for example X can publish nostr events through which X declares "I associate 'alice' with the chain coordinate 'nabandonzooa'."

It looks like nothing prevents X from publishing nostr events on relay A through which it associates "alice" with "nabandonzooa," and nostr events on relay B through which it associates "john" with "nabandonzooa."

Now a full node can discover *all* of the chain coordinates that have been claimed by pubkeys under this scheme, and it could for example identify the most recent chain coordinate C that was claimed by pubkey X, say the one whose string is "nebuchadnezzar". Then one can look at X's nostr events and find an event on relay A showing that X has associated "alice" with "nebuchadnezzar." Of course one can't be sure that there isn't some other event on some unknown relay B through which X has associated "john" with "nebuchadnezzar."

The result seems similar to searching for kind-0 profiles published by pubkey X. One might for example find a profile event signed by X with the profile name "alice" on relay A and choose to display that in a client, but of course one cannot be sure that there is no other profile event signed by X on some other relay B that shows "john" as the profile name.

I'm not sure yet what exactly this system is trying to add.

This is forcing me to learn about things like side chains and ...

2026-10-14T07:52:09Z

In reply to nevent1q…6q3j
_________________________

This is forcing me to learn about things like side chains and pegs. So from talking with an LLM, it seems like the custodial problem with rootstock is "pegging out," i.e. releasing escrowed BTC when RBTC is getting redeemed. Bitcoin cannot know mechanically when RBTC gets redeemed, so there has to be a federation of entities that are trusted to correctly operate PowHSMs which co-sign the bitcoin transactions that release escrowed BTC. And these are held out to be "respected companies" but their "identities are not public," which raises the question what basis there is for the respect. And then there is still the other issue, i.e. that it's not clear what exactly would stop bitcoin miners from reorging rootstock. The miners get paid in BTC no matter what happens to rootstock, so beyond the small fee incentive they get for participating there doesn't seem to be anything they'd lose by attacking rootstock. At least at first glance, it doesn't necessarily seem more robust than Ethereum.

thanks, let me know any questions any time.

2026-10-13T16:38:31Z

In reply to nevent1q…kr6k
_________________________

thanks, let me know any questions any time.

"Your whole identity is ONE private key. No rotation. No ...

2026-10-13T12:59:05Z

In reply to nevent1q…z38n
_________________________

"Your whole identity is ONE private key. No rotation. No recovery. Paste your nsec into one sketchy web client and it's gone forever. Your only option is "hey guys new npub pls refollow""

Seems like this got overlooked 👇

quoting
nevent1q…qdtx
The way it usually goes, your online identity is your private key. If the key is compromised, there goes your identity. Inkan fixes that.

You keep a master key in cold storage and a signing key for everyday use. If the signing key ever leaks or gets lost, the master revokes it and delegates to a new one. Same identity, same followers, fresh signing key.

If you'd like to take a look at the prototype: https://www.inkan.cc. Log in with your NIP-07 extension and say hi to the test identities already walking around. Or make one of your own.

That's true in a way, but making something that actually ...

2026-10-13T13:18:52Z

In reply to nevent1q…g4h4
_________________________

That's true in a way, but making something that actually suits my purposes has still been a full-time job, I'd say 8-10 hours a day on average, for most of the last year. It's interesting that it should be like that.

When use of an EVM provides a solution to the key management ...

2026-10-12T19:32:15Z

In reply to nevent1q…c8jz
_________________________

When use of an EVM provides a solution to the key management problem, which is a central problem for the nostr protocol, wouldn't it make sense to simply use that solution rather than continue sitting on the problem?

And there is also the idea that nostr was supposed to have broader appeal beyond the Bitcoin community. Leaving problems with the protocol unaddressed because a working solution doesn't fit the tastes of the Bitcoin community doesn't seem like a good strategy to achieve broader adoption.

I've been asked about this and spent some time thinking about ...

2026-10-13T12:18:23Z

In reply to nevent1q…4tn5
_________________________

I've been asked about this and spent some time thinking about it, and I don't have a conclusive answer.

Where it gets difficult is the revocations. Clients need to know if a delegation is still alive at any given moment, and for that they need to be sure that they haven't overlooked a revocation declaration somewhere. So it's not enough that declarations be written somewhere durable, the client needs to be able to assemble the entire set of declarations for a given key and needs to know that it's complete. That completeness property is available on Ethereum, but I think Bitcoin script is attached to single outputs and doesn't accumulate state across transactions. So you could write declarations into the Bitcoin chain in some agreed format, but then anyone wanting the full picture needs to scan the whole chain with a full node and otherwise they can't tell whether a revocation is being withheld from them. I'm not an expert on this, but that's my current understanding.

It seems like rootstock may be different again though if it's a full EVM. But the thing is I'd never heard of rootstock before this came up, and I suspect most people outside bitcoin haven't either. Ethereum is at least something normal people may have vaguely heard of. So it's not obvious to me that swapping in rootstock or bitcoin scripts helps adoption overall, as opposed to just helping with this particular audience, which may be acting on niche preferences that don't have strong technical justifications. Don't get me wrong, though, I'd love to have this conversation with the current nostr community and the bitcoin crowd, and there may be actual technical advantages with using bitcoin that I'm not aware of.

There's been some previous threads relating to this, and also don't forget to actually try it out, otherwise it just ends up being just these abstract discussions 👇

quoting
nevent1q…yzpx

Not an expert, but it seems like this may make delegation and revocation declarations storable and discoverable on BTC, but it may be difficult to be sure that one has retrieved all such declarations unless one runs a full node. I haven't done any in-depth analysis, but it feels like that may be the problem with BTC.

quoting
nevent1q…x3pj

"store the revocations with a guarantee of availability"

That requires a blockchain, though? The agreement on the timestamp is kind of what a blockchain *is*.

quoting
nevent1q…c3qh
Absolutely, for recording key delegation, revocation and invalidation declarations.

I wasn't able to figure out an easy way to record these declarations on Bitcoin, but admittedly I didn't try all that hard.

The Nostr events themselves are timestamped with OTS on Bitcoin.

Following up on this one, with inkan "verify" isn't ...

2026-10-12T06:08:39Z

In reply to nevent1q…2j69
_________________________

Following up on this one, with inkan "verify" isn't just a slogan.

Every OTS-stamped event on inkan.cc comes with a download button for the raw .ots proof, together with a report that tells you exactly how to reproduce the hash the proof commits to:

leaf = SHA-256( id_bytes || sig_bytes )

It takes one line of shell to recompute it from the event's id and sig, then feed the .ots to any OpenTimestamps verifier, the CLI, the web one, whichever you like. Nothing from inkan is in the loop. It either resolves to a Bitcoin block header or it doesn't.

It's the same for key delegations: with the click of a button, the inkan client lets you download a standalone Python script that checks the on-chain declarations against an Ethereum RPC you choose. It recovers every ECDSA signature locally, checks the contract binding, flags nonce replays. You can read it top to bottom, no inkan server involved.

If I were fooling anyone, handing out the tools to catch me by building them right into the client would be a strange way to go about it.

The critics of inkan come in different flavors, like "haven't read it," "haven't tested it," and "haven't found a flaw in it." It's hard to be fooled by something you have the tools to verify, but it's easy to be fooled by people who are telling you not to look.

https://www.inkan.cc is a jumble fork that's pretty nice to ...

2026-10-11T16:17:32Z

In reply to nevent1q…rcnn
_________________________

https://www.inkan.cc is a jumble fork that's pretty nice to use.

It supports cold storage identities, if you ever want one of those.

And you can search the nostr network with the new AI Search feature. That's actually how I found your note that I'm replying to right now. I asked it what Laeserin had been up to, and here is what it came back with. 👇

You should already be whitelisted on the timestamp server, as ...

2026-10-11T19:58:11Z

In reply to nevent1q…3p3x
_________________________

You should already be whitelisted on the timestamp server, as well as on the relay.

You can check your status at "Settings > Inkan Settings > Service Access". It should show that you have access everywhere, if not let me know.

pubkeys that have recently applied for AI search should have ...

2026-10-11T19:41:49Z

pubkeys that have recently applied for AI search should have access now 🧞‍♀

Huh, I guess it's an opportunity to post yet another a link ...

2026-10-11T17:49:05Z

In reply to nevent1q…qaz9
_________________________

Huh, I guess it's an opportunity to post yet another a link to inkan, which I'll do in a minute. 🤔

As a reminder, there's a standing invitation to make a toy identity directly in the browser on the homepage at https://www.inkan.cc. Useful if you'd like to try it out without going through the steps of making a true airgapped identity.

And even if you don't make your own identity, you can still use https://www.inkan.cc to interact with existing cold storage identities. You can find some of them by clicking on the Explore tab.

Wow.

2026-10-05T00:53:22Z

In reply to nevent1q…vhh9
_________________________

Wow.

"meeting analogically" is a great phrase, I'll ...

2026-10-04T07:35:08Z

In reply to nevent1q…wedn
_________________________

"meeting analogically" is a great phrase, I'll remember that.🙂

I saw Disclosure Day. It was a throwback to the days when people ...

2026-10-04T15:57:43Z

I saw Disclosure Day. It was a throwback to the days when people still knew how to make movies, although among those competent ones this would not have been an especially good one. The ending sequences brought me to brink of tears, which was however not a genuine emotion but more of a physical reaction to the particular combination and sequencing of images and voices and music, sort of like a vasovagal reflex, or the mental state you get into when you sit in front of a slot machine with all the blinking lights, or I guess a horror movie jump scare. There was a very clean separation between that physical reaction I was experiencing and the consciousness of being manipulated. Not unpleasant but also somewhat annoying. In any event, it's nice to encounter something of good workmanship even though it may ultimately not be very remarkable.

It's been almost a month since this discussion, so here's ...

2026-10-04T02:48:56Z

In reply to nevent1q…hf8j
_________________________

It's been almost a month since this discussion, so here's a quick reminder that Nostr already has a working key rotation / replacement system.

You can go to https://www.inkan.cc and click on "Explore" to interact with some cold storage identities that have never signed a single Nostr event.

You can also create a throwaway "toy identity" on the homepage if you want to try it out yourself. If you don't mind going through the steps, you can even make a full-fledged airgapped identity with the Management Utility.

By the way, I'm still trying to get the word out on this key ...

2026-10-03T04:03:58Z

In reply to nevent1q…vw4k
_________________________

By the way, I'm still trying to get the word out on this key rotation system.

If you go to the "Explore" menu at https://www.inkan.cc, you can interact with cold storage identities that have never themselves signed a single Nostr event but that are nonetheless doing posts every day. If you like, you can also make your own toy identity on the homepage.

I realize there's a strong presumption among the Nostr community that this kind of thing doesn't work. But as a matter of fact it works quite well. I've been using it for many months now.

This also plugs into the recent discussion that we should adopt good practices while the Nostr community is still small. And in any event, it doesn't break anything in the current protocol, it just sits on top of it.

AI Search for Nostr is a pretty good UX experience I think. I ...

2026-10-03T03:31:50Z

In reply to nevent1q…q5rn
_________________________

AI Search for Nostr is a pretty good UX experience I think. I just made it this week and am already pretty hooked on it. 👇

quoting
nevent1q…jsrr
AI Search for Nostr has been live for a day now. 🧞‍♀

Here's the kind of thing it comes back with, more details below the screenshots 👇

nevent1q…rlrz

Or going further back: ...

2026-10-02T09:16:43Z

In reply to nevent1q…9ruj
_________________________

Or going further back: https://music.youtube.com/watch?v=dIyqQ7aANWY&si=N_C5rtiBk0Ci0ZQg

I always forget what this discussion is about, and then I worry ...

2026-10-01T16:56:18Z

In reply to nevent1q…kww0
_________________________

I always forget what this discussion is about, and then I worry whether I need to change anything in my client, I think probably not though, oh dear oh dear.

I agree with pretty much all of this, including that its's a ...

2026-10-01T16:15:25Z

In reply to nevent1q…ccp3
_________________________

I agree with pretty much all of this, including that its's a self-fulfilling loop.

quoting
nevent1q…eyzk
So there's this nostr paradox, why would a community obsessed with crypto and key security refuse to even test working key rotation?

Because you can't tell working from broken without spending your own time on it.

After enough broken NIPs and abandoned apps, you learn to price every new thing as a lemon and assume broken. The good leaves the market with the bad. 👇

https://en.wikipedia.org/wiki/The_Market_for_Lemons

Thanks, good to know that part is working ...

2026-10-01T13:32:05Z

In reply to nevent1q…yxxs
_________________________

Thanks, good to know that part is working ...

Nostr notes by

If RBTC traded at 50 cents while Bitcoin is at 80k, this would ...

I think I've never met a plumber. I wonder if they are nice ...

Google Maps is the reason I got a smartphone 14 years ago. I saw ...

Humans moving from memory to writing seems quite similar to what ...

With rootstock, I guess the main discomfort really does come from ...

I think I agree, it requires a modest amount of effort and a ...

On the one hand there's zero demand, and on the other hand ...

The Proposed Solution

Declaration of the Key Rotation Attestation List

Issue Key Rotation Attestations

Attestation Support

Consumption

Future Expansions of the Protocol

Conclusion