Last Notes
Huh, I had kind of forgotten about these sites. I never really used them, let alone considered posting anything on them, and this made me remember why.
It also makes me think that we actually have a pretty nice crowd here on current nostr, at least relatively speaking.
And I'm not so worried about the community here turning nasty, not because I think it couldn't ever happen, but because the consequences would be limited.
On sites like reddit, it feels like you are locked into some narrow space with your peers, and there is no escaping or avoiding them. With nostr, because you have your own keys, you can be more of a nomad. When this particular spot doesn't suit you any longer, because there's no shade or for whatever reason, you just take a minute to pack up and move to another one, taking everything you need with you.
It's a very different feel, and it has to do with the underlying structure of the protocol.
Iykyk https://blossom.primal.net/ace720d86adec2ace72537c40e116b74d17cf0fd8b60effe86070b6ad1aecd7e.jpg
With a retrospective disavowal, you have to trust that what they are telling you is true, i.e. that their key was really compromised.
The logical structure of retroactive disavowals is completely different from that of delegations and revocations of signing authority.
A delegation declaration is a speech act that has an immediate automatic effect, i.e. to initialize a delegation relationship between two keys. It's like saying "With this ring I thee wed", which has the effect of initializing a marriage. And a revocation declaration is also a speech act with immediate automatic effect. It terminates the delegation relationship, just like putting a signature on the final divorce papers terminates the marriage. These speech acts are historical events with objective temporal placement, marking the exact beginning and the end of the relationship.
A retroactive disavowal of a signer key is a mere claim about the past, specifically about who used the signer key to sign certain events. You are saying that it wasn't *you* but *someone else* who used the key to sign these past events. This claim may be true or false, others have to look at the circumstances, any relevant evidence and your credibility and decide. This claim about the past does not bring into existence any new delegation relationship, and it does not terminate any delegation relationship.
One reason that Inkan works is that it cleanly separates the logic of delegation and revocation declarations from that of retroactive disavowals.
I agree about signatures.
I think your post was maybe referring to my statement "To trust a self-declared disavowal, you have to trust the *person* behind the master key" ?
What I meant is - suppose a person posts a note that's validly signed by their master key which says:
"My signer key was compromised two weeks ago. Don't trust any notes that were signed by the signer key during the last two weeks, especially the notes saying that I was traveling in Denmark, I did not post these, someone impersonated me!"
Then you have to decide whether or not to trust that the person is telling the truth when they say that that their signer key was compromised and that they did not themselves post the notes saying that they were traveling in Denmark and that someone impersonated them.
That's what makes retroactive disavowals of events *very different* from key revocations. Key revocations are acts that occur at objectively verifiable times, i.e. when they are recorded on-chain. Retroactive disavowals of events are subjective statements that other parties may choose to believe, or not.
Thanks, I guess "fork" and "join" are concepts that apply in the cryptocurrency context, so probably not directly applicable to inkan.
I'm not sure what "it" is in this sentence:
"it's cryptographically identifiable"
Also: If others know and agree on the objective time of the revocation, they can *at least* agree that events that are dated subsequent to that revocation time should not be attributed to the revoker.
They can do so regardless of whether or not they agree on how to handle events that are dated between the self-declared start time of the disavowal and the objective time at which the revocation was recorded.
My primary use case is actually just regular nostr users whose keys can get leaked or lost, basically the same reason everyone wants to be able to reset their X password when it gets stolen. It's nothing too specialized, although the system *can* be used for contracting if one wants to.
And just to note this, a revocation primarily protects *the impersonated person*, not the reader of the revocation. So "just ignoring revocations" means basically "the thief gets to keep posting as you to every client that ignores the revocation."
And for revocations to protect anyone, clients have to be able to find them, and they must agree *when* the revocation happened since the revocation is what separates your own old posts from those of the thief.
I agree, and inkan gives you exactly that functionality.
When you revoke, you can optionally declare a past time starting at which you "disavow" events signed by the key you are revoking ("I consider this key to have been compromised since September 14, don't trust anything signed by it after that date!").
But the design point is that inkan won't allow you to silently rewrite history that others relied on. Everyone can see both (i) when the revocation was actually recorded on-chain and (ii) the past time from which you disavow.
So third parties get the full picture, i.e. these events were validly signed during the delegation, and the author now disavows them. Clients can either hide disavowed events or show them with a disavowal badge.
There's also a re-ratification mechanism that allows you to rescue your our own legitimate events inside a disavowed window. 👇
#nevent1q…krrt
I'm not sure what exactly you mean by "fork" or "join," but inkan's declarations do "join" in the sense that the delegation state at any given time is a function of the total set of past declarations.
But the question whether declarations "fork" or "join" seems in any event orthogonal to the question whether inkan needs consensus. Inkan needs consensus on the relative order of nostr events and revocations. If Bitcoin uses consensus for validating the DAG, that's fine. Inkan just uses the types of consensus it actually needs.
I'm not sure about the "humans" point. Inkan can absolutely issue identities to agents. Neither Bitcoin nor inkan can check that its users are humans.
Regarding the "notary," inkan uses a notary, namely OTS, for the timestamping of nostr events. But a notary is not sufficient for inkan, since a notary can't prove *absence* (e.g "no revocation existed before time T ...").
As for the leak's and revocation's being inherently race that inkan can't eliminate, that's of course true. But a stolen signer can damage only the window between key compromise and revocation. You can also take preventative steps by periodically rotating your signing key preemptively.
"when there is no utxo ... in the data"
But the data that inkan is trying to handle *does* have "utxo." There are two competing artifacts that each is cryptographically valid by itself:
1. A revocation declaration R signed by pubkey X saying "X revokes signing authority from Y"
2. A nostr event E signed by pubkey Y
The "unspent transaction output" is the output of the the delegation transaction that occurred earlier, i.e.:
utxo = the delegation of signing authority from X to Y
Now the revocation transaction R invalidates that delegation, i.e. it consumes / burns the utxo.
At the same time, the transaction consisting of the signing by Y of event E tries to draw on that utxo, i.e. it tries to draw on the delegation relationship to cause E to be attributed to X.
So both the revocation and the signing of the nostr event are trying to "spend" the same utxo, one by burning it and the other by drawing on it.
But this type of utxo can only be "drawn on" when it hasn't yet been "burned." So we need to know in which order these transactions occurred.
Classic double-spend.
I'm not really familiar with these, but are these consensus mechanisms actually designed to prevent cheating / deal with dishonest participants? And when you talk about "partition", do you mean that relays may split into two groups, one that shows the revocation and another that doesn't? In that case, it seems that "partition resistance" would be extremely important. That's precisely the problem, i.e. that an adversary may build a "partition" that withholds all-important information about a key revocation.
[By the way, my comment above should have said "Recording a 5-key inkan identity on Ethereum costs say $0.25 in gas fees, about $0.05 per key." That way the rest of the comment actually makes sense.]
I wonder how a non-blockchain consensus mechanism would work. Would there be a penalty for cheating?
"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*.
That could be, I just don't have the data to compare the economics.
By the way, inkan comes with built-in spam prevention.
Recording a 5-key inkan identity on Ethereum costs say $0.50 in gas fees, about $0.10 per key.
That expense by itself provides a decent signal, maybe comparable to NIP-5.
But it's actually better than that. Say you have a funded spammer who records 500 Inkan identities with 5 keys each, 2500 keys in total, for $125.
That creates a patterns that's public and likely detectable on-chain, for example by tracing gas payments, timing patterns, etc. It's cheap to observe these patterns and flag suspicious pubkeys.
Spammers can try to cover their traces, but that's an additional expense and it's risky. If the pattern is detected, it's not just one of their pubkeys that gets flagged but it's the entire 2500 key blob. So they don't just lose $0.05 per key, but lose their entire $125 investment.
This defense covers LLM spammers that produce content that's hard / impossible to distinguish from humans, at least when someone tries to do it at scale. It's an origin-based defense.
A funded attacker will not be working with a typical 4 core processor but will be renting a larger outfit, so there will be a lot more than 15,000 events.
If the purpose is to protect relays from having to store gazillions of spam events, I guess VDF works to some extent. But PoW also works to some extent. You'd have to compare what can be produced at the same cost, and verification costs, and as far as I know it's not obvious that VDF has an advantage over say Equix.
And from the user's perspective, these 15,000 events of course *pass* the spam filter and are delivered, so users get spammed.
I think the problem may be that verification takes too long for RandomX, even longer for the light than for the heavy variant. So that would allow an attacker to overwhelm a relay verifier with junk proofs that cost nothing to produce. A DoS attack I guess.
Au pied de Gargilesse coule la Creuse, Indre https://blossom.primal.net/0475462930b8e80243527957be9c584fabcdaf514134e16a19f64e5c0c97438d.jpg https://blossom.primal.net/d7a38dae39f202a3e6102746881594b027dfb2fd791bb1ef260420745423e57e.jpg
#coffechain
G☕️M et croquis du jour
https://blossom.primal.net/e0c136ccd240febd4921d66198bf65d3af17814e9ed52bf3451129505433ae4b.jpg
It seems like verification costs might be too high with RandomX?
Ok, so then my understanding is that PoW based on SHA-256 hashes is not effective against an attacker with access to asic.
But then there is
https://github.com/tevador/RandomX
and
https://github.com/tevador/equix
It looks like verification costs for RandomX may be too high for relays, but Equi-X could be useful for nostr?
My real Nostr identity probably has no brainstorm score. Please follow it here, it's the cold storage identity that will survive after my current key is leaked (which is bound to happen sooner or later):
https://www.inkan.cc/users/npub10ukg94kvrvk4qqr3482zdekfsuaw2x56wa899mnpkxqwfxl6dlkqrux0x9
I started looking into this a couple of weeks ago and came away with the impression that there's a huge difference between what a phone or a laptop can mine and what a GPU farm can mine.
If that's right, then with the current mechanism you can prevent casual spammers but cannot stop a funded attacker.
I started looking at https://github.com/tevador/equix but not sure if I'm on the right track here.
#nevent1q…4wwd
Dans le parc du chateau de Gargilesse, Indre
https://blossom.primal.net/7913851d54213d561bc49438b2b9d398c74db03209141eacd59ccfa67b0a2e66.jpg https://blossom.primal.net/3f5b2721f6960050648d62b479f718ac292e4e4bdb4f8496f0b87f24d466c0f1.jpg https://blossom.primal.net/12a3e692bc82d351bf8a29a13cfabc5ee4c45b90862a215afc6d1d8c0b70e7e6.jpg https://blossom.primal.net/fdd4ec8fe78e229ba0f7cbadd8a201d8aa0589dfb5ce16ebe27e4e18afacebdc.jpg
#coffechain
G☕️M et croquis du jour
https://blossom.primal.net/fe5f8465139818dcae9d9038244684345c6f2583d08b64cd79466327f34778b0.jpg
This is *not* skipping Inkan identities!
For example, here is @npub1u28…f93q
https://brainstorm.world/p/npub1u280zakdwcv23nqpgatsmz8lw6aj22aa6gjjlx0d50lqr8m8xucq7kf93q
Superpepa
https://blossom.primal.net/7b6b6d32e66f6c26bce105ae0a62a33ce39dcb4cfc4e93dd9f2fd9d7a8e0040f.jpg
La crytye de l'église de Gargilesse
https://blossom.primal.net/d7489ddc9650b773638f0b0bb4015dbb701d351e1b1de6edf47fbe6ff41511e6.jpg https://blossom.primal.net/ce7c674d18d07fe7d9c1287c46d584d59ac657c358402b3fd1655f1215b5a879.jpg https://blossom.primal.net/61120112e868a5fb0a8dc74e98e3db76be00e6643a15fb0ba523bc3246753725.jpg
If you have relay that's pre-configured / optimized for this purpose and can be installed easily, let me know.
The risk is if your friends collaborate to put enough pieces of your key back together, or if a third party in the future steals a sufficient number of pieces from your friends. If you spread around key material, you lose control over how it's stored, duplicated, not deleted, etc.
Congrats on shipping this. One thought on
"NIP-4e, which separates encryption keys from identity keys"
The hard part is how senders know which encryption key is currently yours, especially how they can know when an old encryption key stopped being yours. Just announcing this through a 10044 doesn't do the trick, since senders can never know if they've received the latest announcement and thus can't be sure that they aren't sending their messages to a compromised encryption key.
Inkan solves this by recording key delegation and revocation declarations on-chain. The mechanism doesn't care what the key is used for, so it could be used under a 4E announcement.
I actually started experimenting with double ratchet, because Inkan makes it easy for an identity to assign (and revoke / rotate) device-bound keys.
#naddr1qv…u0kw
The experiment deleted the networking kernel module trees among other things. If you're curious, the result is here: https://gitlab.com/inkan_dev/inkan-offline-live
I'll take a look at SeedSigner OS.
#coffechain
G☕️M et le croquis du jour
La tour carré du chateau de Gargilesse
https://blossom.primal.net/cb92dbbacdd35b9ccd2539811940335ec457b5f8f77b55cdc428e75d3114691a.jpg
That's great. It might be nice to have a relay that works out of the box for this purpose, and which users can easily build and install pre-configured on their VPS if they want to.
This looks like a great project, I just became aware of it.
I actually just recently built my own Tails variant with networking code stripped out because I wanted an airgapped amnesic environment to run my "Inkan Management Utility". It's a utility that generates key pairs together with on-chain declarations that delegate and revoke signing authority between keys, for a kind of decentralized PKI that enables cold storage identities for Nostr.
I wonder if DTails is capable of stripping networking out of an image too, for a dedicated "airgapped" build?
#nevent1q…3xlq
Oh, I realized only now that this allows you to received *actual* email from regular email accounts. I thought it was a Nostr-based simulacrum of email, but it's real email delivered to your npub. That's very cool. But it feels like I'd probably like to have my own dedicated relay for the emails to get saved to, and that relay should otherwise be read-protected.
Is it the the picture or Ethereum, or both?
Au pied de Gargilesse coule la Creuse, Indre
https://blossom.primal.net/3e069d7793b5d096a85e7ad3af8201cf8c278a1f35dba2877e4116ead0016f72.jpg
#coffechain
G☕️M et le croquis du jour
Au fond de la vallée. La Creuse
https://blossom.primal.net/60465c20cef93639e9b106be3d2bd7da2d938cadac9e67b0322071c53895d4ac.jpg
That happened around the same time everything else got uninteresting, including the movies.
Thanks, I've logged into both Armada and Nospeak. They discovered my past chats immediately, which leaves a good impression. Both of them also have pretty clean UIs, with Nospeak being my favorite so far. I'll try to use these for real next time I have a chance, and see how they feel in practice.
If you've followed Inkan you know the core trick: your signing key gets compromised, you revoke it, swap in a new one, and you keep your identity and your followers. Key dies, identity survives.
But there was one gap left.
Say your key gets stolen Saturday 4:39am. You don't notice. You wake up, post a few notes, run errands. It's now Saturday 3:19pm you finally see something's off and revoke the key. That's great, but for 10½ hours the thief held a valid signer key. Anything they posted in that window, they can get it Bitcoin-timestamped, and then it looks like you. They can't touch your timeline before 4:39am or after 3:19pm. But that window is polluted.
So here's what's new in Inkan. When you revoke, you can now retroactively disavow that window. You do this on-chain. You basically say "Nothing signed by that signing key between 4:39am and 3:19pm speaks for me." A delegation-enabled client can then mark everything in that window as disavowed and can filter it out of your timeline. Impersonation gone.
One problem though. You yourself also posted in that window. Your real posts get disavowed along with the fake ones. Baby with bathwater.
That's the second new piece: re-ratification. You go through the disavowed window, pick out the events that are actually yours, and publish a re-ratification, also Bitcoin-timestamped. Those events come back and stay on your timeline, marked as re-ratified.
Net result: key stolen, key revoked, window disavowed, your own posts rehabilitated. The attacker's stuff is chased out, yours stays. Timeline repaired.
Live now on https://www.inkan.cc
