1. Universität Rostock1 A P2P network traffic and access control protocol Herwig Unger Albert – Einstein-Str. 23, 18051 Rostock, Germany Phone: +49 381 498 3365, Fax: +49 381 498 3366 E-mail: hunger@informatik.uni-rostock.de

2. Universität Rostock2 Motivation decentralized P2P system recently gained an increasing popularity due to a lot of advantages communities are built on the base of such systems reflecting it its structures the social relations between ist users however, contents is offered only by a small group of users – e.g. 5% of all machines host 70% of all contents offering contents is not attractive for the users, since hereby a lot of bandwidth is taken to answer remote user‘s request lurker and freerider mostly take advantage from such systems Powerful control mechanisms are needed to control traffic and access of resources

3. Universität Rostock3 Ideas: what can be done with virtual money Special services (not standard services like search) and information are only available for an additional payment. High priorities for the service execution are given for additional payment, since these priorities may cause shorter answer times. Bandwidth will be limited. Standard user communication is either done with a small percentage of the available communication bandwidth or only available, if the network load is not to high. Hopcounters of message chains are lower for standard users. Therefore, standard users may not see the whole size of the network and cannot access to all available information.

4. Universität Rostock4 Requirements to virtual money 1.An amount of money represented through tokens must be generated in the community. 2.The amount of money must be adapted to the number of community members and therefore the potential to offer services/resources in a community. 3.Fault tolerance and copy protection must be provided by decentralized algorithms. 4.Safe trading mechanisms must be described Virtual money on the base of a token population shall be used with a respective transmission protocol

5. Universität Rostock5 Building trust Trusted third authorities (machines) Duration of mutual relations + possibility to predict the other‘s behavior witnesses, control by a group of other machines e.g. trust chains

6. Universität Rostock6 Control of the token amount f(community_member) oThe number of tokens in the population can be controlled with a decentralized mechanism. oEvery node generates and kills tokens depending on the average time between the visits of 2 tokens. oThe existing number of tokens is an almost stable value over the time and depends from the number and characteristics of the community members. Statistics of the token population

7. Universität Rostock7 Statistics for the amount of money Statistics – difference between token generation and removal for every node oTokens removal means to destroy money, which is owned by one of the community members. oEven if the monetary value is small, too large lost / win by this process must be avoided. oSince the process is done pretty randomly, the „+“ and „-“ are well balanced for every node of the community over a linger time.

8. Universität Rostock8 The token structure

9. Universität Rostock9 The copy safe protocol for money token Time K=2 logical transfer physical transfer by protocol a) Forward (FWD) Protocolb) Token transmission realized by the protocol Machine iMachine i-K (witness) Machine i+K FWD_witness FWD_i+1 Acknowledge RCV Acknowledge FWD Acknowledge FWD_i+1

10. Universität Rostock10 where is equal. 1.The probability that k nodes are active is 2.The probability that a machine is in the network is not equally distributed over the whole day. It will be significantly higher a few moments after the time when it has been already seen in the network. 3.The exponential distribution can be used to model this stochastic lifetime problem. 4.If a computer c i has been a member of a community at time t i, the probability p(c i ) that it is still connected with this community at time t' i (with t i < t' i ) is given by Analysis I

11. Universität Rostock11 Analysis II 5. Therefore, the probability p(n) that at least n of K machines are available after some times is given by what can be estimated for equal, average transmission and processing times by with 30 machines are a good compromise

12. Universität Rostock12 Fault tolerance In case the of no response of the owner node x, the token will be forwarded to the next node without replacing x for a fixed set of L cycles; i.e. in case x joins the community in this time again, it will still have access to its coin. After L cycles the money is assigned to any node from the history. If one other node i-K does not respond, i-(K-1) will be used instead. All predecessors j in the history, j=i-(k-1) (1) i-1, will be put on position j-1 and for position i-1 a randomly selected, new node will be contacted and obtain the needed information of the token. For security reasons, this replacement can be done for limited number of nodes in the history, only. Every owner of a token may keep a copy his tokens. In case one of the tokens is not returned to its owner within a timeout interval, it may use the copy to contact all nodes kept in the history, find out the place of loss an re-initiate the respective token game.

13. Universität Rostock13 1.The owner crypts his own and the IP address of the receiver (typically with its private key) and put it on the token. 2.The new owner is set as the successor of the old owner in the forward cycle. 3.The token pass another cycle over the new owner and K-2 randomly selected machines. 4.The machines along the history trail check the authenticity of the token and store the old and new owner information. 5.For a second cycle, the old owner adds again the new owner as its sucessor. 6.Now, the new owner replaces the two IP addresses attached by its own (crypted with its provate key), only. This change can be confirmed by the nodes of the history, since they do know both addresses from the last cycle. 7.The token forward will be continued with the new owner (i.e. a new node, where the token return to after K-1 steps). Trading

14. Universität Rostock14 Network traffic control 1.tokens are used. 2.the number of tokens will be controlled by all community members in a decentral manner, again. 3.the tokens are not used as money but as PERMIT to transfer messages or data ackages with a fixed size. 4.tokens use the before introduced protocol, messages / date may be sent directly. 5.from community members, only incoming messages authorized by tokens are accepted.

15. Universität Rostock15 Conclusion oThe introduced probabilistic money system may control access and traffic in P2P communities in a fair manner. oThe user do not see the trading activities but the knowledge about its existence may force him to contribute resources. oThe properties of the payment system differ from real money. oThe developed protocol ensures probabilistically security and copy protection for the money tokens. oOn top of a non-stable community a stable structure is built, which probably can be used for other applications, too.

16. Universität Rostock16 Thank you for your attention !Contact: Herwig Unger FB Informatik, Universität Rostock D-18051 Rostock Email: hunger@informatik.uni-rostock.de Telefon: +49 381 498-3355