Authors: @rawrmaan

Rendered HIP markdown: https://github.com/helium/HIP/blob/master/0012-remote-location-assert.md

Original PR: #30

Description from original PR:

Since the GPS location assertion check will soon be enforced, more than 1500 hotspots will need to be adjusted in some way in order to have a good GPS fix and continue participating in Proof of Coverage (see current hotspot gps_fix_quality states below). For many hotspots, this will require updating the asserted location to accurately reflect the hotspot's latest location, which can currently only be done with physical access to the hotspot.

gps_fix_quality | count 
----------------+-------
good_fix        |  2275
no_fix          |  1090
bad_assert      |   514

This HIP proposes a new transaction, assert_location_v2, which will allow a hotspot's location to be asserted remotely without physical access to the hotspot.

HIP Template

• Author(s): @PapaOwl
• Start Date: 2021-06-03
• Category: economic
• Original HIP PR:
• Tracking Issue:

Summary

The current reward structure incentivises companies too much to install a 50$ light hotspot for the use-cases they are installing even in well covered areas, since the following will always be true with the current structure:
If it is profitable for any hotspot to be in the area, it is even more profitable for a company to bring in a new cheap hotspot 1m next to the use-case that they install.
Thus I propose to change the DC reward from the fastest responder to all hotspots that could have performed this duty in a timely fashion.

Motivation

The price of Hotspots will see a drastical reduce over time due to Light Hotspots having much lower requirements and economics of scale factoring in. The latest estimation on this that I saw put it at 50$ for hotspots somewhere around 2022/23.
As it currently stands most use-cases are very static in nature.
From the parkmeters, to parking spot counters, various environmental sensors, water leakage things and so on.

As a company you have to worry about a central question: Will the coverage last. You cannot answer that for smaller cities, because you do not know the hotspot owners. Thus this alone is already a reason to install a light hotspot as you install the use-case. Unfortunately with how it currently runs it would also mean that all the DC rewards would go to the company. There is no reason to believe that another hotspot can challenge a hotspot literally built into the use-case on this.

The company has not added coverage, but it reaps the entire reward and thus disregards all others that were already there and furthermore might even violate hex-rules and punish the other miners. However they have a good reason to do and we should not prohibit that, but we should not reward it too much either.

We have to think of those that provide coverage even in areas that don't see as much action, because a network that reaches far and wide is worth much more to companies of all kinds, than a network that only exists on top of use-cases and major population areas.

For the customer it does not matter one bit who is rewarded unless he is also the one that decided to place a hotspot on himself to get a kind of cashback on his DC useage instead of using the coverage that is already provided.

This HIP does not have an affect to areas that have no other hotspots nearby.

Stakeholders

All those already providing coverage

• Who is affected by this HIP?
  All new "coverage" providers

Detailed Explanation

I am not a code guy, but with how it looks to me currently only the resolver of a DC packet is rewarded. Hotspot 2,3 or how many there are have no way of knowing that Hotspot 1 will be faster, so they aswell will at least have tried to resolve it. Currently only Hotspot 1 would be rewarded for resolving. All others would not receive anything.

Thus we could tie the reward to the blocktime, but preferably I would set 1-2s after the resolve as cut-off to give a bonus to those that provide good and fast services.

As an example we have a use-case sending out a ping and there is 6 Hotspots that receive and try to act. Hotspot 1 was the fastest, but Hotspot 2-5 all reacted in under 1s aswell. Hotspot 6 only responded after 2 seconds now the reward is going out to to Hotspot 1-5 in equal amount. Hotspot 6 failed and is thus not rewarded. Maybe he was too far, maybe its internet is too slow.

No new rewards or price increase is happening here. The reward that would go to one guy in full before would now be equally split to all that could have handled the request well. If there is no other hotspot to begin with, then this changes nothing.

• It should be reasonably clear how the proposal would be implemented.

Not a code guy, so I cannot say how this would end up being solved.

• Provide representative examples that show how this proposal would be commonly
  used.
  If you think of any small scale city being filled by several hotspots and providing good coverage. A company comes and installs any use-case at some point in that coverage and additionally a light hotspot is also planted.

Now instead of the DC rewards going solely to the new hotspot they go to all those that could also have provided the service for the use-case.

• Corner cases should be dissected by example.

I think gamey cases are covered as long as we tie the DC output to the reward scale.

Drawbacks

The drawback is that it isn't as profitable for companies to bring their use-case and a hotspot at the same time. However I would not call this a drawback to the network, but an advantage.

• Why should we not do this?

Honestly I see no reason. Good coverage is done by several miners and not by a single one on top of the use-case. If we want coverage to be widespanning, then we cannot have a system that rewards placements directly on top of use-cases the most.

Rationale and Alternatives

An alternative could be to lock out new devices out of DC earnings for a time if they are placed in already settled areas, but I feel simply sharing among all is simply better.

