Should a nodes' value include bandwidth speed?

Continuing the discussion from A couple of Questions about Safecoin that's been bugging me

tldr; Should bandwidth be considered when calculating a nodes value?

This would lead to a faster network, but puts a restriction on farming for people with slow connections.

Not at all, the close-group just needs to know which nodes are satisfying the most GET requests, which will be the fastest nodes.

Sorry I don’t think I was clear. My proposal is not “Only nodes with >50% average speeds should get farming requests”.

My proposal is that bandwidth should be valued on a sigmoid curve just like vault size is.

  • If you’re below average you still earn, but you earn less.
  • If you’re dramatically above you still earn, but you also earn less (out of norm).
  • If you’re in that sweet spot 120% above average performance, you will get the optimal farming reward.

If your internet speed is far below average you’ll be penalized until you upgrade or are phased out of farming rewards ***(exactly like it’s planned to do with vault size)***, and if you’re far above you can either slow your own network to match the average, OR just wait until the network average comes up to you.

I was just thinking about the broken window fallacy last night, you and I think very much alike!


I’m not sure what you mean. To clarify my thinking:

  • The close-group is not really “close”
  • The “reader” (GET-er) may be physically very far away
  • Just one node in a group can be the fastest (or satisfy the most GET requests) and that node may do that simply because it got assigned a reasonably popular, but not too popular (to get cached), photo

That’s why I don’t believe you should measure throughput (you certainly could, as you explained, but farmers already get paid for GET, which requires some CPU, disk and network workload over time).
I think it would be correct to measure and reward the speed of completing requests, because that what the farmer can improve. They can’t improve how many “hits” they get - they can just satisfy those they do get, and they’ll never get that many to be unable to (slowly) satisfy them.

You could also create more vaults to lower your “per vault” throughput (and even increase I/O latency).

1 Like

I had a leap in logic somewhere and yes you said what I was thinking but incorrectly wrote.

That is more of what I meant instead of “bandwidth”, and I think I confused “satisfy” the request with “responding” to the request (satisfy meaning delivery to end node, responding I think meaning sending the requested info back to your close-group).

I think I confused the conversation a bit.

But yes, absolutely the nodes that respond to requests (properly) the fastest should be rewarded and higher-valued.

That incorporates not just connection speed, but also read-time from the disk drive, and cpu encryption speed.

If your close-group (xor bitwise close) requests a chunk from you, don’t they know how long it takes for you to respond? They should reward faster nodes, which in theory would usually be the ones that satisfy the GET.

They can measure it, but like I write in the other topic from which this one was split, should that measurement be considered valid?
I made some weird examples, but here’s just one to spare the trip to the original topic: I am in the UK, I read a 5 MB file, 4 chunks come from vaults in New York, Iceland, Germany and Moscow.
The fifth comes from your SSD-based vault in Perth, Australia. Despite the fact that you have a fast system, CPU, network, you get the worst mark of the 5. And you get the worst mark of 90% of the time, simply because you’re far from 90% of the users.

Maybe vaults could gather their own measurements, but in that case this guy from Perth would get stellar results (SSD) while delivering substandard service (from the user perspective).

While in each case measurements are correct, they would not be objective.

Another problem is how to ensure the veracity of data generated by the farmer and user?
It seems some of those manager nodes could sign requests and validate responses, but it’d take several engineer months to write something fairly basic.
I hope this will become available soon, but I recognize it might take a while.

1 Like

This is only the case if you deliberately construct a bad example, such as the above You can equally choose an opposite case. Neither are representative.

Since nodes in a closed group will be located at randomly (by their xor addresses) , and each vault will serve data to fairly randomly distributed users, on average better performance will be rewarded accordingly. Not always, as your example illustrates, but that’s not a bad thing anyway IMO.


Yes, I constructed a deliberate edge case scenario to illustrate scenarios that make the implementation more challenging than simple Vuze stats.

The best approach would probably be to measure it end to end, but also the most difficult to implement. It’s reasonable to focus on key features first and do this later on.


Hey where did this graph come from? It’s very awesome

1 Like

You cherry picked a case to try and make a criticism that is not valid, for that reason. As I said, I think it’s a good thing that high performing nodes can’t win all the time, so your edge case can be used either way. It’s not objective, or representative, whereas a statistical analysis shows us that on average - just as with how Safecoin are allocated - better performing nodes will be rewarded more highly than worse performing nodes.


Probably vital actually :wink: We must imagine the Iot or whatever its called all being involved. Speed is very time related in terms of our own time line I mean, exponential growth in speed of b/w cpu etc. all become part of the picture.


To me it is a difference in opinion (preferences, or values, or maybe product strategy as it relates to decentralization).

I don’t think there can be invalid choice in that because neither decision is clearly damaging to the system: one provides better performance at the expense of potentially excessive centralization, the other gives up on the maximum performance for the sake of better stability.
One day there could even be multiple SAFE networks with small but important differences only in these key parameters, each focusing on a different market segment.


