Ensuring trust for non-Helium hotspots (HIP draft, DIY gateways)

[vihu]

WIP

Rendered view: https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md

[andresbonilla]

One drawback is that all new hotspots (including helium manufactured hotspots) would require an existing trusted hotspot within range. This represents a massive barrier to adoption since most people aren't within range of a trusted hotspot.

[tjain-mcc]

I think we'd have to create a scalable process to approve hotspots to be level 3B to solve this

[andresbonilla]

@vihu Why do Helium-manufactured hotspots also require a probationary period if you're assuming they're "trustworthy by design"? Allowing them to bypass probation would solve the problem of people not being able to join the network because they aren't near a trusted hotspot.

[vihu]

@vihu Why do Helium-manufactured hotspots also require a probationary period if you're assuming they're "trustworthy by design"? Allowing them to bypass probation would solve the problem of people not being able to join the network because they aren't near a trusted hotspot.

Thank you for the feedback and absolutely right you are! Helium/authorized resellers will definitely be bypassing the "probation" mode. I will be updating the wording shortly.

Also, note that this PR is a WIP draft, mostly just collecting notes from some of our internal meetings and is nowhere near formalization/completion. A lot more details and changes are to be expected as we go forward.

[cokes518]

There needs to be some number of Hotspots at L3 so challenges can be created, the rest should be L2? We need to decide the criteria to bless existing Hotspots as L3 in the new world.

[tjain-mcc]

Some comments/questions:

1. What is the purpose of splitting up 3A and 3B?
2. I think Level 4 hotspots should not based on staking a fixed number of HNT. Rather, Level 4 should be the top 1000 stakers of HNT only. That way the staking requirement to be Level 4 varies with the amount of HNT outstanding.
3. There needs to be a significant unlocking period for Level 4 hotspots. Otherwise they can mess with consensus and immediately withdraw their HNT to sell it
4. I do not think the way hotspot score works today is reliable enough to demote hotspots.

[vihu]

Thanks for the comments @tjain-mcc

What is the purpose of splitting up 3A and 3B?

Both 3A and 3B share the exact same level privileges, the only difference being that the way you get to A/B differs. Furthermore I think that we may distinguish the demotion criteria between 3A/3B but that's TBD.

I do not think the way hotspot score works today is reliable enough to demote hotspots.

Agreed, we have begun adding a lot more information to the POC txns in order to gain more insight as to what constitutes a valid POC receipt. For example, transmit_time, recv_time, time_accuracy, location_accuracy; much of these are coming from the GPS.

Furthermore, I'm certain that individual levels will also serve as a metric to an updated scoring algorithm which would factor all of the above. I will update the post to reflect that, however, it will be a separate undertaking from this.

[tjain-mcc]

We should probably do a phased roll out where we first enable staking, and once we hit 100 hotspots staked we roll out the rest of this HIP. That way we will have enough consensus candidates to prevent a chain halt.

[laughingsquirrel]

I am concerned with the value of a level 4 stake being set at such a high value (currently reads 10000HNT) will dissuade hotspot owners from joining the network as value of HNT rises. A defined dollar value equivalent staked in HNT would provide a more stable definition The terms of the stake also need to be very clear and straightforward as the value of staked HNT could be very significant particularly at patron/commercial scale.

[Carniverous19]

@amirhaleem thanks for the reply. I think what you mentioned is a different potential exploit than the one I am talking about above. If someone could direct challenges to be designed in a specific way that would be a concern although that would be independent of if the hotspots involved were all Helium manufactured or a miner connected to packet forwarder proxy as I described.

To demonstrate I desrcribe a situation where a go-getter patreon does it right and deploys real hotspots in their neighborhood. This is something that many people, especially patreons, have done to increase earnings and I believe would be encouraged by Helium. Then I describe how the exploit can earn the same increased rewards with only one 3rd party hotspot.

