Gaming farming rewards - cost for GETs

What if my client is sitting in the neighbour section? Clients can reconnect as often as they want if I’m not mistaken…?

Have to ask someone who knows the code. We’ve always been told the number of hops is on the order of log of the number of sections and required to be a few in order to provide the anonymity.

For your example its easy to do if the section tells the node to send it to a section not on the actual path and then that section hop it as normal

I always assumed the log n is worst case/longest path to chunk discovery not a stated goal :face_with_monocle:

But routing along xor would be only one path from the neighbour section and only one hop…

2 Likes

This defeats the principle of anonymity

Are your data managers outside of your section? Or am I out of date with the concept of data managers? (or am I mixing stuff here now?)

Edit:
I thought for a get there happens precisely one relay hop for anonymity on top so it’s not you who requests the data - but I somehow assumed because of the one additional hop the relay would be inside your section… Since this is not necessarily the case if you cannot know the section of your relay(s) my assumptions don’t hold anymore :thinking:

(but if you can reconnect until you have a relay in a neighbour section it again would only be one path)

2 Likes

This graphic (old and dated) is what I base my mental image of the different intermediaries between a client get/put and stored chunk.

I think most of your concerns relate more to the game-ability of PtP than PtF. We want the network to be resilient against ddos attack. PtP gives a direct incentive for the attacker to try a ddos, but it also gives us a means to focus the discussion to creatively come up with ways to mitigate ddos. In other words, I see it as : PtP solution == Ddos solution and vice versa. So far it seems that caching is the primary defense, but there may be other ways…

1 Like

Hmmm not sure it’s “that simple” - for PtP I need to try and get all my data into a singled vault (+relay to the neighbour section to only have one path and manage to get around caching) and reward is only 10% of the farming reward while if I own a vault and know which data I can request+ I don’t have the hassle & cost (with mutable data it’s easy to target a section but not that easy to target a specific vault…) and get 10x the reward if I manage to have enough data to blow the cache…

Yes. Each vault lists its own content by key.
https://github.com/maidsafe/safe_vault/blob/master/src/chunk_store/mod.rs#L196-L210
But as @neo says, it is the elders, applying the routing logic, who make the requests to the different Vaults.

BTW, for various reasons I am against PtP, at least during the beginning of the network. I find it technically dangerous, as it could encourage different attacks, and globally, it could give a negative view of the network since piracy and porn would be dominant in the early days.

4 Likes

You don’t know which data you can request by xor address just from owning a vault. Iirc you would need to own the vault, one of its pmid managers and one of its data managernodes. I don’t believe that is possible with random relocation.

With PtP you could create a data chunk and know the xor address. This address could then be requested by a botnet of getters to earn PtP rewards. Caching will slow it down unless as as you described in earlier to there is a cache overload, probably very unlikely as neo described. Growth is key… If the size of the network is much larger than the botnet then caching will probably handle things just fine. What rewards could be used to grow the network as fast as possible?

2 Likes

Okay - requests first go to (all? Oo) elders and those (vote?) decide how to route the data for all gets? Oo

But doesn’t reliable message delivery just specify that all messages/get requests get relayed to the next section/the corresponding vault…? So all elders cache all (yes a subset of 1/3 - but even when multiplying I only need 10 times the data a cache has - that’s possible I would assume) requests and therefore I would (if requesting from the neighbour section) just blow the cache of all elders in my and the target section at the same time…? (edit: the cache size would roughly need to be the around the size of the data storage of the attacker to make sure this cannot happen - just my estimation/expectation)

I would love to believe this - but that would mean that I need to store all data with key information and all the data managers/pmid managers store a table with info which key of my list has which xor address and the elders then only know which data managers to contact for getting the chunk => those tell me to deliver the corresponding key… That would indeed obfuscate the thing largely but I have a hard time believing it’s done like this (just a feeling - I have no proof)

1 Like

Is caching even a solution for PtP gaming? I thought each GET (even cached) generates a PtP reward for the producer?


But the actual data gets indirected by the network: Data Density Attack ?
So the id you get from your vault isn’t the public id of that chunk.

1 Like

No it doesn’t because there is no farming when cached.

1 Like

But if there are not rewards for the caching nodes, then why would they even reserve more resources (memory as level 1 $ / hdd space as a bigger level 2 $) for the cache?

2 Likes

At this time farming rewards covers all the activities the node does. You do not cache then you become a misbehaving node

1 Like

That’s imply section consensus for each section on the path of each GET, isn’t it?

Hmm, RFC 57: Safecoin Revised - #54 by dirvine would make more sens if there is a section wide consensus for GETs (a vault would know if an internal GET isn’t valid, the proxying vault could still do an external GET tho, and repeat if it gets the GET).

1 Like

Yea for GETs, but a cache response is not a GET is it.

How would the elders know from outside how large the cache of the other elders are supposed to be and what gets are supposed to be cached without doing exactly the same work and holding the same cache…? (edit/ps: and only 1/3 of elders are the delivery group according to the rfc reliable message delivery)

2 Likes

Not now, maybe in the future as other features.

imagen

Probably never know it because it would add a routing complexity that, maybe, will not worthwhile. When you live in a completely decentralized world you must assume that a majority of nodes will act honestly. Otherwise the network will never work.
And all the Elders participate in the reliable message delivery. Only that in each hop of each message only a subset of elders will be involved (otherwise the number of messages and the cost of a network operation would increase almost exponentially).

2 Likes

This thread is very confusing to me so hopefully someone can help clear things up.

How would a chunk not be able to be requested individually? That’s the whole point of the xor url system isn’t it? Am I missing something here?

If you could find a source for these bits of info I would appreciate it. I don’t know of the network doing any encryption to chunks. I only know of encryption being done by the client. But I could be wrong so would be interested in where I missed this info.

There’s a lot of different levels of encryption including optional pre-encryption (eg pgp), self-encryption (automatic by the client), transport layer encryption (crust/quic) but none of these clarify to me why vaults would be encrypting chunks in a way that prevents knowing what chunk is stored. (Important clarification: vaults know the name and content of the chunk but don’t know the file the chunk is part of or the meaning of the content in the chunk).

I must be missing something here because as far as I understood it every vault knows the xor names of every chunk they store. And xor name is all that’s needed for a client to request that chunk (see above for link to xor urls).

This is another thing I can’t recall having read. If you could provide a source that would be great so I can fill the holes in my reading. As far as I know any new chunk once it’s created by the client has a fixed xor name and content. The only role of the network is to ‘place’ the chunk in the correct location, not to obfuscate or modify it. Am I wrong in my understanding?

The vault does (locally) know time and cache is entirely locally controlled so in theory they vault may choose to expire cache by time. But probably as you say it would be optimal for them to expire by volume so whatever. But my point is: cache is local, so is time.

Another example is proof of resource must be completed within a fixed time, even though the network itself has no sense of time.

These are old terms, have been replaced by Elders:

“Existing group Authorities such as NaeManager and so on will all fold into a single type, Elders” (source)


Overall this topic has made me feel there’s a need for a simple explanation of how routing actually works, and maybe some explanation of how it used-to-but-no-longer-does work.

I know a lot of changes have recently come about, especially the secure/reliable messaging, so misunderstandings and legacy knowledge are quite understandable. But it’d be nice to have a consistent and up-to-date understanding because much of this thread is not consistent with what I thought I knew about routing and chunk storage, which is a little concerning considering how much time I spend on this stuff!!

8 Likes

@neo would have to answer that, I was always assuming here that they could.

1 Like