Because their poorly conceived measures to prevent group takeover by malicious nodes are unlikely to work, the gifted MaidSafe developers keep complicating things with additional RFCs.
One result of such efforts is a new RFC for node aging, which basically requires each new node to perform a certain amount of compute work before it can join a group, and punishes it for service interruptions (“going offline”).
Consider this (full text of this RFC can be found here):
The network must secure against targeting groups. Earlier RFCs such as disjoint groups and node key as name as well as data chains and locked data chains (linked below) have solutions for improved group security, nodes faking group membership, this RFC specifically focuses on targeting groups.
This RFC will ensure that nodes are relocated and therefore dilute their impact on the network across the address range.
As I pointed out earlier, other RFCs don’t do much for group security. This RFC clearly states it only dilutes the impact of rogue nodes, so all this monkeying around with RFC is just a (very) poor man’s Proof of Work. What are they trying to achieve?
The outcome will be that an attacker or large participant in the network has an amount of work that must be carried out that is prohibitively expensive.
It’s not prohibitively anything, it just postpones the inevitable. A rogue node with 1MB vault takes almost zero resources and thousands can be set up and left idling until their status advances enough to be able to overtake a group which they dominate. The cost of grooming a 10,000 strong botnet like that is tiny (few hundred dollars per month).
Is this MaidSafe’s last attempt at Poor Man’s Proof of Work? No. They’ll have to keep messing around with it because they already know it won’t work:
The maths model of age based relocation is, as yet, incomplete, although it’s very difficult to imagine this does not significantly increase security, whilst also allowing nodes to accrue an age that allows them to store significant amounts of data (archive nodes).
In comments posted on the community forum, MaidSafers state that nodes that go offline will have to start from the lowest “status”.
There is no way for SafeNet to know which nodes are mobile, so mobile nodes (if they ever support them) would take a long time to join (due to the calculation that must be performed) and won’t be able to advance their status due to interruptions (due to power and/or signal loss).
And all clients from areas with unstable Internet connectivity will have the same problem, which guarantees centralization and fewer vaults (which probably makes it even easier to take over a group).
Like other related RFCs, this RFC illustrates continued problems that a network based on Proof of Ridiculousness cannot solve. Which is one of several reasons why Safecoin will never work the way they promise.
Proof of Nothing
In today’s forum post we learn more about the futile attempts of MaidSafers to create a poor man’s PoW substitute. Details of this particular attempt can be found here.
Based on a variant of Hashcash with the addition of the requirement to transfer an amount of data, this library does provide a “proof of work” like algorithm. This work requirement forces joining nodes to perform some calculation and data transfer. The expected use case is to require the work is done and data transferred within a time duration.
It should be clear to anyone that the both of these tests can be easily manipulated. (Start with the obvious: modify the source code to do trivial checks, or simply report a made up result).
But, how does it work?
This crate hopes to combine mechanisms that attempt to validate resources on remote machines. This validation though, is a spot check and also best effort. It is not guaranteed to be accurate over time and this consideration must be clear to users of the crate.
In other words, this is completely useless, but they’ll still spend resources on it.
The important point is that checking the proof is very fast and given enough difficulty, creating the proof is work intensive. This is a critical consideration that will mitigate some attack vectors on decentralised/p2p networks. It is by no means a security solution and should not be considered without continuous ongoing checks on a nodes “behaviour”.
The more important point is that SafeNet has no way of knowing whether the check has been tampered with.
Another important point is that they have no way of knowing of much RAM or flash cash a system has. If test datasets go up to 500M (which can be observed, but also learned from the source code), one has to create a 550M cache and can continue using the slowest HDDs out there.
Another important point is the CPU check program can be assigned a lot of resources while the rest of MaidSafe can be given minimal resources.
In summary, this is useless and won’t work. At best, it can become a minor distraction to hackers, and a major to users.
If they ever get anywhere close to releasing a production network, these dismissive MaidSafers will begin to appreciate Proof of Work (as implemented by Bitcoin).