This is your chance to discuss your proposal in the context of the whole design
space. This is probably the most important section!

I know that currently we have a huge incentive to provide cover, but eventually the Network will be rewarding DC only. If companies start to plant in a well-covered area it is a slap to those already covering. In this it doesn't matter if the coverage is provided by 10 individuals or a single guy, that made sure that the city he lives in is well covered. The use-case would finally appear and the reward would rarely go to those.

If we take the example of park meters, then a company would be well advised, to incorporate the LoRaWAN directly into the design, but they also should not be rewarded exclusively on the DC. Otherwise we undermine those that provided the possibility for it to be used.

In case the network surrounding the use-case breaks down the parkmeter would keep functioning as it comes with its own device.

So this is a very good compromise between protecting companies against the failure of coverage and protecting the interest of those that already provide coverage longterm.

• Why is this design the best in the space of possible designs?
  I don't think, that I could come up with all possible design solutions to this problem, so I guess I cannot answer such a broad question.
• What other designs have been considered and what is the rationale for not
  choosing them?
  I think there was ideas about locking out new devices of earning and protecting old devices. I feel those ideas are too harsh and Helium should in general go further away from individual hotspot earnings and more to area earnings. A LoRaWAN Network that reaches far, is worth more than a Network that exists only in big clusters. We need to make sure, that rewards go to a wider area than the action.
• What is the impact of not doing this?
  Individuals who built the network when there was no use-case will be driven out by companies that bring the use-case. Last time I checked this was supposed to be a network made by people and not by medium sized companies.

Unresolved Questions

Maybe discussion of this HIP brings it to light. Consider this HIP as a nudge. If someone can write it better, feel free to take this idea and develop it further, but I believe as it stands it should neither be too hard to implement, nor be unreasonable to do so.

Deployment Impact

Success Metrics

What metrics can be used to measure the success of this design?

• What should we measure to prove a performance increase?
  The entire problem is something that still has to come up. This HIP targets to remove a problem before it occurs as thus it not happening is our success metric.

• What should we measure to prove an acceptance of this by it's users?

• A vote

As a final note I want to greet Tim and re-offer poffertjes to be guaranteed a purchase of 5 longaps.

Author(s): @jmfayal (jmf), @tjain-mcc (tushar), @rawrmaan
Initial PR: #72
Start Date: 2020-11-04
Category: Economic

Rendered view:
https://github.com/helium/HIP/blob/master/0020-hnt-max-supply.md

Summary:

This proposal suggests the introduction of halvings in net HNT issuance every 2 years (based on block height) to establish a max supply of HNT.

With the introduction of a hard cap on HNT supply, Helium’s token-economics would become more understandable to the broader crypto community at large. It would also create future scarcity and a new incentive to hold HNT. If there is more demand for HNT, miners will have additional incentive to deploy Hotspots. If miners deploy more Hotspots, the network will continue to grow its coverage, which will ultimately help meet the demands of end users and customers who use the network.

Author(s): @tjain-mcc, Shayon Sengupta
Start Date: 2021-04-19
Category: Governance (AKA Meta)
Initial PR: #182
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-31-governance-by-token-burn on https://discord.gg/helium

Rendered view:

https://github.com/helium/HIP/blob/master/0031-governance-by-token-lock.md

Summary:

We propose a new governance system where voters must burn their HNT in order to vote. This system helps encourage consensus building because contentious votes are more expensive than landslides. It also imposes a significant cost on any large holder which tries to control governance, leading to less oligarchic governance outcomes.

Author(s): @vihu, @Vagabond, Helium Systems, Inc. team
Start Date: 2021-04-19
Category: Technical
Initial PR: #155
Tracking Issue: this
Status: In Discussion

Rendered view:

https://github.com/helium/HIP/blob/master/0030-update-threshold-cryptography.md

Summary:

Helium Distributed Key Generation and Honeybadger Consensus Protocol both rely on curve SS512 for pairing-based cryptography. Curve SS512 is considered a very old curve and is not commonly used. In addition, the library we use for pairing-based cryptography, Ben Lynn's pbc library, has not seen major maintenance since 2013.

This HIP proposes switching to an industry standard curve BLS12-381 for doing threshold cryptography. The underlying implementation for BLS12-381 is security-audited, faster, and more secure than curve SS512.

We have been testing a new threshold cryptography library that has been in use on the Validator Testnet for several weeks and believe it is ready for Mainnet.

I'm making a suggestion for HIP19 that vendors visibly disclose the format/style of hotspot DNS names - or adhere to a suggested standard.
As all the different vendors hotspots appear in different naming formats when looking on the routers - I believe some are unique per hotspot and some are the same for every hotspot.
Some hotspots can be identified by the DNS name and some cant.
It will help with discord support and many of the forwarding questions if this could be put into user manuals or tech forums.
Or on https://docs.helium.com/troubleshooting/network-troubleshooting