Real Hotspot Example demonstrating benefit:
I believe you would agree that someone buying 20 Helium hotspots and deploying them throughout their neighborhood with roof mounted high gain omni antennas would certainly earn a lot more HNT than someone with only 1 Helium hotspot in the same region (no gaming just normal network / POC behavior). Assuming all 20 hotspots could communicate with eachother they would earn even more than 20x a single hotspot since some normal challenges would bounce between these 20 hotspots. Sure some challenges may go to other nearby hotspots not deployed by this owner but some reasonable percentage will involve multiple hops to these 20. This should be rewarded as it provides verified reliable RF coverage over a large area. Modesto, CA is a (very large) example of something like this.

Malicious Miners + python script simulating above
Now for the 3rd party hotspot exploit what I am saying is to do exactly the situation above except instead of 20 hotspots and antennas setup in a neighborhood coordinated with different property owners, I am saying create a python script to take data from a single hotspot/roof antenna and send the packets (with modified gps location, concentrator MAC address, etc) to 20 Level 2 miners running in the cloud.

These 20 miners will receive real packets over RF and transmit real data over RF they just share one concentrator / antenna / physical location.

Takeaways
All it would take is a malicious python script that does the following:

• Receive real PUSH_DATA packets from a concentrator and for each of the 20 miners- modify the gateway MAC address (to appear unique) and forward the modified PUSH_DATA to the miner. This now ensures 20 miners can receive real RF data and any data received by the concentrator will be received by all 20 miners even though we dont know which miner is the intended target (if any).
• Periodically send "PULL_DATA" messages to the 20x miners (with appropriate gateway MAC). Store and forward any PULL_RESP messages from miners to the concentrator on its next PULL_DATA request. This allows all 20 miners to transmit real RF data so they can participate in challenges with real hotspots in the neighborhood.
• for any PULL_RESP received from a miner, create a dummy PUSH_DATA message with simulated RSSI / SNR and appropriate timestamps and send to the other 19 miners. This allows the 20 miners to communicate with each other with 100% reliability but appear to be over RF.

This does not require knowing the intended recipient of any received or transmitted packet. It also does not require the ability to pick challenge targets or next hops, normal Helium POC behavior is fine. The "Malicious Miners" exploit will behave and get rewarded very similarly to the "Real Hotspot Example" but with much less investment and without providing redundant wide RF coverage.

The proposed exploit would allow all 20 miners to meet the requirements of Level 3A (really even Level 4 with staking fee) and I believe undetectable with this proposal.

Note: I used 20 as an example and this number may be detectable based on the physical distance this must cover, but some number of hotspots is possible with the reward for this exploit ~ linear with number of malicious miners. Without requiring GPS synchronized hotspots the ability to use ToA to identify misplaced hotspots is also diminished meaning this exploit can use a wider area and more miners per concentrator.

[amirhaleem]

@Carniverous19 that's not quite correct. you cannot simply replay PoC packets and have them be valid - the packets are encrypted by the challenger such that only specific recipients can decrypt them using their private key. Your Python script would not be able to decrypt the packets and therefore not be able to submit valid receipts back to the challenger, so no mining or increase of level would occur.

[Carniverous19]

The python script does not attempt to decrypt the messages there are still 20 miners running in my example that take raw LoRa packets that are encrypted as input (from Semtech packet forwarder) and forwards them in the same format as the Semtech packet forwarder to the 20 miners on port 1680.

In the top diagram in Helium's Build a Hotspot page this python script lives in the middle of "Semtech UDP" between "Packet Forwarder" and "Helium Miner" Not in the "libp2p" side which is where the payload may have to be decrypted / understood or at least signed. This script does not attempt to replace the miners, it allows a 1:many relationship between concentrator and miners.

My proposed python script doesnt touch or even look at the contents of transmitted or received data. Data could be cargo payloads from developers, PoC challenges for one of these 20 miners, PoC challenges for some other miner, or non LongFi traffic that happens to be using the same channels as Helium. No knowledge of the source or destination is required, all it does is transparently multiplexes 20 miners to 1 concentrator (and vise versa).

The interfaces of the packet forwarder are well defined and easy to implement from: PROTOCOL.txt

I'll code up my proposed python proxy and post it. I already have a crude version forwarding data from a single RAK7243 gateway to multiple miners, I havent done the transmit side yet.

