-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensuring trust for non-Helium hotspots (HIP draft, DIY gateways) #15
Conversation
|
||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'd have to create a scalable process to approve hotspots to be level 3B to solve this
@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. |
Co-Authored-By: Evan Vigil-McClanahan <[email protected]>
Co-Authored-By: Evan Vigil-McClanahan <[email protected]>
[deployment-impact]: #deployment-impact | ||
|
||
We need to ensure we transition the existing hotspots on the network in a meaningful way. Whether every single existing | ||
hotspot goes into the same level or not is yet to be determined. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- Add level demotion - Add level names
Some comments/questions:
|
Thanks for the comments @tjain-mcc
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.
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. |
hotspot goes into the same level or not is yet to be determined. | ||
|
||
2. We would also need to determine which hotspots qualify for Level 4 access as we need an initial pool of consensus | ||
members candidates which would continue to miner the blocks once this HIP goes live in production. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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. |
@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: Malicious Miners + python script simulating above These 20 miners will receive real packets over RF and transmit real data over RF they just share one concentrator / antenna / physical location. Takeaways
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. |
@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. |
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. |
@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. |
@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. |
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 |
@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. |
@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 |
@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.
|
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. |
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 Ex2 is the same set space, but one or more of the challengees is virtual, or fake, whatever you want to call it. To expand on this, what if there were multiple virtual miners 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 Now the "inner" edge case |
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:
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. |
EDIT:
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. |
No, sorry B1, B2, B3 are 3 miners sharing the same hardware in my example, this is the "bad actor"
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) Option 2: Stake on top of eachother 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). |
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
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. |
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:
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. |
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. |
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:
|
"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." |
Suggestion for Consensus Group (CG) Processing / Level 4Problem Description Current Process My Thoughts 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:
Benefits
|
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 |
WIP
Rendered view: https://github.com/helium/HIP/blob/7b715a0614d4c529144e1d6c0083ee8b38c05b29/0009-non-helium-hotspots.md