Author(s): @Bx64, @cryptomaniac79
Start Date: 2021-06-01
Category: Technical
Initial PR: #211
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-34-validator-node-security on https://discord.gg/helium

Rendered view:

https://github.com/helium/HIP/blob/master/0034-validator-node-security.md

Summary:

As validators will take over all activities regarding consensus on the Helium network, the pool of actors in charge of validating transactions and creating blocks is significantly reduced from the current situation (46K+ hotspots and growing fast) to a small pool of (expected) several hundreds of nodes, which significantly decreases the targets that need to be interfered with in order to impact consensus in one's own favor. Having these nodes IPs (and with that, location and hosting provider information) be publicly visible, traceable and targetable on the Helium network therefore poses a significantly increased security risk compared to the current situation. If the validator nodes are compromised, so is the progress of the chain meaning the chain could completely (and perhaps unrecoverably) stall.

Authors: @tjain-mcc

Original PR: #19

Rendered view: https://github.com/helium/HIP/blob/master/0005-poc-fairness.md

Summary from HIP:

Proof of coverage challenge participation rewards are too concentrated for the top few hotspots. This has led to a concentration of mining rewards which are not ideal for the proliferation of the Helium Network.

I propose that we cap the number of challenges any given hotspot can participate in during a single Epoch.

Author(s): @refugeesus
Initial PR: #76
Start Date: 2020-11-09
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0021-poc-link-layer.md

Summary:

The goals of these changes are to:

1. Break up the PoC message to improve the reliability of PoC transmissions.
2. Improve the quality of information gained from PoC transmissions in the RF layer.

The link layer is the method by which information is send from one source to another. It sits directly above the PHY layer and below the MAC layer. For a specific definition, please see the OSI model.

Author(s): @xandkar, @Vagabond, Helium Systems, Inc. team
Start Date: 2021-04-19
Category: Technical
Initial PR: #154
Status: In Discussion

Rendered view:

https://github.com/helium/HIP/blob/master/0029-multisignature-keys.md

Summary:

Hotspot owners, HNT holders, and other Helium participants, have different ways to organize assets. This HIP proposes a multi-signature key which can be used to authorize a transaction on the Helium blockchain. This key is a composite of the scalar keys which can be combined to generate a minimal subset of signatures required to make a valid transaction.

Author(s): @PapaOwl
Start Date: 2021-06-03
Category: Economic
Initial PR: #194
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-32-split-dcs on https://discord.gg/helium

Rendered view:

https://github.com/helium/HIP/blob/master/0032-split-dcs.md

Summary:

This proposal changes the DC reward mechanism. Instead of only going to the fastest responder, the DC reward is split among all hotspots that tried to perform this duty in a timely fashion.

I would like to propose that the Validators support somewhere between 5-10 wallets to avoid that only a limited number of people that is holding 10k+ HNT can be able to contribute with a validator.

The staking wallets would retain a % of the 10K that are demanded to run a validator and then it would split the earned HNT across the wallets that are part of this validator.

The current design is benefiting strictly major HNT holders and is not providing an opportunity for smaller holders to have a staking chance within the Helium Project,

Author(s): @evanmcc, @helium/engineering
Initial PR: #110
Start Date: 2021-01-11
Category: Technical, Economic

Rendered view:

https://github.com/helium/HIP/blob/master/0025-validators.md

Summary:

Add a new class of actors to the network, called Validators. These will be staked actors, with the intention being to run them on stronger hardware with better network connections than the current Hotspots. They will serve the dual purpose of being eligible for block production and also, in the future, acting as proxies for lightweight (non-chain-following) gateways.

Anyone know what 7 blinks of the green light on a RAK hotspot V1 means? Any help is much appreciated!

Author(s): @georgica, @lthiery, @Carniverous19 (para1)
Initial PR: #91
Start Date: 2020-11-16
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0022-diy-concentrators.md

Summary:

This proposal side-steps the inherent lack of trust in gateways by creating a special LoRa concentrator module that we can trust. Whereas today, RSSI, SNR and GPS timestamps cannot be inherently trusted, reports from these "Anchor Gateways" will be a root of trust for physical information on the network.

Discussion of a rewritten HIP process

Before writing the first draft of LongFi, I'd like for this issue to serve as a place to ask a few high-level questions to help steer the direction of the protocol. It's become apparent that what we've been calling LongFi is two separate protocols, LowFi and HighFi. That leads to some questions. Please do not consider the answers below as gospel but as possibilities or outright bad ideas.

Glossary

• LowFi: a low-level device ⟷ hotspot protocol

  • MAC layer
  • Likely contains encrypted, application/organization-specific payload
  • Specifies only cleartext fields required to allow hotspots to forward packets to their organizations' routers, and routers to send downlink packets to the correct device
  • Specifies device and hotspot behavior necessary for regulatory compliance

