With 5773 chunks, there is like up to 28,865 nodes with a chunk of the file on them
Seeing as the network is only 90,000 nodes then there is the chance that up to 1/3 of the nodes has at least one chunk. And any large node runner with 2000 nodes has a high change of having all 5 close nodes in their “farm” for at least one chunk. If they remove their nodes/restart them/etc then bye bye chunk
When you strip away the idea of let’s create an atomic 
#1nano=1NRS=1TX=1LOL
You end up with a Kb of NRS that maybe could be registered @ free market prices on this 100K + nodes network.
It would be fun if I could import my $1 Tether stuck on omni protocol and not to mention my bitcoin dust.
If storage is the only game that we play… 
@riddim That queen comment is gold 
be sure to ask me for your 1 nano like
on it its saying that 127 chunks fail to verify
safe files download "linuxmint-21.2-cinnamon-64bit.iso" 36dcf903ccd7d4ff67c097eb4d62063bed6be8448baead8d86c3fa0548bb8aa1 -r persistent
Same here. I tried different batch sizes and it always fails on this.
same here but different chunk
b870e2(10111000)
Even batch size 1 fails for me on that same chunk
Would it be possible somehow to avoid chunk copies being stored on the same IP, if nodes can do a local search for other nodes, or if there are other ways?
Isn’t this a significant issue that might need some solution? @dirvine
yet another chunk
Error downloading “linuxmint-21.2-cinnamon-64bit.iso”: Chunks error Chunk could not be retrieved from the network: 5246f9(01010010)…
Yeah, we know about that chunk
@aatonnomicc have you tried uploading again? If we only have a couple of iffy chunks then it should be quick and fairly cheap, no?
Iv reupload it about 5 times already I can do it again if you think it will help ?
When you tried the reupload, did it say some huge no of chunks already exited on the network and did it charge you only for the previous failures?
If you tried 5 times with much the same results then its prob not going to work on the sixth attempt.
going for round 6 ill post the results
Three downloads on different boxes (2 cloud, one home) failed but with different chunks this time, one on the second last chunk
Chunks error Chunk could not be retrieved from the network: 529e72(01010010)…
Chunks error Chunk could not be retrieved from the network: 529e72(01010010)…
Chunks error Chunk could not be retrieved from the network: e1b28c(11100001)…
Time to moan mightily about Autonomi not giving us some specific files to download.
round 7 in progress
insert something here about the definition of madness…
Anyway, something is still not right - we need a wider variety of downloads to check.
And to do that, we need nanos for testing.
And to think they intend to release this in 5 weeks… effing mental.
I am having a go with round 8 using the persistent flag
safe files upload -p linuxmint-21.2-cinnamon-64bit.iso -r persistent
So it sounds like the issue is that the network knows that the chunk is supposed to be available because it’s been uploaded before. That’s great. But there is no checking that the chunk is actually retrievable. That’s a condition that needs to be accounted for - even if the condition is supposed to be avoided. That will be difficult. It would mean having to do a read verification of the readability on every chunk for an upload on the reupload. Maybe there would have to be a way of marking a chunk as suspect and requesting a reupload.
Not without changing the closest “5” algorithm.
One alternative way to help is for safenode manager to reject any node that spins up with its xor address too close to others already running. If it assumes a decently sized network then close nodes are quite close in xor space compared with a random generation of xor address (well random secretkey generation giving a xor address)