Spam control by node sanctioning

Apart from the good ongoing development on PoW algorithm and methodologies, we have seen many proposals of potential additional solutions for spam-control, yet at least to me none has been sufficiently elegant or fitting the simplicity and the asynchronous nature of the Nano protocol.

What bothers me is that currently we have no way in the protocol to sanction nodes that are not using the Network properly (=spamming). We need a solution where an individual node can decide to accept or reject a particular block based the behaviour of the originator node.

At the abstract level it is an account (or many accounts) that are spamming but in reality, it is always one or more nodes. Wallet level spamming must handled at that level.

So here's my proposal.

First element - block-level node broadcast speed control:

  • Add a 'origin' : node_id field to the block
  • The originator node broadcasts the block to all connected peers, a peer would discard the block if the origin is forged, only accept a 'bad' origin block if it comes in the process of re-broadcasting from a representative node
  • The node would individually set a time-based dynamic threshold for blocks per same origin based on the saturation status of the Network (how many blocks are accepted from same origin by second)
  • Nodes would use their relative timestamp of block arrival to decide whether to vote for or against
  • All blocks that do not fulfil the threshold criteria would be voted out democratically by the Network

Second element - PoW for peering and bootstrapping
It is a bit weird that I need to do a PoW for a transaction but I can freely set up any number of nodes that will first increase network traffic due to bootstrapping.
My proposal is to require a PoW both for bootstrapping and peering. I am not sure how it could be done, somehow it should be part of the handshake. We need this to slow down the process how a new node can join the network.

Let me know your opinions.

I am not sure, if it is a good idea to sanction nodes itself. The nodes are not responsible for the incoming transactions. They are just a gateway to the network. Like your ISP is only a gateway to the Internet. It is in the interest of the node provider to ensure that the network has as little spam as possible.
If there is a constantly stream of spam from one particular node, you can still reduce, as an user, the voting power. Maybe it is even possible for other nodes to just ignore the traffic coming from this node. So, I don't see why this should be part of the Nano protocol itself.

If you add a restriction mechanism, you probably end up with some kind of power distribution. The older nodes have more power, since they are more trustworthy etc. So, eventually this can become some kind of currency in itself and older and more powerful nodes may restrict the access to the network and ask for fees.

The originator node broadcasts the block to all connected peers, a peer would discard the block if the origin is forged, only accept a 'bad' origin block if it comes in the process of re-broadcasting from a representative node

You can fake this. You need some kind of crypto mechanism here. So, you need to bind an address to a node or something like that.

The node would individually set a time-based dynamic threshold for blocks per same origin based on the saturation status of the Network (how many blocks are accepted from same origin by second)

Nodes would use their relative timestamp of block arrival to decide whether to vote for or against

Time in a distributed network is a complex topic by itself. You try to avoid using time at all, since you are not able to ever get a common understanding of "time" in a distributed network. There are some algorithms to solve some time issues, like the chandy lamport algorithm for global snapshots in a distributed system.

1 Like

Well, perhaps I couldn't explain it well.

  • Nodes are the Network
  • Somehow it doesn't feel right that anyone can set up any number of malicious nodes relatively easily. The Network must have a fair, democratic way to disregard traffic from these nodes.
  • You cannot fake the 'node_id' as it is part of the block, hashed and signed. You can forge it but it would fail at the nearest peer validation so it would be discarded
  • I agree with you the time-topic but I do not suggest to implement some kind of universal understanding of time in the network - quite the contrary. I am talking about the relative time of the individual node - how it perceives the influx of blocks from a particular node of origin.

You could create new node_id’s as quickly as you process new blocks, so it would have to be tied to the actual connection to verify, but not all nodes may be connected to every other node, so how would a node validate that it’s a valid node_id if it’s not connected to that node?

I agree in principle that it would be ideal to measure nodes and throttle/ban if they behave poorly. Even created this GitHub issue Establish metrics and a process to ban malicious nodes · Issue #2238 · nanocurrency/nano-node · GitHub

Since then nodes who provide invalid bootstrap blocks get banned as that was easy to detect and long hanging fruit. But I think there are many lessons to be learned from the various rules Bitcoin has as an example for things to try and ban other nodes for. @Qwahzi listed out quite a few in his comment to the GitHub issue.

Only connected nodes would need to make a decision based the 'node_id' field. If it's forged, they would discard the block automatically during validation. If a connected rep node receives a block and finds it valid it will broadcast it to all its connected nodes. So if a node receives a block from a rep node (as a part of broadcast) it would accept a "wrong" 'node_id'. This assumes a minimal level of trust in the rep nodes. In other words a this solution does not work if a representative node suddenly goes malicious.

How do you differentiate an original publish from a re-publish? They’re the same message type. Rep nodes aren’t “gatekeepers”. Blocks are published to random sqrt(peers) to propagate it through the network.

Would a node republishing have to add their own node_id and sign it when they republish? Could you not DOS other nodes then by sending 1 block to 1 rep node each?

I have to admit I am not aware of all the details of communication between nodes. Isn't it so that due to TCP a node 'knows' where a particular block is coming from? My understanding was that it wasn't the case when it was via UDP. If the node 'knows' where the block is coming from, it would accept a block from a rep node regardless of the node_id because it is re-broadcast.