shame it isent āUPLOADS aint one!!ā
It has been said that emissions work by random files being quoted on and the nodes responding correctly are given an amount. The only thing noted is the eth payment address so it can be paid during he next payment cycle.
There is nothing about the IP address or the eth address that influences the selection for payment.
Big problem with that is the 32GB was only chosen because it was 1/2 the maximum amount of space the node can consume (4MB x 16K records == 64GB).
What is to say that the nodes 5 years down the track will be consuming 48GB average OR 16GB average or even as low as 4GB. To enforce 32GB as the amount is to waste resources. While nodes are less than 16GB its better to have twice the nodes. Better distribution of the network, decentralisation, and so on.
The network does not work on space provided but provable storage of data. There is a difference and forces all nodes to maintain their data they are supposed to be holding.
Proof of data storage rather proof of providing space.
Already answered and best to not tag David unless its important. This has been answered by David and others already. By IP address only means another parameter in the gaming game. Easily bypassed and already is since most IP addresses are modest in size compared to the network size.
Also was quashed by David with similar explanation above about proof of data and not proof of storage. Very wasteful on resources if demand 32Gb storage per node.
A lot of this does influence the price and how ant is distributed so in some respects is about that. It will settle down eventually and be more strictly price/trading
Most of it already answered, but seems some just do not accept the explanations.
Yes I feel the network will shift to favour the smaller operators as the data centre storage costs will skyrocket and the smaller players will see much more value in spinning up nodes and for many the first time wanting to keep them online. Many shut down not feeling its worth it at this time and the network is in the hands of the bigger people.
Please donāt, the decision was made ages ago to make the network a proof of data stored rather than what you want a proof of storage. David has said this even in the last few days.
Is
a different mechanism than
I interpret it as the latter is for emission calculation, and the former is for identifying and shunning misbehaving nodes, correct?
Yes, very different and for a different purpose. Apples/oranges.
For node storage size argument, I am sorry to tell you David made a post a day or two ago, specifically saying that the network is a proof for data and is not a proof of storage. That was in regards to proving nodes have the storage.
The emissions is emissions and not meant to be what the network is but it is only giving emissions to those nodes that are operating.
It is neither proving storage is available (proof of storage) nor is proof of data.
Just absolutely laughable that the most ambitious project in this entire space has a market cap of a mere 12M. Hope yāall have your bags packed. This is going to be one hell of a ride when the NPCs get wind of what weāre cooking.
Ok thanks. How does the proof-of-data mechanism work? Some data is stored to a node and then later itās verified that the node still has the data, but more specifically?
Iād suggest going back through some of Davidās recent posts and he explains it yet again quite nicely.
Basically the node has to produced validated record when asked. Simple
Did this really just happen or did something break in the data collection?
https://network-size.autonomi.space/
Nope the community member who runs that site did a reset of some of his nodes he collects the data from.
Here is a more reliable figure, but no graph. Scroll down to the section āare you ready to break outā and the figure is just below that.
Gotcha. Thanks @neo . Got nervous there for a minute 
Iāll use the figures on the autonomi page.
Just to note that this number is most likely added manually on the site, because it sits unchanged for hours and then suddenly jumps.
Check out the Dev Forum
I havenāt seen an explanation how this works when there is no records stored, as is the case for majority of nodes at the moment. Do you know?
Itās quite simple. If they are supposed to have a record they must produce it. If none exist then itās fine, of course, people should not be asking for non existent records and if they do they just waste their own time.
So neighbour nodes who also hold the record will note a node is failing and exclude the node from their routing table. That makes the node disconnected from the network basically.
By hash, or uploading the entire chunk to the peer performing the check?
okay ā¦ deleted the false data timespan and switched over to different nodes for data collection (and removed the āoptimized data processingā that turned out to cause more harm than it helped ā¦ )
Whole chunk, but there is an easier mechanism we used previously and will again. The requester can then prepend (not append due to the sponge like nature of sha3 hashes) some random data and request the new hash that would produce if hashed with the existing chunk.
It reduces b/w but costs cpu, so is a trade off.
That sounds like the proof of space mechanism but applied to stored data. Really cool.
Two questions regarding this; if a node has been excluded from the routing table, is there any way back, or is the node banned forever?
Secondly; could the ban be caused because of a short network break?