The other day we shared a thread on the 5 types of work a Hotspot can perform to mine $HNT. Today we take a look at the work of a Challenger in Proof-of-Coverage (PoC).

Challenges are used by PoC to validate wireless coverage. As a Challenger, your Hotspot is chosen by the network to create a challenge, or encrypted multi-layer packet, over the Internet.
The challenge process begins with the Challenger selecting an initial target Hotspot, followed by a group of Hotspots known by the @helium blockchain to be within range of each other as a result of RF witnessing.
These Hotspots are given a multi-layer packet (think an “envelope of envelopes”) that only they can decrypt to prove they are providing legitimate wireless coverage.
The Challenger could be anywhere in the world and does not need to be co-located near other Hotspots. Challenge requests occur every 120 blocks, and if the consensus group accepts the challenge transaction as being valid, the challenge proceeds.
One very cool thing about public key cryptography is that data can be encrypted for decryption by a specific recipient while only knowing the recipient's public key. This allows the Challenger to encrypt each layer of the packet specifically for only certain Hotspots to decrypt.
The Challenger delivers this multi-layered packet via the Internet #p2p network to the first Hotspot in the challenge path.
Once Challengees and Witnesses broadcast and receive the layers of the packet via RF, they send proof they decrypted their layer of the packet back to the Challenger. The Challenger then bundles the receipts together and submits them to the consensus group to be rewarded in $HNT.
The role of the Challenger is similar to something like the role of a client in the @filecoin network. In that case, the client is asking a miner for proof that the file they are storing is still being stored.
In the case of Helium, the Challenger is asking the miners on the network to prove they are still creating network coverage that can be used by devices.

🎙To learn more, listen to this great podcast episode on PoC with @armanhotspot and @amirhaleem: https://t.co/dUx9eFq06d.

More from Tech

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective


Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.

You May Also Like