[amirhaleem]

@Carniverous19 totally understand the vector you're describing, and we know the packet forwarder well. The point is that submitting 20 copies of the same message doesn't actually benefit you in any way, or help you improve level. The only way to improve level is by participating in Proof-of-Coverage challenges directly with gateways of level 3+. If you can't decrypt messages (because they weren't intended for you), you can't improve level.

Because the miners each have their own key, simply splitting the same packet to 20 miners with different keys doesn’t help you any more than having one miner running. Only 1 of the 20 will be able to properly decrypt and improve their score. The key point that you are missing is that random packets do not count towards proof of coverage or your ability to level - they must be proof of coverage packets encrypted for the private key of one specific miner instance, or they are useless.

[laughingsquirrel]

@amirhaleem but if you have 20 'virtual' hotspots tied to a single radio all 20 of those hotspots could participate in their own PoCs individually via the same radio. The other 19 would simply drop the packet. I believe what he is talking about is not hijacking a packet and re-routing it but simply rebroadcasting the single stream of signal from the packet forwarder to every one of the miners (simply by copy the UDP packet and re-routing the copy to a different port on the miner server) just like if they were all sitting within range of the original broadcast and their own individual radios picked up the message on their own.

[Carniverous19]

I guess the key is the packet forwarder gives a method to communicate over ip/udp instead of over longfi. There are many ways this can be used to earn higher rates of HNT without providing corresponding RF coverage.

The key advantage to the malicous actor described above is not submitting 20 copies of the same message but having 20 eligible targets for PoC with minimal hardware investment. PoC's really go from miner to miner with the assumption that each miner provides its own RF coverage. So there is an advantage to having 20 miners vs 1 miner even if they are staked in the exact same location.

For example next hop calculation is somewhat evenly distributed among those hotspots in the witness list. So if there are 5 real hotspots (named A, B, C, D, E) that can all witness eachother and a challenger selects hotspot A as initial target for a PoC, hotspot B has a ~25% chance of being selected as next hop (I am oversimplifying the next hop algo but this is representative). If hotspot owner B wants to earn more HNT they can implement what I describe above and now there are 25 hotspots all within witness range of eachother called A, B1, B2, B3... B20, C, D, E. Now again hotsot A is selected as initial target and the challenger randomly(ish) decides next hop. one of B1...B20 has an 83% of being selected as next hop 20/24). Same story for hotspots C, D, E as targets.

Also initial targets for PoC are selected somewhat evenly random, so hotspot B has a ~ 1/ 4,400 chance of being selected as an initial PoC target. But implementing what I describe above each hotspot B1, B2... etc has a 1/4,400 chance of being selected as a target so owner B has a 20/4419 chance of being selected as an initial target for a ~20x increase in being selected as PoC target.

Both of these advantages seem worthwhile in implementing the proxy and that is excluding additional gains by spreading out the staked locations so hotspot B1 and B3, etc can be in the same PoC path.

Edit: yea what @laughingsquirrel said

[laughingsquirrel]

@Carniverous19 your theory would work best in a 'closed' environment such as a rural area where your 'locations' are all set in areas that are outside the range of anything but your own hotspot and you own the only 'real' hotspot in that area to challenge. For example, the middle of Canadian wilderness or an island. The only potential way for it to be disrupted is if someone put a third party hotspot within range of one of your virtual hotspot locations and then your challenges start to fail. Shoot, right now I could do that in most of Delaware and the eastern shore of Maryland.

[Carniverous19]

@laughingsquirrel I dont think it would fail, again all miners have access to a concentrator / antenna so they can send and receive real RF packets. Any transmit command from a miner will be transmitted over RF so nearby 'real' hotspots will receive the transmissions.

with how much variability there is in how well LoRa works (due to sender / receiver antenna gain, placement, buildings and elevation changes). I think a high gain omni on the roof could easily cover the same area as 20 stock hotspots placed indoors in someones window. Could you really tell the difference?

What I describe above still needs an actual gateway / antenna, the key is you only need one but you can share it with lots of miners getting the multiplication of earnings

[clendaniel]

