Defense Against Forged Data

[dnwiebe]

Background
The problem is an evil exit Node that continues sending garbage data on behalf of a server after the exit Node has received a CORES package with last_data = true.

As this card is being written, GH-800 and GH-801 are on the way in to deal gracefully with honest exit Nodes from which the originating Nodes receive data after they've expressed a desire to stop receiving it; but we can still be repeatedly victimized by evil exit Nodes that continue to send us data we don't want and can't use but that well-behaved relay Nodes will charge us for and eventually delinquency-ban us.

Once GH-800 and GH-801 are in place, the originating Node will start a timer at the moment it first expresses disinterest in further data, but will continue to pay for data it receives and throws away until that timer expires--at which point it will retire the StreamKey and stop paying. This limits exposure per stream, but if the exit Node is evil, it will pull the same scam on the next stream it's called upon to exit. We need a way to malefactor-ban it the first time so it doesn't scam us again.

Solution

1. Modify the ProxyServer so that instead of using a fixed timeout, it calculates a reasonable timeout based on the relevant route's hop count, and keep in mind that we will probably eventually want to add more factors into the calculation of that timeout: for example, route and/or individual Node latency, once we start keeping it.
2. Modify the ProxyServer so that every time it receives a CORES package on a particular stream, it stamps the time and stores it keyed by that StreamKey, so that it always knows the instant it received the most recent package. (Note that only the most recent timestamp is required; it can be overwritten with each packet.)
3. When the ProxyServer's interval expires after declaring that it is no longer interested in data on a particular stream, use that stream's most-recent-data-received timestamp to determine whether the exit Node is still actively sending data or not: was the most recent data received just moments (milliseconds) ago? If it was, then conclude that the exit Node is evil and malefactor-ban it.

[kauri-hero]

A more priority and positive outcome from the solution outlined, would be creating a card that approaches point 1 and starts to track and measure average latency, using it to score routes with undesirability factors.
Although average route latency won't identify individual Nodes on the route itself since the latency is based on entire route