You're probably the one and only developer I wouldn't mind proving me wrong 
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
If you can show me proof of an existing crypto processing 250 tx/s sustained, I'll be mildly impressed. If it can be done on 20 or less nodes, I'll be suitably impressed. If you can show the same doing 500 tx/s+ I'll be very impressed.
Likewise if you can show peaks of 500, 1000 & 2000+ the corresponding impressed level as described above will be in effect
What are requirements for bandwidth, RAM and CPU of a node?
PS: I'm using a hash-based signing algorithm, it's much faster than elliptic curve stuff (even faster than Ed25519), so I may have some advantage right from the start.
The lowest spec node I ran in that test was an Asus i3-3217 laptop, 32bit OS, 256MB of heap allocated to Java and the DB running on its 5400 rpm platter drive. Its a really crappy machine, the CPU is Quad Core, but it barely manages 2000 passmark points and the HD...well....pen and paper would be faster I swear. It *just* about kept up acting as a ledger node, so I guess that or lower is your target
Not sure if anyone in the network was running lower grade hardware than that.
Hmmm...Ive found that the major bottlenecks on lower end stuff is actually the IO DB writes/reads and not so much crypto related stuff. Sure it has a positive effect if you can speed it up, but a good 70%+ of optimizing I do is how to get data over the IO quicker and more efficiently.