Last Notes
something is messing with the ui @npub16xn…6z6l https://image.nostr.build/d0456970154c567f4782b5d42ca91ea624d8b09498ab59389f4583eaef633b6c.jpg
Yeah, and it's actually worse than just hate, they are *correct*. I think economists call it "rational ignorance," and it can be the right move with limited cognitive resources. So you don't read the NIP, you instead watch what your peers do, except the problem is your peers are watching you, so there's paralysis. The key rotation discussion on nostr is this bottomless information cascade, and that probably applies to other topics as well. I guess the trick is to make checking cheaper than doubting.
If I'm understanding this correctly, it should be at least as safe as NIP-46 if you hold your own shard and require all shards to open the vault. (I guess that also assumes that the underlying cryptography is as good as when you just hold the full key.)
If you have your own vault, is the experience of that similar to having a remote signer? Can one have a vault on one's phone, maybe something that can be used like Amber?
Great, thanks for calling my attention to it!
The UI changes were due my adding an AI-based nostr search feature. If you're interested, I gave you access to it, just click on "Assay" in the nav bar and take a look if you like.
I'll probably revoke access again soon as it's still a construction site, but if you'd like to try some searches in the meantime for a quick preview, feel free to do so, I think it's kind of fun.
Thank for pointing it out, that looks very wrong!
Can you do [ctrl/cmd]+shift+R, or alternatively go to Settings > General > Check for updates?
After the app has updated, can you see if it works better?
yes, which is also why there are no failures compared to jev
https://paragraph.com/@metaend/we-put-the-typed-decision-engine-on-four-of-our-own-jobs-it-lost-three
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
nostr is my only bridge to the worlds of ai engineers, except I used to work in the building next to their headquarters I think
it's new and hyped to the tits on linkedin by the typical "Ai Engineers" :copy_812bf741_ab2f_40ad_abf9_188:
That feels right ... I had never heard of jev, thanks for pointing it out.
the thing is, this simple stuff, which you usually run more than 100 times is always worth it. for a single test? prehaps jev has a place, but then again, it's just overhead in your stack
This sounds like when a mechanical solution exists you'll want to use that. And when none exists, it may be cheaper to create a mechanical solution and use it. Maybe jev is useful when it's not clear how to create a mechanical solution?
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.
Do your mechanical solutions require custom-tailoring to the task at hand that jev doesn't require?
So I had our whole fleet on #jev yesterday, running benchmarks and tests mostly against mechanical solutions we run anyways, and it was around 10% inferior to our solutions on average. Plus our stuff runs offline
If "convergence delay" is meant to refer to a delay that occurs before *relays* agree on the same set of revocations, then that term carries a presupposition that relays *will* at some point converge. As far as I can see, there isn't any particularly strong reason to think that they will ever converge.
(I'm not sure what "DST" is.)
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.
more reliable? unreliable? relia-bro?
I think it's difficult to do without a blockchain.
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.
Thanks, I guess "fork" and "join" are concepts that apply in the cryptocurrency context, so probably not directly applicable to inkan.
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
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.
To trust a self-declared disavowal, you have to trust the *person* behind the master key.
When somebody retroactively disavows past events that were ostensibly signed on their behalf, then a question arises as to whether that disavowal is honest or not.
This question cannot be decided mechanically or by an algorithm. You have to look at the circumstances of the particular case, and you can only do so to the extent you have access to relevant information.
And an important piece of such information is the *time* at which the person made the disavowal, whether it was made retroactively or not, and, if so, which events fall within that retroactive window.
In many cases, you will simply believe the person who made the disavowal and not attribute the disavowed events to them. You can simply set the inkan client to not show these events, or if you operate a relay you may decide to delete them.
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.
"Y can never spend anything that X signs"
I think that's not quite correct. For example, on Bitcoin, spending something signed by another key is the *normal* case, every spend uses an output that someone else's transaction created.
"We can just trust X's 'created_at' in the revocation event"
If X's self-declared created_at is treated as authoritative, then X can sign a revocation today that's dated last year and retroactively disown a year of events that counterparties relied on. Also, even assuming that X is always honest, the issue about the *discoverability* of X's revocation remains. A party who never *becomes aware* of X's revocation will just keep attributing events signed by Y to X forever.
More generally, revocation is not a private matter between X and someone who has a personal opinion about X's character. The idea is that *every client*, with no trust in anyone, computes the same timeline of delegations and revocations.
"utxo" in this context refers to a "delegation of signing authority from X to Y." Key X can "spend / burn" that output by revoking the delegation, and key Y can "spend / draw on" that output by signing events that are then attributed to X. Order is absolutely crucial because, once a delegation from X to Y has been burned, Y can then no longer draw on that delegation to cause the events signed by Y to be attributed to X.
"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'm trying to get my mind around this. With VDF you can limit spammers to, say, 1 event per second from the same pubkey, right?
But you can't limit them to 1 event per second from different pubkeys. So they can run CPUs in parallel producing separate chains containing tons of spam events.
I guess you could look at each chain at the end of each day and if it looks spammy ban the pubkey, and the attacker will have invested a day's worth of CPU in it.
But in the meantime, they'll have caused the relay to deliver 86,400 spam events to users for a day, which presumably was their purpose.
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.
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
Doing some GEO analysis our harness found a big one: misconfigured woo commerce plugin literally made critical and private data un-gated AND INDEXED available to the unauthorized public.
I would say that's bad, but also a nice extra for hiring me to fix your shit
I think it's different with a chain, you can verify that nothing was omitted. For example the note below has a screenshot of a table showing a complete key delegation history that a client has read off a blockchain:
#nevent1q…tvx9
Yes, but an attacker will also be able to decrypt messages encrypted to the old key. Also, the old 10044 is validly signed forever, so an attacker can actively seed these announcements in any place that hasn't received the update. Inkan fixes that as a by-product of its key rotation system, which records revocations on-chain. I may try to add DMs, right now I'm exploring if a double ratchet is feasible.