Add proof of work to advertisements in v2

[RobertH1993]

Flooding spoofed advertisements with new keypairs causes problems.

Fix:

For nodes:
Let nodes add a proof-of-work (PoW) to the advertisement based on public key and appdata. Exclude the timestamp and location (lat long). By doing this it gets harder to spam the whole network with false advertisements and run an Sybil attack (https://en.wikipedia.org/wiki/Sybil_attack). For harder PoWs (aka more leading zero bits in the hash) the cellphone can be used to offload the work to an faster CPU.

For repeaters:
Check PoW and signature before forwarding.

How to implement:

depending on the hardness of the PoW a field for a uint32_t should be added with a PoW-counter, this counter is increased till the hash of the adevertisement message has X leading zero's. The minimal amount of leading zero's should be defined network width.

[ViezeVingertjes]

And then add blockchain so we earn MeshCoin (MC).

[edit]
All jokes, PoW is actually a good one, theoretically. I wonder if it works in case of MC though, as you can just generate thousands of PoW in nanoseconds on your GPU and hookup the LoRa device as modem to usb etc.

[damn-simple-scripts]

Since the advertisement is something the node sends about itself, a PoW would not be efficient.
A PoW needs a puzzle to be solved, if the node that should proof the work knows it/generates it itself it would not be a challenge. If the puzzle is not unique an attacker could copy an existing solution.

A Sybil attack is something that attacks a reputation system - I do not know about one existing in meshcore.
A PoW would slow down an attack where an attacker could generate lots and lots of nodes, implying that this is a bad thing.

Your suggestion implies multiple things: a reputation system/a problem with too many new nodes, a way to strongly identify the sender, having a state (first seen the advert with the PoW, then fwd on that info).

Currently I do not see a way to identify the node that is sending a packet to a repeater (since only ADV and ANON contain the senders public key and the sender is not to be included in the path header field). Therefore, currently any host would be able to spam the network with flood messages without the need to generate a new ID in the first place.

Your suggestion lacks the proof that adverts with too many new IDs is an actual issue for the mesh. Surely spamming the network with tons of adverts causes problems - but the issue is not the ID itself or a new IDs.
If spamming adverts is a problem - and I am very confident that it is - computing a PoW once would be insufficient.

Also on the case on spamming the network we should not differentiate between a node and a repeater, since repeater could also spam adverts and in theory could be originator of text messages (it is not implemented on them, but in context of the MC protocol it would be irrelevant).

PoW on IoT hardware is generally a bad idea since IoT devices usually lack the power (in terms of CPU, RAM and battery) to do the work.

[NOP4]

I think it can easily be bypassed by making a computer do the computation.
This is not a reliable solution.