Why aren't we doing NIP-03 of `kind:0` events to make impersonation even harder?

Replies (23)

It would make normal profile updates very expensive. Why timestamps over PoW? If you prefer older profiles, the dishonest one quickly gains the advantage and never loses it
Also that you're relying on OpenTimestamps. It theoretically scales well, but if it's a vital link in a trust chain people will spam it either for value or for DoSing honest updates. It's simpler to attach PoW to kind:0 updates, that way the attacker bears the cost
It would be interesting to have a "PoW zap". You can game Bitcoin zaps by zapping yourself, but Proof of Work costs the same either way. If clients periodically PoW zapped the accounts they follow, legitimate accounts would accumulate huge sums over time, and spammers would always start very low. On a cell phone? No problem! Someone could run a PoW zapping server that converts Bitcoin into PoW with server efficiency
By the time a scammer has accumulated significant proof (likely on their own), they'll be identified as a known scammer
Either they'll flood it with honest requests, or they'll flood it to prevent honest updates. I'll let Satoshi know about PoW. He'll be disappointed, but you're probably right
Bit rude perhaps not to clarify, since you are still a PoW believer: PoW gives you no defensive advantage whatshowever. This is why it is usefull in Bitcoin, because no participant should have any structural advantage; but when it comes to protecting my stuff, i do want asymmetry, and as much of it that i can possibly get. The best example of asymmetrical defensive advantage: cryptographic keypairs. Hope this helps
Not sure what mechanism you're proposing. Something like "PoW zaps" would be an extension of WoT, but with more skin in the game. Your asymmetry is having followers that burn resources. Much harder to Sybil than nostr today
You realize that a simple OTS gives you Bitcoins PoW practically for free? And denial of service on a calender server? Meh..it does not even do anything if you simply delay publishing your event until after the timestamp of that event has been mined; at which point you would have to conspire with the calender server. And if there seriously would be a scenario where that would be a plausible risk because we are dealing with something that high profile, you could just timestamp things with your own bitcoin transaction, and that would still be cheaper (and way way way more definitive of a defensive measure) than going a PoW route.
If your goal is knowing when something was published, OTS certainly gives you that. An attacker will duplicate the update, and also register it with OTS. The next time you update your profile, the attacker is more authoritative than you. OTS gives you "the PoW of the blockchain", but only for knowing a time something happened before. Collective PoW gives you something else: an expensive notion of how much the network trusts your npub
Yeah i don't think the OTS in this instance is all that helpfull either, especially because older kind0 events are not stored by default. When it comes to this stuff i am a WoT maxi, i don't really think it is worth doing much else. I have a scheme in mind that could streamline the entire thing, but need to sit down to work the explanation out more at some point.
Constant's avatar Constant
TL:DR, using musig events as association proofs to base WoT and identity analyses on in order to facilitate key migration. Been struggeling with a write up, so il have ass a post on it first: Figuring out which npub is the correct npub in terms of the person/identity/thing you are looking for is a hard problem, especially if you take people migrating to a different npub (because of loss or compromise) into account. For many reasons i wont go into i would posit that the only real way is to leverage contextual understanding, or what we broadly call 'web of trust'. This type of analyses looks at behavior, posts, mentions, reactions, follows etc. and through interconnectivity in associations you can start to make sense of things. My idea is to add a thing, which could serve as a relatively simple efficient abstraction of these associations into single events. So instead of for example trying to look for mutual follows (bob follows alice; alice follows bob, so we infer association of some kind) , Bob and alice create a musig abstract handshake event together. This can be done between two or more people. This way, "association" (whatever that may mean) is abstracted into easily traceable compact data. Easy to trace because this musig interaction creates an Npub specific to the combination of the two or more participating npubs. And compact because one event represents two or more associations. The idea is to put experation dates on these things, this way signals 'die out' the moment association stops between Npubs; this could be cause to look for other association events, and perhaps finding someone posting under a new Npub within otherwise the same 'network of associations' with the same name (indication some switched keypairs). To be clear, this type of analyses is probably still somewhat complex, but hopefully massively simplifying the queries and comparisons. To be clear i am not suggesting to do this with everyone, on the contrary: you are in controll of what this 'association' means, and you effectively tie your identity to it. The events themselves are just evidence of appearently a concious decision to interact in a particular moment in time. What leads up to that is up to the participants themselves. Some super fancy procedures for really important people; just the fact your bro joined the voicechat during the weekly gaming sessions; Or because....you live in the same house. Bottomline is that 'you' are defined by what you do as much as who you associate with; and what npub your using is expressed in both, may change over time, and this way we have a method of keeping track of that. Not a watertight superdeterministic objective binary perfect system, but a...practical approach. Anyway, better write up is comming, maybe. Any questions?
View quoted note →
That seems complex. Proof of Work is less complex, but no one's using that either, so 🤷🏻‍♂️ Maybe it's a problem that isn't really a problem. If someone who I'm not following messages me, I just ignore it
Because it introduces pretty significant friction to onboarding. An ok compromise that I have in coracle is to nip 03 the user's first post, which could be used to discover new users (although it probably isn't really)
In order to be meaningful, pow should take some time (how much do you need to deter spam? 30 seconds?). So unless you're super clever with the implementation your user would have to wait for it to finish. Maybe if you collect profile information and generate the user's key at the beginning of the onboarding process you might be able to generate the work in the background while the user is occupied with something else. You could also publish first a low-pow version (to avoid failing to publish one if the user leaves the page), then a high-pow version later. So I guess it's possible, just complex in terms of implementation.
Uhhmm... I'm talking about using OpenTimestamps, as per NIP-03. All the PoW comes from bitcoin miners. The user doesn't need to do anything. The client just needs to make a single call.
Derp, was thinking about NIP 13. That's what I get for memorizing all the numbers. Not a bad idea, although like someone said you would lose the attestation when you update your profile.