SAFE versus passive surveilance

[smacz]

@janitor

The network knows because it picked one of the replica hosting farmers (vaults) to deliver.

Does the network choose one, or is it the chunk that arrived at the client’s machine the fastest?

[Seneca]

@smacz

Does the network choose one, or is it the chunk that arrived at the client’s machine the fastest?

All vaults holding the chunk will get the request, the fastest to deliver has a chance to get the reward. I imagine the fastest will be selected by the client’s manager group, which tells the vault’s manager group that that vault won.

[smacz]

Thanks @Seneca. I always seem to be fuzzy about the roles that the various Managers take on.

[janitor]

@Seneca

All vaults holding the chunk will get the request, the fastest to deliver has a chance to get the reward. I imagine the fastest will be selected by the client’s manager group, which tells the vault’s manager group that that vault won.

Hmm, David on several occasions emphasized that the speed will not be the main factor, because that would contribute to farmer centralization. @smacz I would suggest you to check David’s posts on this topic (I am writing from memory so I can’t provide specific links).

If it’s true that all vaults would deliver requests, that would be a disaster. Farmers already don’t get paid for PUTs, so this would mean more work (and precious egress bandwidth) for uncertain gain - cross that - certain loss (if you’re a home user who is fast, you can be pretty sure you’ll almost never be the fastest). With 4 replicas, the average farmer would have to serve 4 chunks to earn 1 coin; all those below average could conceivably store and serve data for free on a permanent basis. Some investment! (If what Seneca said were to be true. Which I think it isn’t.)

IIRC a combo score (“reputation”, which consists of age, uptime, performance, etc.) will play a very important role.

Edit: I found one of previous discussions on this topic here.

Governments blocking Maidsafe

Various versions question have ben answered by project members multiple times on this site, e.g.

[happybeing]

@smacz

In light of the numerous reports on TOR vulnerabilities, in what ways and to what extent is the protocol weak in regards to traffic flow or other analyses?

Also of interest to @Tonda for the OP…

There have been at least a couple of threads discussing these kinds of attacks (in 2014 I think), and at least one in relation to Tor (will SAFE be better than Tor? How do they compare? Kind of thing). I also think there is something in the wiki FAQ on that.

Anyway, the forum discussions have gone into some detail in terms of attack, network ability to evade them, and further measures that David anticipates to improve things even more.

I might have noted one or two links, but searching for posts about Tor and attacks/surveillance in @dirvine’s posts should find them. If not, DM me and I’ll check when I have access.

[Seneca]

@janitor

Hmm, David on several occasions emphasized that the speed will not be the main factor, because that would contribute to farmer centralization.

Vault’s own speed is only a (small) part of the overall speed, because the chunk has to be routed through the DHT before it arrives at the client.

@janitor

With 4 replicas, the average farmer would have to serve 4 chunks to earn 1 coin

It kinda baffles me that after so many discussions on this topic you still don’t get how the farming issuance algorithm works. It’s not static or linear like that at all.

[Warren]

Transitioning to self verifying hardware and wholly end user owned network nodes and a network free of state and corporate owned/controlled nodes and cables. Net composed primarily of SDR MESH SAFE Phones. Opponents will attempt shills but you’re getting to the same sort of power that compromising a battlefield com would require. Beyond that would be non local parings- need a time eye to help defeat that.

[janitor]

@Seneca

It kinda baffles me that after so many discussions on this topic you still don’t get how the farming issuance algorithm works. It’s not static or linear like that at all.

That may be because there are so many versions of the truth here. Can you share with us which is the correctest?

@Seneca

Vault’s own speed is only a (small) part of the overall speed, because the chunk has to be routed through the DHT before it arrives at the client.

Are you saying that a slow client download from one particular vault makes that vault get a poor speed mark for the chunk it served? Does the client decide how fast a vault is?