Monday, February 24, 2014

Participation rewards

Recently I read about a fresh new project that shares with netsukuku a lot of principles.
This project aims to create a mesh-network where the collaboration of the nodes is rewarded with a crypto-currency. This currency is then used as a payment for sending ones own trafic over the network.
Francois Zard, the ideator, contacted me before going public, asking for clarifications on the status of our project.
I wish him and his project to grow up well.

His idea made me think about the possibility to exploit the features of netsukuku network protocol in order to have a similar rewarding scheme. After a few days I came out with a rough idea that I share with you.

The rewarding mechanism

A new feature of Netsukuku will allow the participants to give a reward in money to the owners of the nodes that permit them to reach their favourites contacts and services.
This is on a completely voluntary basis. The network remains free of charge for everybody.

There are many projects today that have the goal of building a self-sustaining network where participants are incentivised to improve the network. The key point in all of them is to reward not just the provider of a service, but the owner of the nodes that make it  possible in the first place the connection between client and server.
Many of the proposed payment schemes try to reproduce how the bitcoin transactions work, but with a new digital crypto-currency.

Netsukuku will take no effort to create a new currency, and not even be tied to the best payment solution that we could find. It will just make it possible for a node owner to reward the right people. More precisely, the owners of the nodes that are in a precise instant connecting him to his favourite friends.

Netsukuku will not, of course, expose their identity, but only a payment address that is at their disposition.

The actual payment processor can be anything that has the required properties. There can be at the same time more than one.

A first implementation of this will use Bitcoins, the real thing. With most probability it will use Coinbase services, because it is good for us to have a practical way of enabling micro-payments with no fees and with low delay confirmations.

At the moment I figured out 2 types of payment procedures. One is initiated by the client at his will. One is required by a service provider.

Client-initiated procedure

A node owner, say A, uses frequently a certain service hosted on the node of another participant, say B. Or she speaks with B owner via a VoIP application that contacts directly the node B.
Supposedly, A might be willing to donate, every now and then, some money to the nodes that make her communications possible. Because she wants them to keep on running their nodes and possibly improve their links.
Node A will send a particular message to node B; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address (or other payment address, but for now we refer to this). Node B responds to A with the list of addresses and A can make the payment.
Obviously A can make this donation whenever she likes and for the amount she likes. A good strategy for A would be to make frequent micro-donations during the very same hours when she uses the most the service that she cares.

Service-required procedure

The owner of node S (S=server) provides a service to his customers. He wants to get paid for this service based on the volume of trafic that is used.
S might be willing to share (a part of) his income with the nodes that form the link from his server to his customer. Because he wants to incentivise them to stay and new nodes to arise for him to be reachable by a broader mass of potential customers. Hence, S advertises that he is providing a service through this channel with this feature.
A client C sends a particular message to S; this will trace the nodes that make up the best route right now, and obtain from them a Bitcoin address. Node S will append its own Bitcoin address and respond to A with the list of addresses and the amount of payments that he has to do to each of the addresses per unit of trafic. Furthermore, the nodes that form the link will be notified of the IP address of C and S and the amount that they are going to receive per unit of trafic. These hops might then verify every now and then the payments and (if they want) temporarily block the trafic on this flow if they don't receive the payment.
A consideration: C could "cheat" and not make the payment to the hops, because he thinks that they will not check. But for sure he will not be able to cheat S, because he will verify, of course, and deny the service. So S, if he really wants to reward and incentivise the hops, could ask for a slight bigger price for his service and then take care on his own to donate back to the bitcoin addresses that he receives with the message from the client C.


What has been briefly exposed until now is plausibly feasible with any payment processor that possesses some properties.
Now let's take the assumption that the Bitcoin network is used.
Here are some considerations about the problems that arise with this choice.

First, not all the nodes are required to participate to the service.
But only those who participate can be rewarded or initiate a payment.

When a node participate to the service, the only requirement is to be configured with a Bitcoin address where he can receive payments. It is advised to generate a new valid address for each payment, if the node is able to do it; but it is not mandatory.

If a node wants to be able to check the payments then he needs to get connected to the bitcoin network. Or at least to get connected from time to time to the Internet and use some host which provides informations, such as This requirement is not particularly hard to satisfy. For example it's enough if the owner of the node has got also a computer which is connected to both the netsukuku network and to the Internet.

If a node has trouble to get to the Internet but wants to participate he can do. It will not be able to check the payments, so it shall never block the trafic. Nevertheless it will probably receive payments, because when the network is highly dynamic it's hard for the client to know in advance which hops will verify the payments and which ones will not.

A node that wants to pay (or donate) could do this by having a bitcoin client and having access to the Internet. Anyway this requires big computational and memory resources. Further, it would be prohibitive to send micropayments because of the fees built into the bitcoin network.
There is a better alternative if the payment address of the sender and the receiver are both accounts of Coinbase service. In this case micropayments with low delay and no fees are possible. Furthermore the client just need to use the API of that service and this can be done with very low computing resources.

Final note:
The porting goes on steadily. I presume to have a first version ready for the masses before summer. I hope obviously to be able to implement also the rewarding system.

No comments:

Post a Comment