Question: How would the accounting system work?

[WillCodeCo]

Please forgive me for abusing the issue system just to ask you a question :)

I recently stumbled across your repo and I find the ideas here to be fascinating. I am very interested in trying to implement a subset of them in a project I am working on.

For the moment, I just have a question regarding the economic incentives...

"Therefore, each user simply picks an amount to donate to the network. This donation is then divided among all peers proportional to the amount of service they have provided."

How can the network achieve consensus on how much service Alice provided, in order to pay her a fair proportion of donations?

Do the consumers of content somehow provide proofs-of-service-rendered to the network so that the providers can be adequately reimbursed?

Keep up the great work!

[bytemaster]

Each node has a long-lived identity into which they have invested a lot of CPU cycles to find the magic nonce. As a result node IDs (public key + nonce) are hard to forge and relatively unique. (Every node is continually enhancing their ID by always searching for better nonces).

When designing the network, think of it from a 'local node' perspective, rather than a 'global perspective' and focus on what you can do with only the information you have locally.

Given a measure of how much time and effort has been contributed to a node id, I can filter who I allow to connect to me and how much 'credit' I extend them. I know with 100% accuracy how much service they have provided me and how much I have provided them as well as how much I have paid them and how much they have paid me. I can then calculate the NET SERVICE / NET PAYMENT to figure out how much this node is willing to pay me for service. I also know TOTAL SERVICE and TOTAL PAYMENT.

Once I know how much every node connected to me has actually paid me (historically) and the average ROI I can now prioritize service to every node connected to me and discontinue service to nodes are 'free loaders'.

From a user interface perspective, the user only picks how much they pay the 'network' and create a transaction that will send small amounts to every node they have used services from proportional to the services provided. For 99.99% of honest nodes they have no reason to discriminate and so the user interface is very simple.

Given that your node also knows how much it is being paid for services provided it can inform the user when service is being degraded because their connections are lower priority or entirely disconnected due to being shunned from the network for lack of payment.

The key here is that it must be more expensive to lose a trusted identity than to create a new untrusted identity and build up trust and confidence.

If you have C++ skills and would like to interview for a job to help develop next-generation P2P technology let me know, we are hiring.

[WillCodeCo]

Thanks for the quick reply. Yes that makes a lot of sense now. Each node makes decisions about who to extend 'credit' to and who to ignore, based on previous dealings (mutual services rendered / crypto-currency transactions), made possible by discouraging throw-away identities.

I wonder if this method would be compatible with overlay networks in which you want to stay anonymous. In some scenarios, such as in Freenet, you want to incentivise as many nodes as possible to achieve reliable and performant delivery of the data in demand, but you also do not want to give away too much information about your identity.

But perhaps this would still work, as you could then incentivise nodes to provide onion-routed tunnelling services, so one's true long-term id would only be visible to the first node in the tunnel.

I was thinking a bit about alternative approaches today and was wondering if there could be some way for a probabilistic payment scheme to work. So when a node performs a service, its 'customer' provides it with a receipt, which acts as a proof-of-service-rendered.

This receipt also invites the node to take part in a crypto 'lottery', where the prize fund is related to the significance of the service that was rendered (serving large file vs small one). So it would be similar to the crypto-puzzle-solving race that Bitcoin miners participate in, except that in this case, the more receipts you gather, the greater the odds are that you would 'win'

But then this might run the risk of price-fixing. So ill need to think about this more :)

Anyways, my current preoccupations are concerned with 1) Economically incentivised DHTs and 2) A better BitMessage. So it would be great if we could find some common ground that could tie in with the needs of Project Invictus.

I will try to write up an informal paper regarding 2) and then you can better assess if you want to interview me or not :)