neo: neo: I though bad nodes were being evicted (removed from section and ignored thereafter)

I think that’s the intention, but as yet does not exist to my knowledge. And actually this is a pretty tough problem… deciding who to punish and to evict them as a group is quite different to individually ignoring a vault that appears misbehaving just to yourself.

neo: neo: 100th block seems too severe.

The number is just an example. I mean to say ‘after X time’ where time is measured in datachain blocks and is presumably a very long time. Don’t want to evict often, maybe vaults are evicted on average after two years?

neo: neo: What about Archive nodes

This is a good question, and since archive nodes are still just an idea with very little info behind them I might expand a little on my own ideas for that.

I think archive nodes (or any ‘class’ system for nodes, including the ageing classes) is not going to be that great. Balancing rewards and trust and cooperation is quite hard, and more complex reward structures become harder to predict and guide desired behaviours. If the behaviour deviates and requires intervention it can bring the decentralisation and governance of the project into pretty serious doubt. Not to say it must be perfect to start with but having a good basis to start from is important.

My feeling with archive nodes is there will be nodes that choose to operate on a very aggressive policy for caching, to the point that they are virtually all cache and almost no vault. These will become defacto ‘the archive nodes’ without requiring any explicit designation since they can restart in any section and not require any initial transfer, they’ll just have what they need immediately. Instant restart, instant relocation, instant merge. The phrase I use to think of this concept is ‘opportunistic caching’. imo the power and importance of cache has been seriously misunderstood and under appreciated. Mutable data adds a lot of complexity but the power behind the opportunistic cache idea is still there. The idea that vaults only store their section/close data is (to me) a ‘basic’ idea and the real power comes from the cache. This is of course a choice for the operator but one that I think will be taken avidly (similar to why people choose to seed torrents).

neo: neo: I would think perhaps halving of age if old enough and if baby then evict.

Yes, the type and magnitude of punishments is important. Eviction vs age penalty is a very good idea to ponder. Could even treat eviction as simply ‘reduce age by infinite’ so all punishments are done ‘using the same dial’.

neo: neo: mav: mav: If a vault is consistently underperforming it may be voted for eviction by other vaults in the section. This is what I expected to be happening anyhow

But how does the section agree on ‘underperforming’? It’s not enough for me to personally ignore/evict since then the consensus of elders / section members is inconsistent in the section. I may choose to ignore 7 elders because my connection to them is faulty, but do I use that personal info to elect for all 7 to be evicted? Group agreement for eviction is quite a lot more complex than individually ignoring.

neo: neo: There has to be some [method of eviction rather than no method]

Maybe not. Maybe there is never a need for a mechanism to agree on removing a vault. Maybe it’s a matter of waiting for relocation and seeing if it’s too slow (due to insufficient bandwidth to get new section data) which leads to a ‘natural’ dropping out; but this is not eviction. Sections have to wait for relocation before a slow vault is booted off the network, but I consider this different to eviction. Eviction is group agreement and coordinated action to remove a node.

digipl: digipl: it remains to clearly define the system of punishments within a section

Agreed. What actions are punishable and what is the punishment? Tough to decide. I think much tougher than the rewards and incentives aspect. But also probably much more powerful if used correctly. (Some unfortunate broader reflection of a pessimistic reality here perhaps?!)

dirvine: dirvine: feels like older vaults should have more trust.

Agreed.

oetyng: oetyng: would only negate effects of node aging

I think there is a point where a node of age eg 200 is not twice as trustworthy as a node of age 100. But a node of age eg 10 is twice as trustworthy as one aged 5.

Maybe it doesn’t warrant cutting that vault back to age 0 by random eviction but I think there is some value in allowing newer participants a chance to overcome entrenched elders by cutting the oldest back a bit (randomly or whatever).

This post came out of a period of broader consideration so maybe it’s worth adding those thoughts…

I feel the existing proposal for safecoin mechanism is completely undefined. In part this is due to rfc-0012 relying on sacrificial chunks which no longer exist. But the undefined-ness relates more to the need or desire to measure spare capacity and use that as a dial for rewards. There is no specification of punishments which is a large and important question-mark.

To my mind there is no reliable way to measure spare resources and quantifying or rewarding spare resources is an undesirable path to pursue.

This got me to considering the idea of voting to determine the difficulty of farming. If correctly designed (eg there’s a cost to voting) then it could be an interesting feedback mechanism for controlling the farm rate. For an interesting similar mechanism see how the Monero Dynamic Blocksize works - they can change the blocksize but it reduces their mining reward so they only do it if they think it’s worth it.

There are some obvious disadvantages to voting but the idea of penalties and / or voting is quite compelling, especially if the design has strong game theory behind it. Overall I’m not in favour of voting and hence started this topic to explore the idea a bit more (albeit within a simpler / different context than farming).