@Carniverous19 Played with this for a few minutes and without munging the gateway ID I was able to easily proxy inbound udp on 1682 to two miner containers running on 1683 and 1684 using socat and they seem 'happy'. It's fragile and has obvious flaws but I think shows what you're talking about.

socat -u udp4-listen:1682 - | tee >(socat - udp4:127.0.0.1:1683) >(socat - udp4:127.0.0.1:1684) >/dev/null

[amirhaleem]

Ok, I think I understand what you mean now. You’re basically increasing the probability of being targeted. @refugeesus is going to illustrate some of the other changes planned for PoC that will (hopefully) make this not particularly fruitful.

[refugeesus]

OK my handwriting is bad so I'll type out again here.

Ex1 is our set with multiple challengees, all with unique miners using unique hardware. These two examples are to show variable resolution of challengees in the observed set. Because all of H(Y) have independent hardware, the sets of challengers, challengees, and witnesses, will include all hotspots in the space H<X,Y>, with exactly one sample H(Xn,Yn) for every n. If every link is covered in the set, that would be the maximum possible outcomes and describe the probability space in its entirety. Not likely to happen for a multitude of reasons, but the healthier the network the closer this approaches 100%.

Ex2 is the same set space, but one or more of the challengees is virtual, or fake, whatever you want to call it.
The key difference in the result is there will always be (n-1) sets of missingness between the virtual miners, for n number of virtual miners shared on hardware.

To expand on this, what if there were multiple virtual miners n for multiple pieces of hardware m and to keep the "doing this to save money and increase chances of being rewarded" policy, n>m, and really n>>m.

OK, and this tricky individual also wants to be as confusing as possible so the miner<->hardware association is switched at random. Good news for us is the occurrence of samples with H(Xn,m,Yn,m) will still contain missingness for the difference between n and m, and when the association is broken, there will also be samples in each challengee's datasets which have differing means and variance, which would show us a a non-standard distribution. It would be even more apparent when including a virtual gateway in a set of many sets as the included list of hotspots increases.

Now the "inner" edge case m->n, which does make this behavior harder to show in large sets... but we want m=n. Ultimately, if the distribution changes modality as the observation space changes, there is outside interference.

[Carniverous19]

Ok I'm struggling to follow your notation (due to it being a long time since I took proper stats...).

I'll keep looking at it, but are basically saying you would observe missing links between virtual miners? ie virtual miners cant communicate with eachother?

Can you give an example with say real hotspot (1:1 miner:hardware) A, C, D, E, F and 3:1 miner:hardware B1, B2, B3 with all hotspots being able to receive eachothers messages?

Although hardware cant receive its own transmission it is easy to take the transmit command and create a receive packet from that fudging rssi and lsnr (and timestamps if needed). So miners sharing the same hardware can appear to communicate with eachother.

Basically its possible to have 100% receive for all transmitted packets across all miners regardless of miner:hardware ratio.

EDIT:
So basically my pretend proxy code will do 3 things (+2 optional):

• Send any packet received by the single hardware to N attached miners
• Send any transmit command from N miners to the single hardware
• Loop back any transmit command from transmitting miner to N-1 receiving miners as a received packet
• (Optional) fudge received packet metadata, hardware MAC, add randomness to RSSI / LSNR
• (Optional) randomly drop some % of packets going to each miner so they dont have identical behavior

Its hard for me to see how this would be detectable as it would be identical to what happens if actual hardware was in place. What you may be able to detect is the real hotspots will have very similar witness histograms for all of these virtual hotspots since the RF path between will be identical. I am not sure if this would be sufficient to really say this is a on 1:1 miner:hardware or just closely located valid hotspots having similar setups and behaving similarly.

[refugeesus]

1. Are B 1..3 unique hardware? Maybe I can make some fake data and add it to an example set with real data.

EDIT:
If I am going to make a sample graph analysis for this it is probably better to just do 1, 3:1 hotspot in a set because it starts to get messy visually.

