[Netsukuku-vala] Participation rewards

[Luca Dionisi]

Netsukuku: Participation rewards

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 blockchain.info. 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.



--Luca