Awesome! Thank you for this clarity. I had not grokked the below. On Mon, Oct 28, 2019 at 01:33:29AM -0400, grarpamp wrote:
GPA was monitoring the upload, thus why GPA attacked X (and others in their target set), and due to the [temp|full] link dropout (latency trough), GPA IDs node X as the uploader. But, same problem even if link not dropped, and just a latency trough - target X, is now IDed by GPA. In both cases a) X's uplink dropped, or b) not dropped, there destination of X's upload, sees the [temp|permanent] dropout.
No. First principles... under a proper enforced and regulated background of fill traffic network, there is no such observables for GPA to monitor, so nothing to attack (which a GPA doesn't do), no ID to be made.
Now if a GAA is an agent running the central server receiving the upload, and they're fast enough to recognize the content on their filesystem as such before it completes, they can try to DoS back their own overlay hops toward the uploader in realtime.
At first that would seem hard to defend against.
Then you realize that again, a proper fill contract aware network will auto detect and depeer any link that gets DoS, thus the upload stops well before it can ever be tracked back. And GAA has to literally sweep through the entire overlay spiking at tens of thousands to millions of nodes (because every node is a relay, linear search odds) trying to find the point source that causes the server upload to stall. And if the user has selected a higher hopcount for their side, odds are that much higher that GAA will spike one of those first again depeering the path and ending the upload before discovery.
The upload might continue a bit slower in a multipath or scatter mixnet, or if either the depeered node renegotiates back in, or the source repaths another circuit around. Whichever way the GAA has discovered nothing and is back to step one at that point... the depeering problem.
Nodes might publish a number of depeering tolerance parameters, or network metrics seen of peers, such that clients could use them when constructing paths on continuum from more reliable to more secure as desired. The particulars of what observables drive depeering thresholds should be, and whether an overlay can perform whatever self management tasks well... all need tested out.
Regardless, sensitive users should not upload to any plausibly owned / suspect / scene central servers, and instead should insert into any distributed encrypted file storage overlays, IPFS, generic surface websites or hosts, upload encrypted blobs and release the keys elsewhere, use wifi, vpn, etc.
Any candidate network for any nextgen award in the subject line should raise the bar significantly such that only the highest sensitive and smallest number of users would have reason to argue.
That is simply not the case with today's networks.
incentivize
Incentive is that secure network platforms provide generic transport for cool apps and services that people want to use. Most users are not going to hack their nodes to disable giveback, and or the network will detect that, or have natural consumption limits. Again ventures into generic transport network built for mass utility vs network built for some specific app or class of app... the former has probably not yet received its fair share of development consideration over the last decades.
As before, have fun creating and deploying new stuff.