• HighFi: a high-level device ⟷ router protocol

  • HighFi is to LowFi as TCP is to IP (ish?)
  • Can be application or organization specific
  • Where [de]fragmentation would live

• ACK: a small and possibly data-free packet sent to acknowledge the receipt of a data-bearing packet

  1. A → B: a data-bearing packet
  2. A ← B: ACK

• Uplink-ACK: a device ← router ACK in response to an uplink packet

• Downlink-ACK: a device → router ACK in response to a downlink packet

Q1: Should LongFi specify any of the high-level protocol (HighFi)?

Initial offline discussions lean towards no if possible.

RATIONAL: Not specifying HighFi keeps LongFi simple and easy for third-parties to implement and understand. Additionally, it removes some risk of early decisions leading to unintended consequences.

Q2: What must LongFi specify to support HighFi?

It depends on the semantics of HighFi.

Q3: Does LongFi have the notion of connections (or sessions)?

It appears that LongFi requires sessions from device to its organization's router to operate in a trustless network.

Q4: If LongFi has sessions, how will that work with multiple hotspots?

Sessions are between a device and its organization's router, not with any hotspot in particular. It doesn't matter which Hotspot relays a device packet to a router.

Q5: What about downlink packets?

At a minimum, downlink packets are required for Uplink-ACKs.

Q6: What packets get ACK'd?

Uplink-ACKs are optional, and the conditions on which they are sent are HighFi/application-specific. For example, a device/user/org may only care about receiving Uplink-ACKs occasionally or in response to uplink packets containing critical payloads.

Downlink-ACKs seem to be mandatory. Downlink-ACKs are the only way for a router to detect malicious hotspots who charge for downlink packets but purposely drop them on the floor [1].

1. Short of adding downlink-witness semantics to the network (which is worthy of further investigation).

TODO

Explain some things that came up at lunch today:

• Dance Dance Revolution
• Interaction between Downlink-ACKs and state channel (might need @Vagabond for that one)
• Timeshare
• Fallback slots

Discussion area for HIP

Rendered view: https://github.com/helium/HIP/blob/0c76a685e64885832c265b44fda87a4d58a4e97d/NNNN-usage-based-rewards-structure.md

Pull Request: #33

It has been widely discussed that the recent rewards reallocation disincentivizes so-called "lone-wolf" hotspots from existing, as well as disincentivizes the Helium Network from growing into new markets. Many large cities in North America still have yet to see any hotspots come on line, and the now-current rewards structure, even with implementation of HIP 10 as-designed, makes it so that any new entrepreneur will need a minimum of 3 hotspots to effectively create a new market. Prior to August 2020, it was possible for new markets to grow organically around these lone-wolfs. This proposal intends to structure a Network Growth Rewards Pool so that the Helium Network can continue to effectively grow into new markets instead of stagnating around existing, established markets.

I propose an amendment to HIP 10 that does the following:

• allocate DC arbitrage from Data Transfer pool (until arbitrage phases out) to a Network Growth Rewards Pool
• Once arbitrage accounts for less than 1% of total rewards, begin phasing PoC rewards down to 18%. PoC is at 18% once arbitrage ends.
• Network Growth Rewards stays permanently at 1% of total rewards. Any unused Network Growth Rewards during a bonus cycle get reallocated to the total rewards pool (in HNT) over the next X number of blocks.
• Rewards Cycle for Network Growth Rewards would be every 6 months. First Rewards Cycle would begin on the first day of the first month following technical implementation go-live. Second Rewards Cycle would start 6 months later. Rewards Cycles would be fixed dates. (i.e. September 1 & March 1)
• Each Block, 1% of the Total Rewards is set aside into a Network Growth Rewards Account.
• Rewards Cycle would consist of 6 separate Rewards Months. ⅙th of the Network Growth Rewards Account balance is allocated to each month (Rewards Month Pool).

Eligibility: During a Rewards Month, a hotspot is eligible for a bonus as follows:

1. A hotspot must have mined HNT on at least 75% of the days of the month.
2. A hotspot must have mined no more than 14 HNT for the month.
3. A hotspot must have an asserted location at least 750 meters from another hotspot.
4. A hotspot must not have asserted a new location more than two times during the Rewards Cycle.

Payout: The Rewards Month Pool will be allocated as follows:

1. A hotspot can earn a bonus UP TO 100% of that hotspot's earnings for the month, with a progressive, even decline in bonus starting at 8 HNT, phasing out at 14 HNT. For example, if your hotspot earned 11 HNT on the month, the bonus it is eligible to earn would be up to 5.5 HNT. Need to verify that this structure won't reward someone who mined less in a way that puts their total reward for that month higher than someone who mined more
2. The maximum total bonus paid out for a Rewards Month across all eligible hotspots cannot exceed the total HNT available in the Rewards Month Pool. If total eligible bonus exceeds the Rewards Month Pool, each hotspot's share of the Rewards Month Pool will be reduced accordingly.

