Threat of mass usage of the rep field for arbitrary data

I feel like there hasn’t been enough discussion directly regarding the risk of rep fields being used for storing arbitrary data. A demonstration of how data can be stored is a tool I made that converts 16x16 binary images to and from nano addresses that can then be set as a representative. This usage of the rep field is of legitimate interest, for example in this Banano project for layer 2 NFTs.

If this data storage solution becomes used in the future in projects on Nano, how severe is the risk to network security? What could be done in this situation to mitigate the risk?

4 Likes

There has been discussion before about whether it is possible to require representatives used in blocks to be either online, or at least be an open account, at the time of initial publishing (although I cannot find references atm). Of course with nodes having different views of the network state as a whole this gets tricky, but if a solution were found, this would make these types of approaches to adding data to the ledger unreasonable.

At this point there is no guarantee that the ability to push arbitrary representative accounts into the ledger will remain, so it is advised not to design applications around this assumption.

Even if you advise not to do, what is the impact and likely solution if this occurs irrespective of the stated NF stance? It’s demonstrably a method that people are inclined to use, so it’s a plausible situation.

Impact: Less online voting weight.
Solution: Keep only a small amount of Nano on such accounts, so it won't affect the network.

That’s an individual solution, I’m more interested in the protocol-level solution given non-compliance from users.

Users with high Nano balances are interested in the stability and reliability of the network, so they will most likely assign their voting weight to valid representatives. IF this will ever become a real issue, then the protocol could be updated to Zach's suggested measures above, but I don't think this will be anytime soon.

People thought massive spam wouldn’t happen anytime soon, and yet here we are. I don’t think it’s productive to ignore things because they “probably won’t happen,” and it would be good to have concrete solutions discussed before it ever DOES happen. If you have an idea of how to implement a policy to ensure representatives are legitimate, I would be very interested in hearing it. I personally haven’t thought of a good way it could be done, so I’m curious what others think.

2 Likes

If no one else has a specific solution, I suppose I can float a rough idea I have in the event that dead weight becomes a significant issue.

A new block type could be used as a sort of “ping” for rep changes. Say account A wants to change their representative to rep account R. A sends a changerep “request” block with R as the recipient. R publishes a changerep “accept” block which functions as a dual send-receive for the changerep block. A then receives or “verifies” the changerep accept block from R.

To help prevent abuse as well as to encourage setting your representative to an actually online rep, the “verify” block must have the “request” block as the previous block.

Any thoughts on this?

1 Like

How about requiring that the rep has a block height above zero?

This seems like an elegant solution

This effectively provides a proof that the representative was online at the time the rep change was attempted, which is stronger than the approach @mustacheman and I mentioned of just checking locally for an open block on the account. Whether that stronger proof is worth the extra complexity and resource usage/additional network activity would need to be evaluated, along with any potential attacks this could open up, including DOS on representatives.

A stronger guarantee is requiring recent voting having been seen from that chosen representative. Currently the votes are only rebroadcast when published by PRs, not non-PRs, so that creates a bigger opportunity for inaccurate evaluation of the liveness of a particular representative for different nodes. But longer term if vote storage was put in place, that might allow validation of recent voting even if a particular node hasn't seen it directly (query for stored votes). Of course this is also subject to attack/DOS concerns and has quite a few dependencies before it becomes possible.

If the need arises in the short term, the local check is the most reasonable to stop obvious data injections such as random CIDs from IPFS like in the banano example.

2 Likes

Thank you, that clears things up for me!

I think this technique can be simplified. You don't need an request/accept pattern. You just need a single proof that the rep address is capable of signing a block. What this really proves is that there is a private key matching the rep address. If the rep address is encoding non-random data, then the only way to have the private key for it is to brute-force a huge number of private keys until you get one that converts to your target data. But that is computationally infeasible (if you could do that, you could find the keys to take over any nano account). So if you can sign any one piece of data for that address, then you have proven that the address data must be generated from a private key, which means it was not generated by encoding some other non-random data.

So if the rep address has a chain height higher than zero (as mustacheman suggested), that in itself should be sufficient proof that the address is not encoding meaningful data. If the chain height is above zero, that means that at least one block has been signed by the private key matching the address.