OK, but wouldn’t you want to test that? And until it’s fully tested, wouldn’t you want to have some backstops?
I do understand that a new, bootstrapping network is different from an established network. In a new network, nothing has any history, so you can’t trust any one node over another, and there are no established nodes that will relatively reliably backstop a failure to deliver. You have limited options.
Nonetheless, if your beta network ends up full of bogus Sybil nodes, but you think your production network would not, then you still probably aren’t getting a very good test of nearly any part of the protocol. Maybe churn resistance… but that’s something you’d normally test in a way that you wouldn’t call a “beta”.
Giving out tokens, which are definitely meant to have negotiable value outside of the system, for beta nodes that can’t deliver service, will actively motivate people to participate in your test in a way that undermines its value as a test. It only makes sense if it’s for some unrelated reason that’s actually seen as more important than getting a good test.
That was my original point.
As for the issue more generally…
It’s nice that a nonperforming node will eventually be excluded, but if the person who set it up can collect any kind of reward before that happens, and nothing else limits the ability to keep doing that, then most of the nodes in your network at any given time are going to end up being bogus spam. No P2P network can survive if a really large fraction of the nodes in it are bad actors, and “bad actor” can very much mean just not being able to provide service.
In a production network, you don’t want a node to ever collect an actual reward without demonstrably doing what it’s supposed to do. Preferably you want to do that in a way where it can’t even build up a useful amount of “credit” in advance of actually delivering service, no matter how hard it tries.
Now, maybe the protocol is “eventually Sybil-resistant”, in the sense that it won’t end up handing out tokens exploitably once it’s been running for a while. Maybe any vulnerability only exists at startup. Even if so, you should still want the test network (and the bootstrap phase of the production network) to have some kind of immediate, interim resistance, however fallible. Otherwise you won’t get a useful test in your beta, and/or your production network may never make it to the point where the “real” Sybil resistance kicks in.
There are heuristics that have been shown to help a lot in real networks, against real threat actors (who tend to have limits that theoretical ones don’t). Even trivial things like blacklisting address space if too many nodes show up in it too quickly.
Not having any attempt at protection from the beginning, and apparently actively cheerleading for people to set up bogus nodes to get rewards, makes it look like there’s some motive here other than testing anything or getting a network running.
