MASQ-Project
Reversal Mode
Note: It's possible that this card is too big and should be split.
The idea here is to provide a way for Nodes to understand propagation errors so that they can fine-tune their databases, rather than hacking and slashing whole swaths of innocent Nodes in order to get the guilty one when a transaction fails.
-
A CORES package should gain a flag telling whether it's in Reversal Mode or not. All CORES packages should start out not in Reversal Mode.
-
Whenever a LiveHop is consumed from the top of a Route, instead of adding garbage to the bottom of the Route, the local Node's public key, encrypted with the public key of the next Node in the route, should be added to the bottom. (Perhaps this addition should be filled out with random garbage so that it has approximately the same size as a standard LiveHop.)
-
Whenever a non-Reversal-Mode CORES package cannot be relayed, it should be flipped into Reversal Mode, information about why the relay failed should be added to it(1), and it should be sent back to the relay or originating Node it came from.
-
When a CORES package is in Reversal Mode, its next destination should be taken from the bottom of the Route rather than the top, and garbage pushed onto the top to fill out the route length.
-
When a Reversal-Mode CORES package arrives back at its originating Node, the information in it should be used to adjust the NeighborhoodDatabase as conservatively as possible. Note that this will probably require a new ability: the NeighborhoodDatabase will need to be able to remember undesirability scores for links between Nodes rather than just for Nodes themselves. If Node P has difficulty with Node Q, we want to deprecate the link from P to Q, but not necessarily either the links from R or S to Q, or the links from P to R or S.
-
When a Reversal-Mode CORES package arrives back at its originating Node, the Nodes on the near side of the problem should be paid twice(2), and the Nodes on the far side shouldn't be paid at all.
-
When a Reversal-Mode CORES package arrives back at its originating Node, and after the NeighborhoodDatabase is appropriately adjusted, another route should be computed and another CORES package transmitted, containing the same data as the reversed one.
Notes:
- Failure could happen for a number of reasons. The unreachable Node could be unreachable because its connection is down, or because it has been delinquency-banned by some relay Node before it in the route, or because notification has been received that it's in the process of a Graceful Shutdown, or because it has been determined to be a malefactor, or perhaps for other reasons. That information should be included in the failure message. Also, the failure message should be placed alongside the existing payload, and should not replace it. The reversing Node will not know whether the payload is a request or a response; if it is a response, it could still be useful to the originating Node. But remember: if the payload is a request, it will be of no use to the originating Node because it will be encrypted to the exit Node. If the originating Node wants to retry that request, it'll need to keep a record of the request in memory until A) the response arrives, B) the transaction times out, or C) a Reversal-Mode package is received for the transaction.
- It's convenient but inaccurate to say that the Nodes on the near side of the problem should be paid twice. First, the Node just this side of the problem (the one that flipped the CORES package into Reversal Mode) should be paid only once, since it routed only once. Second, the Nodes between that Node and the originating Node should indeed be paid twice, but the two payments will be slightly different because the CORES package that comes back in Reversal Mode will be of a different size than the original.
- Consider what might happen if an attacker starts illegitimately flipping CORES packages into Reversal Mode and returning them, even though there's nothing wrong with its neighbor connections. If it accuses its real neighbors of causing problems, it could impact their income by scaring away routing business. (Later note: this probably isn't a problem if it's the link, rather than the link's target, that gets its undesirability score boosted.)
- One of the fundamental rules for the Gossip protocol is that Node A can't tell Node B anything about Node C that Node C hasn't said about itself. This is very near the edge of that rule: while Node A is telling Node B about its own difficulties, so not technically about Node C, its difficulties are nevertheless related to Node C, so it amounts to an accusation that can be falsified. There may be some design work to be done here. Perhaps it would be good to keep track of who is reversing CORES packages, and if a reverser accuses more than one or two neighbors of causing reversals, raise its undesirability score considerably. (Later note: this also probably isn't a problem if we're deprecating links instead of Nodes.)