Authors: @jamiew

Original PR: #22

Rendered view: https://github.com/helium/HIP/blob/master/0007-managing-hip-process.md

Summary from HIP:

Defines an initial process for proposing, discussing, and finalizing improvements to the Helium blockchain using Helium Improvement Proposals (HIPs).

"How a bill becomes a law"

For discussion of #20

Latest rendered view: https://github.com/helium/HIP/blob/60ba6cb841d3ef66020a8504070f7016d20ef5ab/0006-reward-ramp-for-packets.md

Author(s): @ericmheilman
Initial PR: #104
Start Date: 2020-12-26
Category: Technical

Rendered view:

https://github.com/helium/HIP/blob/master/0024-reward-splitting.md

Summary:

This proposal introduces a new transaction, transfer_gateway_v2, which will allow a hotspot owner to irrevocably transfer a percentage of their hotspot ownership to another owner. Percentage of hotspot ownership will be determinant in the payout of HNT rewards (50% ownership -> 50% of HNT, 10% ownership -> 10% of HNT, etc.). This transaction can have an optional amount of HNT associated.

Formerly known as: Transfer Percentage of Hotspot

Author(s): @zer0tweets (Boris Renski, FreedomFi)
Initial PR: #133
Start Date: 2020-02-23
Category: Technical, Economic

Rendered view:

https://github.com/helium/HIP/blob/master/0027-cbrs-5g-support.md

Summary:

This proposal suggests a technical and economic mechanisms to support higher new wireless protocols on Helium network, starting with LTE and 5G in CBRS spectrum band

This is for discussion of HIP 10.

Rendered HIP view: https://github.com/helium/HIP/blob/master/0010-usage-based-data-transfer-rewards.md

Author(s): @Carniverous19
Initial PR: #59
Start Date: 2020-10-20
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0017-hex-density-based-transmit-reward-scaling.md

Summary:

Very little additional coverage is demonstrated by being able to witness multiple hotspots that are co-located or in close proximity to each other. On the other hand, being able to witness many hotspots that are in distinct locations demonstrates a hotspot is providing a large area of coverage. This is in contrast to the current PoC reward structure, where transmitters and high density areas see a significant portion of PoC rewards.

This HIP suggests a change to PoC rewarding to better rewards areas of coverage. Rewards are reduced for transmitting or witnessing hotspots in close proximity to each other.

Author: @anthonyra
Initial PR: #47
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0014-poc-ripple-method.md

Summary:
The current Proof-of-Coverage allows for Virtual Machine (VM) farms or hotspot farms that have been engineered to maximize return of rewards without providing benefit to the network. This HIP proposes a different method to to determine Proof-of-Coverage, by seperating the network into islands that are based on the geolocation of hotspots and their associated witness lists.

