This may be a stupid question, but does standard practice involving “right to negotiate” actually apply for nodes operating within the regime of SAFE routing protocols? In other words, if a section is unhealthy and a given infant node shows up to help out, behaves well, doesn’t ask too many questions and does what it’s told, isn’t this all that matters? If the infant node ends up being adversarial, won’t other node aging and defense mechanisms kick in to ban the node from the network? Consider a sly adversary that somehow figured out a way to get this right to negotiate, the group still needs to ensure that they are protected from this crafty devil, right?
Yes, filters are good. Perhaps rather than a deterministic filter, a stochastic one will suffice?
Forgive me if the following real world analogy is too naive: A widget company (section) is overworked and has need for some additional employees (infants). Their HR department (group) can either screen new applicants based on referrals from neighboring businesses in the community whom they trust (targeted neighbor relocation) or screen applicants based on the pedigree of their resume (HDkeys). These methods are both HR preferred when compared to the effort required for the company to hire every individual that comes along off the street (unfiltered), pay some employment tax, then ban them from the premises for bad behavior and lack of productivity. However, it’s not like this company is sending a rocket to the moon, they just make widgets, so the value in an overly selective screening process may be limited. Enter candidate pools, where any candidate that shows up will be placed into a pool for possible consideration. Every so often (random accumulation/wait time), HR selects a candidate from the pool at random. As long as there is a majority of decent applicants currently in the pool at that instant, the chances are good that HR will hire a good worker, and the randomly selected worker is still going to need to pass some entrance exams (PoW/PoR). However, this doesn’t necessarily stop a mass of applicants from swamping the front doors of the company ever day, thereby shutting down operations. To guard against this scenario, priority is given for entrance to the facility(message routing) based on seniority (sending/receiving node age). Thus, HR considers new applicants only when most all other meaningful work has been completed. Incidentally, if production rates are falling too quickly due to lack of workers (rapidly declining section health) then finding new applicants may become the highest priority work in the interim. Job seekers for their part, may be impatient, so nothing stops them from leaving to look for a different place of employment, or for a message to arrive from management at another factory (group in neighboring section) indicating that a particular applicant is banned. You could also pit applicants against each other to see who is the most trustworthy with the widget inspection (collective data integrity / resource proofs). Since priority is given to seniority (node age) when leaving the parking lot (message/data routing), shipping and receiving is not held up due to too much unproductive traffic to ensure normal company operations go largely unaffected.
Yes, this was a rather long winded way to suggest a group acceptance strategy based on random acceptance from infant pools that occurs at random time intervals while also assigning messaging/routing/hopping priority based on nodal age. Some competition within infant pools or assigning collective/coordinated PoW may also be a way to minimize resource needs from the more trusted members of a group and to out which applicants are untruthful. This may be in line with what @rreive was alluding to. I see that in the time since you posted, and since I had some of these thoughts, dirvine gave some additional clarifications here that I missed the first time reading through so maybe what I’ve said falls into dirvine’s category 3, ie. “terrible”. Anyhow, I apologize if this was counterproductive, but agree that the idea of random relocation is potentially a very good one since stochastic monte-carlo type processes like this have the potential for maximal scaling. However, there is always a fine line between the law of averages vs. using intelligence to improve efficiency and right now I’m not experienced enough to judge just how time consuming the “brute force” key generation following the standard protocol will really be relative to other network timings. For this reason I’m looking forward to your analysis of the crowd-sourced keypair generation data. Cheers.
method should be done before during beta. Or else it’ll stay that way till the complaints of the time taken to rejoin the network arise.
and continue enjoying the journey.