2. The first three parts of your proxy code are the assumed behavior. Fudging rssi and snr, over samples n large, in a way that behaves naturally (respect to the local environment) would be a feat unto itself since this is a continuous outcome problem. The sample data contributed by other hotspots >> than what is observed by the hotspot under inspection. Essentially the virtual hotspot would continuously have to know what appropriate signal conditions would be when it was challenged.

If there are other hotspots in your set of observations which do not align with the virtual playback data, two or more distinct groups are going to be organized. We run back into the problem of having two non-intersecting sets of hotspots in one set of data.

There is always the island problem until some interference occurs though.

[Carniverous19]

Are B 1..3 unique hardware? Maybe I can make some fake data and add it to an example set with real data.

No, sorry B1, B2, B3 are 3 miners sharing the same hardware in my example, this is the "bad actor"

Fudging rssi and snr, over samples n large, in a way that behaves naturally (respect to the local environment) would be a feat unto itself

I remember looking at RSSI before and a lot of witness RSSI was very low like -121 to -116 regardless of point to point distance. Setups are so variable and environmental factors play such a big part, I think it would be hard to say "two hotspots 0.4 miles apart witness eachother at -122dBm but another hotspot 8 miles away witnesses both of them at -112dBm and that's invalid". I remember seeing stuff like that all the time.

Option 1: everything gets poor reception (but reliable communication)
Because of the observation above, one option for simulating RSSI between virtual hotspots sharing hardware is just to set it low such that the minimum is just above the poc_good_bucket_low chan var or a realistic floor like -121 whichever is higher. You could also ignore RSSI and SNR readings from all actual received messages (real or simulated) and just set all RSSI randomly from -121 to -116 for all data going to these miners, so real and fake data all appears low. (Same idea for SNR I just dont have good dataset to look at yet). Also for "randomly choose RSSI" I am guessing there is some empirical distributions that could be followed so the histogram appears in-family with "real" histograms, some skewed normal I'm guessing.

Option 2: Stake on top of eachother
Embrace that these virtual miners will not be able to be in the same PoC path and stake them all on top of eachother. This makes their similar behavior much more valid. When they "hear" eachother just give very high RSSI and SNR like -50dBm and 9 SNR. This makes them ineligible to witness eachother or PoC in the same path but still gets all the benefits I mentioned HERE being more likely to be selected as initial target for challenge and more likely to be selected as next-hop for nearby 'real' hotspots. Less valuable of an exploit but still getting a good multiplier. This is also a situation where it is easy to simulate the signal between these fake hotspots as the distance are so close.

I admit, my knowledge of stats is pretty poor and the datasets I have looked at are much smaller than what you have access too but from what I've seen there is so much variability due to environmental factors I think it would be difficult to say with confidence that there are miners sharing hardware vs intricacies of RF and setups. I looked at RSSI pretty extensively before and determined its only good for detecting hotspots that are on top of eachother anything below like -115dBm could be 1/4 mile away or 30 miles away.

