Devman - thanks for your response, I finally have the time to reply. If the detailed spec you are working on is published anywhere I’ll be happy to read it, hopefully I am not missing important details below. It ended up being a lengthy post so I’ll start with the summary
Overall there are few (but important) differences between the two arrangements - here is the summary of benefits and drawbacks for the proposed pooled system as I see them now.
- allows instant response to nodes looking to register, which will make node deployment easier to troubleshoot
- requires a port open to the world on the tracking server which would be easy to DDoS or otherwise attack
- difficult/impossible to publicly audit the node uptime calculation
- the solution is further removed from the ultimate goal of using the challenge responses as a test of the publishing functionality (to e.g. GNUNet)
In both cases, I would suggest the server uses a private cert for encryption and the nodes verify that cert when connecting or receiving a request. This should prevent amplification or MITM attacks.
In more detail:
1 DDoS: a polling server will be much harder to DDoS as the central server would not have to listen and respond to requests. A DDoS attack would need to exhaust the connection bandwidth to be effective which is much harder than to tie in all available machine resources with bogus requests. A polling server is MUCH safer in this respect.
2 DDoS node: When the node is listening on a port it is trivial to limit the source addresses that it responds to (unlike the polling server). The port will only be opened to the IPs of the polling servers. A simple IP tables rule can make sure noone other than legitimate pre-defined polling servers can connect, which completely eliminates all attack vectors over that port (except compromise of the tracking server).
3 Uptime-availability: there would definitely need to be more than one challenge a day - more like one every 15-30 min I would expect. The exact number would be a matter of balancing granularity with resource usage. The challenges and verifications that the pooled system uses can all be built into the polled system as well. The only item I am not sure about is the challenge during registration as I don’t know what it consists of. Can you describe it?
4 Uptime-tracking: I did not assume there will be only very few disconnects, but agree that is probably safe to assume that. I’d also agree that if well written, the code should be able to notice a disconnect event without having to explicitly check connected clients periodically. Still there will be summing up of durations of disconnect events in the end. Overall the pooled system will be slightly more complicated and prone to error because of the added dependency on the code correctly detecting disconnects. It will be further from the ultimate goal of challenge responses being published to e.g. GNUNet, so either that white paper functionality will be dropped or more re-development will be required. Finally, it would be easy to set up some form of audit system for the uptime tracking as we would just add a system whcih is allowed to poll nodes. With the pooled design we have to trust the pool - I can’t see any feasible way of auditing the decision it makes on the uptime of nodes.
5 Node health and 6) RPC on the node - it is good that ultimately the local SecNodeApp executes the RPC commands; in that case both options should work equally well. Block height is easy to fake, but connected peers can help if we match the results across nodes. If node A says it is connected to node B, C and D but they don’t declare being connected to A then A is faking. Some level of mismatch might have to be permitted.
7 Yes the polling server would verify the URL every polling interval which does mean more work but it is not resource heavy in any meaningful way and can provide an extra check/security. If this is taxing than I think, the polling server can easily store the results and copy the behaviour of the pool system.
8 Self registering: The only difference here as I understand it is whether the node can initiate the registration or has to wait for the next challenge period. Yes it would be easier for troubleshooting nodes if the result was instantly available but opening a listening port on the tracking server open to the world is a price I would not pay for that small convenience.
9 Using the blockchain for administration: fully agree we should limit the amount of transactions and these should not be required at every polling interval. Would it be better if these transactions are done randomly as determined by the tracking server rather than always at the time of node registration, which is triggered by the node?
10 Scalability: The only difference between a pooled and polled system is whether the check will be executed over a ‘always on’ connection established by the node or over a short-lived connection established by the tracking server. The number, timing and type of checks executed is independent of the type of connection used.