# PoC v8

### Summary​

We have been steadily gathering data on the performance of Proof-of-Coverage and are ready to release the PoC version 8 update. This update brings a few key bug fixes and enhancements detailed below.

### Contents​

• Target filtering: With the introduction of hierarchical targeting we stopped checking whether the target Hotspot is actually eligible to be a target. This was largely done for performance improvements, however, we are re-introducing target filtering with PoC v8. We believe we have mitigated the performance drawbacks by limiting the target search space addressed in PoC v7. We know that there are Hotspots on the network which are not participating in any poc/reward activity for a variety reasons (offline, etc), and there is no reason to attempt to target or path through them.

• Witness RSSI centrality metrics: As the network grows we have gathered enough data to make more conscientious decisions around which Hotspots to include to when creating PoC paths. In order to do this we split the witness histogram into two buckets, one being a "good" bucket the other being "bad". The probability of picking a witness as a next hop in the path is now governed by the ratio of good vs bad counts. We believe this to be a better approach rather than simply declaring a witness as bad by looking at RSSI values. The fact that RSSI alone is not a good enough metric to make such decisions hinders better paths, and as a result we plan on adding additional witness data collection to make better decisions going forward.

• Address next hop randomness bug: Thanks to the community we identified a bug in the next hop selection algorithm where the random seed for target selection would conflict with the seed for the first subsequent hop when creating a path. We've addressed this bug by generating a random seed once for targeting, and propogating that through the target/pathing algorithm.

• Fix extremely long next hops: We've introduced a new chain variable poc_max_hop_cells which would limit how far away a potential next hop can be. It is defined in terms of h3 grid cells.

• Ensure new consensus members have latest block: We've added code to prevent slow block gossip holding up a new election round by trying to fast-forward all the new consensus group members to the same block.

• Bump assumed valid block: We've also bumped the assumed valid block to 196777.

• Adjust some peerbook gossip rules: We're trying some changes to peerbook gossip to try to keep peers fresher.

### Chain Var Proposal​

VarExistingProposedRationale
poc_version78Bump poc_version
poc_v4_prob_rssi_wt0.20.0Zeroed because centrality weight takes precedence with v8
poc_v4_prob_time_wt0.20.0Zeroed because centrality weight takes precedence with v8
poc_v4_prob_count_wt0.20.0Zeroed because centrality weight takes precedence with v8
poc_v4_randomness_wt0.40.5Increased to still keep 50% chance of picking a random witness as next hop after filtering.
poc_centrality_wtundefined0.5Introduced to pick potentially legitimate witnesses as next hops when constructing paths.
poc_max_hop_cellsundefined2000Introduced to limit max next hop distance. A rough estimate is given by: sqrt(3).a.(n-1), where, a: hex_edge_length and n: poc_max_hop_cells. For hexagons at resolution 12, ~32.5kms
poc_good_bucket_highundefined-80Upper bound for a good RSSI value
poc_good_bucket_lowundefined-115Lower bound for a good RSSI value

### Plan​

We've been betaing this release since Saturday morning and plan to release it go General Availibility this evening. We will then activate PoCv8 sometime Monday morning.