The Safecoin chapter of the SAFE Network SystemDocs


Also this.

We’re using the average on the sigmoid curve, all people with any sort of reliable computer and internet connection will fall within a small range of the network average.

Slower-than-average nodes will still satisfy GETs in the conditions the faster-than-average nodes can’t (maybe all nodes are on the same continent so no cross-sea connection lag, or some other perfect race condition), which is good because they’re still performing that specific response better than all other nodes.

But that slower-than-average node is still under performing, because even though it satisfied the GET, it did it slower than is possible (based on the network average). And so that farmer loses a slight chance in farming.

It’s a negatively-reinforced incentive to upgrade by telling him he’s being slowly phased out.

In terms of the technical aspect:

Far be it from me to recommend adding any sort of functionality into the network (we <3 our core devs), but the requesting node could respond to the fastest node’s close-group and tell them they were the fastest (verified using the hashed chunk with the delivering node’s public key, or something).

Instead of measuring every single request, just let the close-group track out of how many GET responses were you successful?

I guess my stance is:
1) Why reward under-performing nodes?
2) This “crippling centralization” will not happen when using the network average node speed

You agree, which example case is chosen will be subjective… Hurrah! But coming to your assertion above, I don’t understand… Please explain to me how a system, which guarantees on average to reward higher performance nodes more than lower performance ones, will deliver less performance than your “better” example which measures every case but achieves the same effect.

I actually think it will be worse performing, so please explain why you think it will result in better network performance. Both cases reward higher performance nodes proprtionately, so I don’t understand why you think there will be a difference in this respect.

I commented on that on the parent Topic: if you reward the average (and above), nobody who’s below average can get any requests. You could loosen the criteria a bit and say “the bottom 20% doesn’t get any requests” to make only the bottom 20% improve or leave, but the moment you stop rewarding any vault except the fastest, you’re effectively rewarding under-performing nodes.
It seems you consider “under-performing” to mean “below average”. That’s an interesting way to look at it. I’d just call them 'below average", and anyone but the fastest would be “under-performing” :smile:
I guess this terminology made us talk past each other a bit :smiley:

I am wrapping things up after an all nighter and I had to read this question 5 times to understand it, but I won’t leave it for later:my claim was that rewarding anyone but the fastest of the 4 replicas for each chunk will get you a lower performance than if you always direct your request to the fastest replica for each chunk.

I don’t see a problem with that logic, but that’s maybe because it’s almost dawn here.
If you are fetching 5 chunks and on a relative scale 1 to 10, chunks 1, 2, 3 and 5 get fulfilled by vaults with a relative grade of 8, 9, 10, 7, while chunk 4 gets fulfilled by a vault with (latency/performance) grade 6, your overall speed for the file/object will be 6.

If you only ever send requests to the highest performing vault for the chunk (or highest performing vaults overall, the top 10% on the network), all chunks 1-5 get delivered by vaults grade 10 (the highest grade for the chunk). I can’t see why it would be slower than any other combination.

1 Like

But the close group may be faster or slower based upon completely random, and changing factors. Remember that “close group” is related to address range. Member vaults could be very close or very far in terms of physical distance, access to high throughput connections, etc. So it seems to me that such metering would not be meaningful. @happybeing has a really good point, and David reinforces it. On average a faster cpu with a better connection will have a marginal advantage just because it does its work faster, but in no particular or predictable metric relating to the changing environment that it’s operating in.


Is the physical build out of the network on increasingly SAFE only or SAFE optomized hardware a priority? Is that counter productive? But how can it be avoided?

1 Like

The idea is commodity hardware is preferred AFAIK and this means as much inclusion as possible which in turn means the more specialised you are the less effective it should be. Bad for those who want preference but probably better for all in longer run.


What of stuff like FOSS small shop printable (on fabber) hardware that may be SAFE verifiable? It would be potentially commodity and specialized.

1 Like

It should not be to run a vault per se but to advance sharing of data/information in a way that advances knowledge. That’s where I get off, all I want is to be able to ensure we all learn, so basically stuff we use to produce consume is specialised enough and SAFE fits in there.


Its starting to sink in I think that the new money is the network and data. Its seems global finance is about to get very very pushy about this. 22 more banks joined the big 9 on the r3 bit coin standard. The network is the money and they think they own it or are entitled to control it. It used to be their formula was money is power now its money is data which is power. Now it seems we will just rent their global currency. Because that is what this new bank bit coin is, its a global currency that will become exclusive and replace all cash and cash equivalents so no matter where your money is they can charge negative interest to hedge deflation (while paying themselves) and program inflation automating away the fed and make sure treasuries can tax to protect their power. On their money network (internet) we are just a tenant and they make the rules.

1 Like