ExploreTrendingAnalytics
Nostr Archives
ExploreTrendingAnalytics
Tim Bouma1d ago
Ethereum as a public bulletin board… https://www.coindesk.com/tech/2026/03/12/vitalik-buterin-…
💬 5 replies

Replies (5)

inkan1d ago
Inkan uses Ethereum to record declarations of delegation / revocation of signing authority. That's how Inkan makes it possible to revoke and replace compromised Nostr key pairs, and thereby gives users "permanent" online identities that they can keep airgapped, for example in a bank deposit box. I think that's precisely the type of use contemplated by this article. But "public bulletin board" may not the best term for it. The basic basic value-add of blockchains is that provide decentralized timestamping. A better term would be "public timestamping service."
0000 sats
Tim Bouma1d ago
Nostr does this quite well as a public relay service.
0000 sats
inkan1d ago
I agree that Nostr is a public bulletin board. But it's not a timestamping service. Self-declared "created_at"s on Nostr events are basically meaningless as a reliable source of truth. Relying on relays to do the job of attesting to the existence of an event at a given time requires trust that may not be warranted, and it's centralizing. Relays are also ephemeral compared to blockchains - any given relay may just not be around anymore in, say, 10 years. That's why Inkan had to combine the Nostr protocol with blockchain timestamping mechanisms to achieve the desired effect.
0000 sats
Tim Bouma1d ago
Agree - you have to rely on the reputation of the npub, otherwise use OTS. For most cases, reputation of the signing npub will be good enough. Relays provide availability only. Anything more, relays fall into the platform trap..
0000 sats
inkan1d ago
The thing is that, under the regular Nostr protocol, you cannot rely on an npub's reputation at all, not even historical past reputation, once the npub has been compromised. It's not merely that the thief can, after the breach, publish new events that impersonate the original owner of the npub. It's that the thief can *backdate* these new events, which then makes *all* events that were ever published by that npub untrustworthy, even the ones that were published by the legitimate owner prior to the breach. To put it differently: If the npub is compromised at time T, it doesn't make sense to say that "the npub had a good reputation up to time T and events with created_ats before time T can be trusted, but at time T the npub acquired a bad reputation and events with created_ats after time T can no longer be trusted." Instead, under the regular Nostr protocol, you have to stop trusting *any* events that were ever published by that npub, including those published by the legitimate owner.
000
0 sats