On the theoretical side, I'd argue that bitcoin PoW is the best choice because it is more resistant to malicious actors. Assuming that a solution to the botting issue requires a small proof-of-work or fee to post, on a PoW chain malicious actors would need to control a large amount of energy inflow and hash power to support their botting operation. Whereas on a PoS chain, they simply needs a large pool of capital to be staked, which would give returns that can support their operation. This means that the attack vector is larger on a PoS chain than a PoW chain. This is also why the nostr protocol itself has a proof-of-work component. It's the simplest solution to two-generals problem.
Ethereum had an unfair issuance. That means the founders kept a pool of coins for themselves and have unfair control of the network, furthered by PoS.
Ethereum is effectively a private tech company led by a CEO. They have a public roadmap.
Ultimately I think these fundamental properties of Ethereum make it inadequate as a permission-less money protocol. It works great for games and apps, but its foundations are susceptible to coercion and control - and you can’t build a permission-less protocol on that foundation.
[0] https://cointelegraph.com/news/51-of-ethereum-blocks-are-now...
This is incorrect, and your reference doesn't back the statement up.
Validators don't have to include any transaction they don't want to, just like Bitcoin mining pools don't have to either.
The link I provided shows this coercion via OFAC compliance.
I understand your excitement, but your elevator pitch fails to tell me why I should even look at it.
Posting your pitch on a technical public forum should have a random critically minded technical person in mind.
If everything is an event, and you can send any types of events, then you can trivially saturate the network, the clients, and the relays with bogus events.
> but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on.
None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
Yes, including "we send events, and listen to them". Kafka alone is 12 years old this year.
It’s uncharted in the protocol. The protocol has nothing to with crypto other than 1) it depends on cryptography and 2) there is an event type that cares about bitcoin lightning payment receipts.
Here's what I said, verbatim: "then you can trivially saturate the network, the clients, and the relays with bogus events."
What are you arguing against?
Explain to me how you trivially saturate this protocol. That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
Even if they don't accept your events, you can still trivially saturate their bandwidth and processing.
> Explain to me how you trivially saturate this protocol.
Explain to me why you keep pretending I said anything about saturating the protocol
> That’s like saying you can trivially saturate TCP/IP by broadcasting packets.
And yet DDOS exists. Things like TCP tuning to avoid network congestion exist.
I agree this is a problem. However, there is at least one protocol addition (that doesn't involve cryptocurrency per se, although it shares some ideas) that tries to address this: proof-of-work requirements.
The idea is basically this: message IDs are SHA256 hashes of message contents. If you add a nonce to the message metadata, then each time you change the nonce, you'll get a different SHA256. Relays can then choose to ignore messages without a particular number of leading zeroes in the event ID. This means a client will have to do a non-trivial amount of computation to generate an event ID that a particular relay will accept.
> None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
I mean, I think it's a direction for social media that hasn't been tried yet on a wide scale. Personally, I look at it as a cool idea- I don't know if it'll actually pan out in the long run, but I think it addresses a bunch of problems with both centralized and federated social media, so it's worth seeing what can be done.
On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.
I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)
One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.
---
For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.
What direction? Building music distribution and ai agents? Or building a social network that literally relies on trusted servers (that you're even expected to pay for) to function?
what problem does this solve? how many people are publishing events (tweets) that are inauthentic? you need to be logged in via password + 2fa on twitter to post. if somebody can post from your twitter account on your behalf, they are logged in as you. i don't see how "PKI" on top fixes that?
That's where PKI comes into play: it's not layered on top of a login system, it's a complete replacement.
The messages contain your pubkey so others know who sent it. Your messages are signed so others know they came from you.
If you don’t do that, as soon as it becomes popular enough to attract scammers you’re going to have Mallory publishing keys with Bob’s name on them and a million random people who have incredible financial opportunities for you. Most of the decentralized systems shift that problem to another system like email or DNS, Facebook/Twitter/GitHub/etc. at which point it’s worth asking whether there’s still value in decentralization at that point.
The only trust a 3rd party like Twitter demands in your example is that I trust they won't impersonate my account with a message (since there's no private/public key proof)
But your system doesn't address that either. After all, what's stopping _anyone_ from just saying they're me and sending out messages?
Like 99% of decentralized usecases, this still falls down to trying to cheat the oracle problem. I actually trust Facebook and Twitter more in this situation because they can at least demand verification in the real world, they've got enough social capital that they can overcome the oracle problem in limited contexts.
You are correct - it allows consumers to know the message has not been tampered.
The downside of your trust model is permission. Facebook and Twitter may revoke your permission to use “your” identity at any time, for any reason.
Requiring ID verification for a rented online identity is a terrible trend imo. These companies are not to be trusted - they exploit users and inevitably sell your data or get breached.
A tweet is not a direct message, it's a broadcast message.
Without a centralized 3rd party mapping names to public keys, the identity of the sender can be set to whatever you want.
Your model only works for non-tweets where I'm sending to people I had communication with in the past and was able to verify a public key... at which point you're just providing E2E encryption with worse ergonomics and no new value prop.
—
You cannot cheat the oracle problem. There is no magic bullet that lets you broadcast messages with known identifies without a centralized 3rd party.
- Sharing keys in person
- Sharing keys via other channels like Twitter
- Via DNS using NIP-05
> Without a centralized 3rd party mapping names to public keys
Sharing in person doesn't work for broadcasting
Other channels require falling back to some non-decentralized system.
Again, it's the oracle problem. You can't say it's not true, that's like saying "1+1=2" is not true.
Pretty much everyone, because Twitter doesn't provide a way to tell a tweet written by a user from a tweet written by someone that controls/works at Twitter.
On nostr if a relay or even client decides to ban you from posting you can just post from another client to another relay using the same identity.
my favorite part about that last one is the possibility of social key revocation - if you're in a community misbehaving, the same people you trust to save key fragments in case you lose your private key can conspire against you to lock you out of your account, a kind of cryptographic ban hammer.
KERI sounds interesting, I’ll read up on that. Maybe you can review that PR and share some insights?
everything is an event. events are signed using pki so it’s easy to know who sent the event and it’s authentic. they’re human readable json objects. events flow over websockets so it’s “real time”. you can build literally anything on this platform - listen for a type of event, do something, emit another. it can all interoperable. we started with basic twitter clones but are rapidly moving into uncharted territory - people are building music distribution apps, ai agents, and so on. and the entire ecosystem has native, programmatic payments built on bitcoin’s lightning network.