Finally fudging RSSI/SNR can be a bit of a continuous chase. What I proposed above is two options, and it may be possible to identify the above as not valid, but there are more advanced methods to attack this as well and a malicious hotspot owner just has to stay a few steps ahead to benefit. I think the sophistication required to confidently detect these types of miners is significantly higher than the sophistication required to improve the exploit. With everything recorded on the blockchain everyone has a large dataset of real-world data to build models around (I'm too lazy to do this but its possible).

[Carniverous19]

Stepping back a bit, I think what is important is that the proposal in this HID may be sufficient to prevent 3rd party hotspots to build a completely virtual network it is not sufficient to

make it safe for LoRa gateways of unknown origin to participate in Proofs-of-Coverage and earn tokens for that participation.

The situation I described is one example of it not being safe to allow 3rd party hotspots for PoC as PoC stands today. Maybe should add a requirement that PoC is designed to such that many miners : few concentrators (and other known methods to artificially increasing earnings) dont significantly increase earnings prior to allowing 3rd parties to participate.

[laughingsquirrel]

Is it possible that we are looking at the wrong angle here by analysis of the 1:many configuration which is based on using one single RF antenna and what we should be looking at is the real impact on PoC design. Rather than code around the problem by analysis of the RSSI/SNR to identify potential bad actors shouldn't we be looking at how to reduce the motivation/benefit for the configuration.

If the frequency of hotspot (miner) selection for a PoC challenge is designed in such a way that:

1. When a concentrated area of hotspots is selected to be the target a random hotspot in that geographic area (assume 2-3 mile radius that could be easily covered by a mid/high gain antenna for this exercise) is selected for the challenge target the subsequent targets in the challenge are selected at a minimum geographic distance sufficient to push the limit of this grouped scenario and reduce 'internal' transmission within the virtual miners nearby staked locations.
2. The defined minimum distance selection is variable within a range of values so that testing of the PoC logic by a bad actor would not show a consistent clearly defined distance between staked locations that would be required to increase potential selection for PoC.
3. PoC target selection frequency in the defined geographic area is limited during a defined period (by epoch?)
4. Witness comparison of RSSI/SNR of broadcast packets received from targets within a margin of error are rejected with the assumption that they are broadcasted by the same transmitter (continued rejections trigger demotion).

We can discuss the ins and outs of this scenario forever and model signal strength logic for spoofing the hotspot locations but the simple fact is there is an inherit limitation of this model that is the single radio transmission point which has physical limits so if the region that malicious miner participates in does not see increased PoC activity during a period just because there is a larger concentration of 'hotspots' there would be less return on investment because the single radio providing service is what we really care about with proof of coverage. There is zero benefit for the 1:many on the DC side so the only benefit really is if there is marked increase in PoC participation.

You are never going to weed out all the bad actors without locking down and centralizing the control of the network so reducing the geographic selection frequency and therefore reducing the opportunity for a single area to earn an out sized portion of the PoC credit during an epoch will reduce the motivation to game the system.

[refugeesus]

I agree with @laughingsquirrel here. Any approach should be taking a network view rather than the analysis of the actions of one hotspot.

EDIT: grammar/clarity

That said, the thought experiments are interesting and I still believe constructive. Happy to discuss the details of any methods being developed over in discord @Carniverous19 & @laughingsquirrel. We can work through this in detail in the PoC channel. I understand the concern and confusion surrounding RSSI, SNR, and how these measurements can be applied. My best short explanation right now would be that they are by definition, dimensionless, so the value itself cannot be extrapolated to another medium. However, differential measurements could be useful.

For example, RSSI and SNR as they apply to each radio individually over time can be related. Consider a scenario in which RSSI and SNR change for receivers on buildings on a foggy day (happens a lot in SF). Much of network back-haul is provided over microwave links, as fiber was not widely integrated until relatively recently (however this concept still applies to optical links albeit different interference). I really can't say much about why one building has values -30dBm in difference from another building right next to it due to confounding, but I can quantify the association between receivers and fog.

[Carniverous19]

Happy to move to discord, probably a better place to discuss, I get what @laughingsquirrel proposed although again I think its hard to do in practice while 1: encouraging healthy growth of the network and 2: not really screwing over existing customers.

Some thoughts on your proposal:

1. I think is already implemented, initial targets are chosen at random and randomly selecting within a geographic area still benefits the exploiter as they control are larger % of hotspots in the radius so are more likely to be selected. Additionally they already require additional targets in PoC to be in unique hexs thus geographically spread out in distinct regions. There is a balance here on allowing hotspots with short-ish range to still do multi-hop PoC and preventing exploits. This number can be tweaked but I dont think you can make it large enough without stopping lots of honest hotspots from doing PoC. Helium hotspots ship with a decent but limited antenna and they encourage indoor installation. This could have 1/10th the range of a high gain omni on a roof.

2. This range couldnt be secret, likely would be a chain variable so a malicous actor knows the bounds and could set distance just outside maximum or at the mean and accept a 50% chance of being too close.

3. This is possible but may not encourage a healthy network, some environments need higher densities than others (Manhattan for example is ~13 miles x 2.5 miles with 300 hotspots and there are likely still lots of dead zones). A maximum HNT/area/epoch for all regions wouldn't really work to encourage growth. Note you could say areas like SF and NYC are already well saturated so you dont need to encourage growth but pretty much all other cities are far from saturated and you need the promise of PoC earnings to build a suitable network. You could assign a HNT/epoch rate to each hex but what do you base that on? population? customer interest?

4. I think this is very hard to do reliably. As I mentioned above there are lots of witnesses with poor RSSI and SNR regardless of distance. I think the noise / variability in these readings are too great to reliably say "this is a fake hotspot" without risking significantly penalizing honest hotspot owners. It will be interesting to hear more from @refugeesus about the feasibility of using RSSI and SNR to reliably identify a mismatch of hardware:miner. If it is possible I think it also would only work in very dense areas. Most of the country outside of NYC and SF is still well under healthy density of hotspots so if you are in LA or Miami in an area with only 2-3 hotspots in witness range of you I think it would be easy to add 5-10 miners in that area and do a good enough job simulating RSSI's to not be reliably flagged as invalid.

[GP-Colorado]

1. If there's to be a staking requirement, why need it be specified with a fixed amount of cash or HTN, the value of which, in purchasing power, will change over time, due to growth/contraction of the net, competition yet to develop, and inflation? Would a criterion of being in the top X% of stakes be better?

2. Is a staking requirement essential? A new person coming along and looking at the distribution of new tokens sees that a substantial chunk goes to the founders/backers. Having another 6% be unavailable to most owners, no matter what effort they might make to follow the rules and help grow the network, because they can't afford a prohibitively high stake may not line up with what a person of modest means expects of something advertised as "the people's network". It might also grate on some current owners to see the percentage potentially available to them dropped below what was in the illustrations shown to them when they bought-in.

3. Does this suggest that the cost of moving a hotspot to new location would be increased from $10 to $40 or is it a typo? If truly proposing a quadrupling of the assert location fee, I think such might be excessive.

"Level 2: Network ParticipantA hotspot must satisfy the below minimum criteria to enter Level 2:It must be a Level 1 hotspot for X number of blocks.Issue an assert_location transaction by incurring a $40 USD data credit burn fee."

[arkieguy]

Suggestion for Consensus Group (CG) Processing / Level 4

Problem Description
It's my understanding that part of the reasoning behind requiring a stake to achieve Level 4 is to provide a disincentive for attempting to "game the system". As I see it, a stake large enough to provide this disincentive will potentially price many good actors out of the pool and as a result limit the size of the pool of users that are willing to take the risk to participate. This could actually make it easier for a bad actor (BA) to "buy it's way" into a position to in fact "game the system".

Current Process
The way I understand the current consensus pool is that there are 16 RPI's that do the consensus for a given block(?) and the concern is that a BA could infiltrate the group and fudge results for nodes it's helping without being detected.

My Thoughts
The Helium network has the potential to be one of the largest parallel computing environments in the world (currently at 8K nodes) and the CG problem is (at least as I understand it) pretty much the perfect fit for a parallel computing environment.

Here is what I think might both enhance the performance of the network (by increasing CG "bandwidth") and add a security element to the process:

1. Set up random groups of nodes as virtual parallel compute groups (VPCG). These groups could scale in size over time to handle larger and larger blocks using standard parallel computing methods. This could also provide redundancy for nodes that don't respond quickly enough or completely fail.
2. Submit the same block(?) to at least 3 VPCGs (the more the better)
3. Submit the results of step 2 to another VPCG to compare a hash of the results for each group. If the hashes match, then all members are in agreement. If the hashes do NOT match then a more detailed review of the individual member results (comparing the "same" sub-block from each of the individual members of each group to see which one is in disagreement.
4. Use the "score" from step 3 to update the individual members overall score for inclusion in future CGs.

Benefits

1. Provide higher performance to the CG process.
2. Provide redundancy
3. Provide automatic identification of bad actors
4. Spread the network over a larger footprint requiring less internet bandwidth per node
5. The potential to "weed out" slow or low performance nodes could be built into the scoring
6. More nodes are harder to DDOS than a limited few.

[jamiew]

I'd love to see this merged for discussion if there is still interest, but in the interest of keeping PRs moving, I am closing this as stale. Please re-open if you'd like to finalize and merge it.