Judging by the latest ANN on Discord (https://discord.com/channels/404106811252408320/730418759298318346/849697264053911624), the Helium Network is struggling with the Blockchain performance, due to the increase of Hotspots joining the network.
I do understand the necessity of the Validators, but at the current collateral value (10000 HNT = $152800), I'm afraid the network won't reach the necessary Validators, to cope with 80K or 100K Hotspot miners in a near future, plus all the IoT sensors coming in for Data Credits further ahead.
A proper preparation for a stable network is undoubtedly required!

I suggest:

• the colateral amount for Validators to be reduced to 5000 HNT or less (this will give more Validators on the Network)
• reduce in half the % rewards for Validators (less investment - less rewards - same ROI)
• keep or increase the % rewards for the Hotspot Miners (manufacturers are planning increased sales volume)
• Consequently, the main objective is for the Helium network to gain more stability and having more affordable Validators, will make the Network prepared for the increasing devices, coming into the Network, without damaging the early Hotspot miners rewards and allowing the new ones to get their ROI earlier.

I believe this is a Win-Win for everybody and it will be much beneficial for the whole Helium Network.

Eden Litespot
Summary
My name is Tyrell Gerald. I plan to build lite helium hotspots mainly for the Canadian market at a reduced price and much faster and more reliable delivery. I understand the importance of credibility and experience and I know that all the other applications will be from big companies with years of formal experience I may not have all the experience as the other but I do have the drive and determination to provide a excellent product and to help grow the helium network and ensure that the Canadian market can play a big role in that. I don’t think that it’s right for the people who may have learned about helium a bit too late to not have the opportunity to be apart of something this spectacular and therefore If given the opportunity I will do everything in my power to make this a reality and help spread the word that is helium. Thank you in advance for the consideration and please let me know what additional information is needed

Company Information
Business network home automation data systems have been around computers and all electronics for years. I have built multiple computers and have put together functioning home automation systems.What brought me to the helium network is the idea of creating a more reliable coverage network. And rewarding its users for providing a service

Product Information
So just like all the other units on the market I will be using a sbc like the Raspberry Pi and then will be adapting the Sx1302 LoRa card which will provide 10 programmable parallel demodulation paths, an 8 x 8 channel LoRa packet detector, 8 x SF5-SF12 LoRa demodulators and 8 x SF5-SF10 LoRa demodulators. It is capable of detecting an uninterrupted combination of packets at 8 different spreading factors and 10 channels with continuous demodulation of up to 16 packets. For software I will adapt everything to run on the helium app and We will provide ota updates. that way it’s directly on the network and we don’t have to worry about security risks my goal would be to produce as many units as required with the order numbers I would be able to have the units assembled and shipped within 3-5 days of receiving the order my goal price point would be 450-500$ cad until we can get the price for the components down and at that point 300$ a unit. I will provide prototype photos and videos at a later date as I would like to see if I have a chance before starting to build it

Customer Service
I will provide email customer support and have a solid amount of people ready to get to the customers and resolve their issues I have years of experience working in customer service and technical support for companies such as Telus bell mobility ect. for repairs and replacements I will have the customer send the unit back in to the headquarters inspect and repair and send them back out until it will be possible to have a location in every province where they will be able to bring the units in person and have them repaired on site or replaced if needed each unit will have a 1 year replacement warranty which will cover any hardware issue

Hardware security
The swarm keys will be stored on a secured EMMC storage card

Manufacturing Information
Have built data centres and multiple electronic systems from computers to smart home panels phone systems intercoms ect. I have personally created similar units years ago before helium was a thing and am very familiar with the technology.

Proof of Identity
To be provided in private message .

Budget & Capital
The plan is to fund the initial development personally and I am confident that the profits and pre orders will be able to more then cover any expense I will also plan to have a large amount of units already in stock and ready to be shipped out upon order I will ensure to update the availability of the units accordingly and will only allow pre orders of up to a week delay to avoid having customers pay for a product and not receive it for months

Risks & Challenges
The only challenges I see would be the shipping of the units but to address this issue I plan to use multiple shipping companies and providing local shipping service

Other information
Desired Discord support channel name -
Twitter profile -Eden.Litespot
Facebook profile --Eden.Litespot
Other social profiles --Eden.Litespot
Website --EdenLitespot.io or .com or .ca
Payment methods available - debit credit crypto
Regions covered / shipped to - Canada

Your Name
Tyrell Gerald, upon approval I plan to structure a formal company and I will be the ceo.

Sorry if this is the wrong place for this, if it is then please let me know and I'll happily move it.

We have had one or two customers who have onboarded their hotspot to their wallet and have subsequently lost the seed phrase to their wallet.

Currently, these devices are essentially bricked but it is possible for us to rework them (for a fee) and fix the unit to allow it to be re-onboarded by replacing the ECC chip.

We could do this with no problems, however, given this brings in concerns about theft, among other things, we felt this would need a mechanism to be agreed on with DeWi and the wider community in order to safeguard the network from theft and gaming.

I guess the two things I was thinking would be needed are:

1. A method to verify the hotspot has not been stolen (proof of ID and purchase etc)
2. A method to blacklist/remove the original ECC key from the network

With these two things it should be ok, in my opinion, but maybe there's something I'm missing of course. And for a fee of around £100 would be less than a full replacement hotspot. It obviously also solves an issue of sustainability that will likely come up more frequently as time passes.

Hi
I just started 4 days ago and I the first 3 say I was making 3 hnt a day but since 24 hours I didn’t make any rewards and even all the miner who are near me either didn’t make any rewards

is this normal and do I need to do any things to fix the issue

my miner : Straight Ruby Huskie
NewWestminster BC Canada

Currently we have several HIPs which have been merged and deployed to the blockchain, but it'd be good to have the proof in the associated .md file. I'm specifically thinking about HIPs 1-4

For a decentralized blockchain the number of validators seems pretty low and the stake amount is pretty prohibitive creating a very high barrier of entry.
The 10k HNT are equivalent of ~$150k and is a huge limit for an "average" (1) person to start validator node.
At the current stake level this means that very early adopters or people with this money to spare would be able to even think about running a validator.
Having a low number of validators is also risky for the blockchain even if the current number of gateways is relatively low now... it will explode in H2 this year.

I agree that the barrier of entry should not be very low either but I would say something in the range of ~$5k-$10k (equivalent of HTN) would be a much better starting staking threshold.

(1) By "average" person I mean someone who is in the Helium network already, has some HTN or can buy some and has technical skills to setup the validator node.

The Decentralized Wireless Alliance (dewi.org) advertises itself as "the Foundation arm of the Helium block-chain and its global community". It is a not-for-profit organization established and run by early investors of the for-profit Helium Systems Inc. with the declared purpose of "supporting the Helium community worldwide, we are responsible for fostering research, development, and innovation at the intersection of radio hardware, sensors and manufacturing, blockchain, and peer-to-peer systems".

Not-for-profit implies neither that an organization is, nor is not, dedicated to advocating in an unbiased way the interests of all stakeholders or of the public-at-large.

DeWi is seen as a benevolent non-biased entity. However, while the current directors and dues-paying members may be benevolent, with interests aligned with those of all in the community, it is folly to assume that this is, and always will be, true.

There is nothing wrong with the founders having a trade organization. However, I suggest that it should either hold no arbitrary authority regarding Helium Improvement Proposals (HIPs) OR it should be fully transparent to the community regarding all factors which might reasonably be perceived as potentially leading to conflicts of interest. This would include, for all directors and managerial employees/consultants:

1. Full legal names
2. Relationships, including employment with, and beneficial holdings of stock and other securities of, Helium Systems Inc. and entities that produce or supply relevant products and services.
3. Beneficial holdings of Helium Security Tokens (HST) and Helium Network Tokens (HNT).

Additionally, the terms by which the board of directors and voting membership in the organization is determined should be clearly displayed on its website.

Ideally, I believe that approval and implementation of HIPS and all adjustment of chain variables and firmware code should be controlled by a well-defined and representative organization. The current system of holding a vote by a few dozen folks who know to keep an eye open and regularly check the proposals on Discord could result in decisions contrary to the interests of many or most being implemented.

I expect that some, upon reading the above might be tempted to say – So you don’t like the status quo; where is your fleshed-out proposal for the future? Why are you bringing this up here without one?

To which I would reply that I believe that this is a topic worthy of discussion and that I have learned that to raise such issues for discussion in Discord is not, by some, taken “seriously”. While I do not flatter myself to know how best the matter should be addressed, nor all of the factors that should be considered, I am hopeful that a good discussion will result in a proposal with wide acceptance.

If it turns out that the current system is widely viewed as the best that option available, I'll be fine with that. I really don't know.

Author(s): @PaulVMo
Initial PR: #54
Start Date: 2020-10-14
Category: Economic

Rendered view:
https://github.com/helium/HIP/blob/master/0016-random-consensus-group-election.md

Summary:
Changes to the election process for Consensus Group (CG) members to make all active hotspots equally likely to be selected to the CG instead of the current functionality that favors hotspots with a higher hotspot score.

After asking the Reddit Helium Community over 70% of the community agrees with postponing. Can we please proceed with considering this proposal. Also please re-direct this to the correct spot for proposals or where it can be re-submitted.

Thank you

Author(s): @mj0lken
Start Date: 2021-02-06
Category: Technical, Economic
Initial PR: #210
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-33-regional-reward-adjustments on https://discord.gg/helium

Rendered view:

https://github.com/helium/HIP/blob/master/0033-regional-reward-adjustments.md

Summary:

This proposal suggests the addition of a regional reward scaling chain variables to deal with different regional output regulation for the LoRa protocol in order to create an equal deployment incentive over the world.

Hello, I am having an issue where my newly installed hotspot is getting invalid witnessing of another unit. The odd part is that unit is witnessing me back just fine. I am wondering what can cause this?

Is it my antenna gain is too high? Is my antenna moving in the wind making it seem like it's moving or something I am very confused about how the blockchain can just decide the miner I paid for is not valid or not sending valid signals? I opened the box, programed it and plugged in the antenna, and left it. There are no settings to change so how is this even a rule? Maybe the antenna is overpowered or greatly unpowered (higher or lower dbi than advertised)?

Anyone have a clue or can tell me what is going on/causing this? Anything I can try? Do I change antennas?

RSSI | SNR | Distance | Data rate
-105dBm | 10.50dB | 1.5 km | SF9BW125

Please help if you can. This is my only witness and he will only witness my beacons I cannot witness his back. I am so confused and would greatly appreciate any tips that may help.

Thank you for your time today.

Author(s): @cvolkernick
Initial PR: #97
Start Date: 2020-12-15
Category: Technical

Rendered view:

https://github.com/helium/HIP/blob/master/0023-decouple-consensus-from-gateways.md

Summary:

This proposal changes the structure & process involved in forming consensus on the network, primarily by separating concerns of miners (providing verifiable coverage) and the consensus group (securing the network and forming blocks).

Authors: @jamiew (jamiedubs), @georgica, @philltran
Initial PR: #86
Start Date: 2020-11-14
Category: Governance (Meta)

Rendered view:
https://github.com/helium/HIP/blob/master/0019-third-party-manufacturers.md

Summary:

This proposal seeks to lay out requirements for new third-party manufacturers to be approved by the community, and a process by which onboarding keys can be issued by Helium, Inc to those manufacturers.

These are merged now but this repo is out-of-date

Need to dig up relevant blockchain-core PRs and/or chainvar audit txns and add them to README, then update relevant issues

HNT is a utility token and will grow as the network grows in value. Halving does not mean it will increase in price, Take LTC as an example, halving had no effect on the price, the price actually followed bitcoin price action. I hold Bitcoins, why in Gods earth would I exchange my Bitcoin for HNT? Doesn't make sense to me. Make a great product, investors and speculators will follow.

That said, what's scary to me is, Numbers are floating around, after the halving and validators, HNT earnings (by miners) will drop approximately 85-87% of current earnings, is this true?

I have an interesting and effective proposal here. The mining income of hnt can be distributed according to the population of each city, and the more the population, the more hnt should be distributed in cities. If there are fewer mining machines in a city with a large population, you can set an upper income limit for each mining machine. Those who make virtual positioning (cheating) like to put mining machines in deserted suburbs, forests, fields and mountains. First, the benefits of cheating can be greatly reduced in this way. Because of the decrease in income, cheating is bound to decrease slowly. Secondly, this method will also contribute to the ecological development of helium in the future. Because many applications need to run in big cities with many people. I think this way is very beneficial to the continuous development of helium in the future. Third, this approach is also conducive to helium's faster and wider layout of all cities in the world. Of course, my ideas have just come into being, and there are still many areas to be improved. I hope everyone can correct and improve them.

Author: @Carniverous19
Initial PR: #49
Start Date: 2020-10-07
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0015-beaconing-rewards.md

Summary:
This proposal suggests a change to proof-of-coverage (PoC) from multihop to beaconing as well as a change in how PoC is rewarded that combines HNT mining for witnessing and PoC into one pool and gives the bulk of the reward to hotspot witnessing or receiving RF payloads vs transmitting RF payloads.

• Original PR: #42
• Authors: @mrallen1, @abhay

Summary: This proposal introduces a new type of transaction to the Helium blockchain called transfer_gateway_v1. This transaction will be an atomic transfer of an onboarded Hotspot / gateway from one owner to another. This transaction can have an optional amount of HNT associated.

Rendered version: https://github.com/helium/HIP/blob/9cf52310b532d98232d21de33449ce789c58ef10/0099-transfer-hotspot.md

Author(s): @lthiery
Initial PR: #62
Start Date: 2020-10-28
Category: Technical

Rendered view:
https://github.com/helium/HIP/blob/master/0018-remove-oracle-forecast-for-dc-burn.md

Summary:

A new oracle price takes effect one hour in the future, to provide users with predictability when converting HNT to DC. Unfortunately, this delay provides an on-chain arbitrage opportunity via state channels. Given the delay, an actor with HNT in-hand may see the forecasted drop in HNT price and thus convert HNT into DCs. After the drop takes effect, the actor may then “spend” the DCs in a state channel, naming a colluding gateway of theirs as the beneficiary. Effectively, the actor is burning and minting HNT on-chain at a profit with very little risk. This HIP seeks to address this flaw.

I just updated README but would be good to clarify in their .md file and issues

Info

• Author(s): @BFX
• Start Date: 2021-08-06
• Category: Technical
• Original HIP PR: 257
• Tracking Issue: not filed yet
• Status: In Discussion
• Discord channel: #hip-36-blockheight-chainvars on https://discord.gg/helium

Rendered view

https://github.com/helium/HIP/blob/master/0036-blockheights-instead-of-time.md

Summary

At the time of writing, most (if not all) blockchain variables and implementations are activated manually by the Helium team, requiring active intervention from the team and have a time-based activation. The active intervention can, for the greatest part, be avoided by enabling auto-activation of variables at certain blockheights. This has been the standard for most blockchain projects. One example is the bi-yearly halving of HNT rewards agreed to in HIP20 which should be integrated with blockheights rather than be defined by moment in time for its activation - and in the future, hopefully any change of blockchain variables can be defined that way.

Author(s): @cvolkernick
Initial PR: #117
Start Date: 2021-01-24
Category: Technical

Rendered view:

https://github.com/helium/HIP/blob/master/0026-payment-notes.md

Summary:

This proposal suggests the addition of a new option for the Helium wallet PAY command: an optional (likely length/size restricted) alphanumeric memo/note field included with a wallet-to-wallet HNT payment transaction.

Author(s): @PaulVMo
Initial PR: #136
Start Date: 2021-03-12
Category: Economic

Rendered view:

https://github.com/helium/HIP/blob/master/0028-consensus-reward-adjustments.md

Summary:

Changes to consensus group rewards to better achieve 6% reward target and reallocate any unearned consensus rewards to PoC

Author(s): @wavesoft, @dmamalis
Start Date: 2021-07-28
Category: Technical
Initial PR: #249
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-35-rf-metadata-sidechannel

Rendered view:

https://github.com/helium/HIP/blob/master/0035-safe-rf-metadata-side-channel.md

Summary:

Introduces a new side-channel from which RF metadata can be collected, in a way that no sensitive information
can be disclosed to third parties.