[p2p-hackers] decentralized incentive engineering: GNUnet

[R. A. Hettinga]

--- begin forwarded text


Status:  U
From: "Zooko" <zooko at zooko.com>
To: mnet-devel at lists.sourceforge.net, p2p-hackers at zgp.org
Subject: [p2p-hackers] decentralized incentive engineering: GNUnet
Sender: p2p-hackers-admin at zgp.org
Reply-To: p2p-hackers at zgp.org
List-Id: Peer-to-peer development. <p2p-hackers.zgp.org>
List-Post: <mailto:p2p-hackers at zgp.org>
List-Help: <mailto:p2p-hackers-request at zgp.org?subject=help>
List-Subscribe: <http://zgp.org/mailman/listinfo/p2p-hackers>,
	<mailto:p2p-hackers-request at zgp.org?subject=subscribe>
List-Archive: <http://zgp.org/pipermail/p2p-hackers/>
Date: 22 Aug 2003 12:36:14 -0400


Hello mnet-devel and p2p-hackers.  I've written some notes about a GNUnet 
paper and put it on my "http://zooko.com/reading.html".

After waiting in vain, for about an hour, for my friends to check my web page 
and write letters to me about decentralized incentive engineering, I lost 
patience and decided to send it to these lists.

--Zooko


An Excess-Based Economic Model for Resource Allocation in Peer-to-Peer 
Networks

dura-link [1] v1.0.1 entry above [2]

This is a reasonable stab at the problem from an engineering approach. The 
ideas are actually implemented, as I understand it, in GNUnet. It is 
completely decentralized, and they've given thought to the detailed problems: 
newbies, transitive operations, systemic attack resistance. It feels like 
exploratory work, and the author admits as much. He includes, for example, a 
"proof" that the attack resistance of the system as a whole is bounded by the 
attacker's bandwidth, but it is so specific to GNUnet's design and its 
assumptions that it isn't an exciting general result. These GNUnet-specific 
assumptions include that all traffic is request-response pairs, the requests 
are the only things that trigger consumption of resources, the responses are 
verifiable (except that this verification isn't yet implemented in the current 
GNUnet), and so on.

Still, to his credit the author is clear that this is exploratory, and he 
clearly indicates his plans for future work.

On a personal note, it is bittersweet to see some ideas that we implemented in 
Mojo Nation being reinvented here, such as the central notion of 
"excess-based" accounting, in which services are free when the server is idle 
anyway. I don't feel pride about this -- rather I feel regret that we didn't 
document what we did, and gratitude that the GNUnet folks are doing the world 
a better service by documenting their ideas. Also, of course, GNUnet is not 
identical to Mojo Nation, as GNUnet lacks the centralized component that Mojo 
Nation had.  

The basic approach that GNUnet takes to decentralized incentives is very like 
what I've been planning for Mnet v0.7. For anyone out there who is familiar 
with Mojo Nation, it is pretty much what you get by leaving the 
"KEEP_RUNNING_WHEN_TOKENSERVER_IS_DOWN" flag set and then adding some tweaks 
to favor the most useful of your peers. If you are interested in decentralized 
incentives in Mnet v0.7, you should read this paper.

[1] http://zooko.com/reading.html#notes_GNUnet_ExcessBased_Economics
[2] http://zooko.com/reading.html#entry_GNUnet_ExcessBased_Economics

_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com