Gaming farming rewards - cost for GETs

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?


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)


Not now, maybe in the future as other features.


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).


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!!


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

1 Like

As I have always said.

1 Like

Just what I’ve come across on github and been able to infer on my own. Outdated info, yes. However, it’s pretty clear from the old vault personas that the separation of duties allows the retrieval of chunks from a vault while at the same time the vault is incapable of knowing the xor addresses of the chunks it holds. The neighboring nodes that manage the vault can know by keeping a lookup table to translate from xor request coming in from a client to a vault’s chunk index. The vault manager can also encrypt a chunk before passing it to the vault for storage. Is this exactly what is going on currently in the latest code? Unsure… But that technique makes farming rewards unable to be gamed unless multiple personas are bad actors that collude.


Just want to throw in that I assume that data managers need to call each chunk the same name and therefore all share this table as common knowledge - so if elders are data managers now I would still just need to be in control of one elder (maybe +a second regular vault in the same section if the elder doesn’t know its own table /only stores table)… The systematic worked well with the old more decentralised structure but elders seem to have kind of become a central authority which looks to me not capable of resolving this particular issue

1 Like

Wait a minute… isn’t last proposal that farming rewards are paid immediately on PUTs?
That for sure removes any gaming angles on farming. (An additional benefit of that solution, as well as reducing complexity, it would seem.)

1 Like

Last proposal is, that that is only for Maxwell and MVP and based on test results they will set final reward formula.

1 Like

Hmhmm - okay tbh I don’t know if that’s the case - but I’d wonder then how the new little safecoin then come into existence? - if I get paid for storing and can use that coin to store… Then there is no inflation… And if I get paid more than what I have to pay for storage there might be another attack angle again because I can have a look at the other vaults and as soon as I have 4 (or so) vaults in a section I can store chunks in mutables that are closest (in xor) to my vaults and I get the full reward…

It takes from network as well, reward is 2xStoreCost in the proposal, where half is from network. It’s in the RFC. Am on mobile.
This means fairly rapid depletion, but it is a temporary simple algo for the coming tests.


There was discussion about this here:

with little change formula to FR = 2/(4^FC) * (1/G+F/N)

And here: RFC 57: Safecoin Revised - #292 by TylerAbeoJordan

So it might work, but it looks like with less motivation for farmers to share more bandwidth and if your space is full, you will not receive anything else.

1 Like

The only reasonable action then will be to shut your vault down and restart it again :face_with_monocle:

Age loss vs. No reward at all (Well - or investing into a larger hdd)