Low bid/ask risks - RFC 14 changes - protecting from network attack

[hottogo]

In RFC 14 it explains the mechanism whereby a neighborhood is determined using distance or key space criteria, it then tests to see if the bid satisfies the minimum number of r1 nodes. This test is done inside the neighborhood, where R1 minimum nodes is tested within r2 neighborhood nodes. In the RFC it said R2 is 8 nodes to form a neighborhood, with R1 being a minimum number of nodes (example was 6) having the matching ask value. I understand since RFC 14, updates have been made so that R2 is now 20 and R1 has changed since to 8.

These changes (since RFC 14) expose the network to certain risks, as instead of needing 6 out of 8 nodes (75%) at the minimum bid price, r1 only requires 8 out of 20 nodes (40%). An attack on the network to dramatically lower the required Trac to publish assets is then much easier than the previously set rate of 75%.

The other issue, not security related, is that the current change favors lower and lower bids and asks. i.e., if 50% of nodes are set to an ask of 0.4 and the other 50% of nodes are set to an ask of 0.2, the DC can lower their bid to 0.2 and it would be rare for a pub to not go through, as most neighborhoods on average will have at least 8 nodes (out of 20) with 0.2 as the ask.

This means that 50% of nodes in the network set to 0.4 ask will have to drop their ask to 0.2 to qualify for the majority of neighborhood assets. Then the same 50% group of nodes who had the originally lower ask of 0.2 could drop their ask again, this time to 0.1. Again most neighborhoods will have at least 8 nodes with 0.1, so DC can lower their bid to 0.1 and have hardly any pubs fail to go through. So the other 50% now on 0.2 still needs top drop to 0.1 to qualify for the majority of pubs. And so on and so on.

You could ask why a group would do this, but it is better to make it very hard or very expensive to attack the network than assume no one will do it. Groups such as competing protocols, malicious DC's, development teams who want cheap publishing for their clients etc.

This is also a risk at lower % intervals of the entire network at the current parameters, for instance at 40% of the network nodes, on average you would still have 8 out of every 20 nodes in neighborhoods. Now some neighborhoods you would have more than 8 and some less than 8, but you would still end up with a large majority where there is at least 8 (so would the other 60% of nodes but the DC can set their bid to match the lowest group).

On top of this, there is additional incentive for nodes to lower their ask because they receive rewards based on the highest ask in R0 (being the winning 3 nodes). So there is no punishment for lowering your ask as low as possible, as you receive the maximum rewards unless all 3 winning nodes have a lower ask than the DC bid.

I suggest that the minimum number of r1 nodes check go back to being 75% of the neighborhood, as set out in RFC 14.

Changing back to 75% doesn't mean that nodes have all the power, it is still up to the DC to set their bid and nodes can drop their ask to meet it. It just means that bid and ask cannot be dictated by a minority group, especially if that is a malicious attacker. The cost to attack the network increases, as a larger majority of nodes is required.

[hottogo]

Thanks Big Brain (telegram handle) for helping me run some calculations and to better understand some concepts.

[Valcyclovir]

To add to what @hottogo wrote above, I would like to address the issue of market forces to determine the ask / bid price.

There is an imbalance on market forces to pressure ask price down to 0 with very little market force to sustain the ask price. This is unhealthy if left unchecked as TRAC tokenonics would completely crumble if there is no logical reason to have an ask price above 0. In an environment where asset publishers are also node runners, publishers would be willing to take a loss on the node to publish assets at the cheapest price possible. They can recover the node loss by having assets published as cheaply as possible. As we've seen with 500k nodes on the network with ask at 0.00001, this is as unhealthy as having a node alliance keeping the ask price way way too high. The only market force to counteract this downward pressure is storage space. At ask near 0, node storage could be filled up very quickly rendering them useless by a "DDOS" style attack. There is no other incentive to keep ask price high and nodes / asset publishers could be easily willing to take a loss on the node to gain on asset publishing. Game theory. Moving forward, there needs to be a way to prevent a few nodes setting ask too high or too low to control the flow of assets. As stated above, a 40% requirement seems to be way too low and something higher such as 75% seems to be safer without any downside.