Here we will discuss some ways that people may try to defraud, game or exploit the proposed currency, along with techniques to avoid them. We´ll assume you are familiar with the basics mechanism of the currency.
Putting fake items on the list:
In this scenario, someone just adds fake items on the list, which would generally be considered good by most members of society, so that they are more likely to get people to help them.
Solution:
Every interaction requires that there is another party, so if you give a service then at least one person must have accepted that service and have the opposite reciept. Thus a fake item can be easily found by checking for missing or mismatched opposing items. This would involve the hardware dialling up other hardware and simply checking the other half exists.
Check-sums and encryption can be used to ensure that the actual data does not need to be transmitted over the network, just that it is the same. Also, when each item is created then a one-time pad of codes can also be created to prevent man-in-the-middle attacks whilst checking.
To reduce network use (if it is a problem) then only the most critical items that have the largest impact on the final score would be checked, in addition to a random selection of items (with a bias towards more recently included items).
Finally, it would be assumed that the software/hardware design could be such that it would be relatively difficult to add items to the list.
Deleting items from the list:
In this scenario someone would delete an item from their list so that they get a better standing.
Solution (I´m not totally sure of the solution to this one yet but I have a few ideas):
Solution 1, A check-sum of each item following on from the last item. This would take the form of some simple check-sum type computation based on each event and its proceeding event to create a value that is stored with that event in the list. Thus when an item is deleted the chain of check-sums would be destroyed and corrupted. However, it may (or may not be) computationally intensive to calculate these check-sums every time there is an interaction-
Solution 2, Check against back-ups. Elsewhere we discuss back-ups, it is concievable that these are stored publicly and each can have a check-sum, against which the whole list can be check-summed. To prevent someone from simply deleting an item and then re-saving the backup (thus saving the deletion) we can either use Solution 1 before backing-up or have incremental back-ups.
Solution 3, on publicly available database of who has interacted with whom, with minimal data stored, just the names of who helped who. This can be dialled into, names downloaded for the person of interest and then checked to see if any are missing from their own database.
Solution 4, make the hardware so that it is not possible to delete or overwrite data using a Write once read many (WORM) logic. Errors can only be handled by adding errata or notes later.
Working with someone else to create fake items on the list:
Someone could work with an accomplice and they could give each other fake items so that they get a better standing.
Initial solutions:
The system would not encourage this kind of behaviour as each "giving" item on one persons list requires an "recieving" item on the other persons list. So if one person gains from fake items then the accomplice will lose.
It could be possible to include into the system (though it would have to be very thouroughly thought through) a method of deleting such items. So that when two people perform two equivalent services for/from each other the two cancel out and get deleted or ignored by the algorithms.
Yet to be addressed
Backing-up data:
Network security, man-in-the-middle
Other issues, location of data storage, P2P:
Verifying false data