On Thursday, June 17, 2010 David Barrett wrote: > Just curious, is there evidence that aggressive leaching is so > prevalent to even require these currency systems?
Never heard of such evidence. Always thought this to be a solution in search of a problem, really. In fact, I thought that this was exactly the hint that Zooko was dropping with his question about MN history. Was kind of surprised to read all the serious history descriptions that followed - though enjoyed them anyway... :) Best wishes - S.Osokine. 17 Jun 2010. -----Original Message----- From: p2p-hackers-boun...@lists.zooko.com [mailto:p2p-hackers-boun...@lists.zooko.com]on Behalf Of David Barrett Sent: Thursday, June 17, 2010 5:45 PM To: theory and practice of decentralized computer networks Subject: Re: [p2p-hackers] Alpha testers needed Just curious, is there evidence that aggressive leaching is so prevalent to even require these currency systems? I think the brilliance of BitTorrent isn't its tit-for-tat, but how it uses social norms to ensure a high seeder ratio for popular content. So far as I know, every popular BT client has defaults configured to auto-seed when the file finishes downloading. There's no technical reason why this should be the case -- indeed, it's ostensibly in the user's interest to just stop when the download is done. But due to the social pressure of the BitTorrent community, the defaults are set to be pro-community rather than pro-user. And so few individual users care to trick out their clients that it results in a community that has an unnecessarily high seeder count -- even though there is no meaningful enforcement mechanism. ** Indeed, I expect the primary reason people stop seeding is because seeding is made unnecessarily painful (no effective throttling), and due to the legal risk. If a system were to address both of those (effective throttling so seeding doesn't come at the expense of your personal experience, and perhaps always-on encryption with a built-in onionskin network to muddy the legal waters), I wonder if it could get even higher seeder ratios purely through leveraging community generosity, without bothering with all the complexity of a byte currency? -david ** I'm referring to the public trackers, not private trackers. Maybe the private trackers are better -- maybe they have high seeder ratios even further down the long tail. I've never used them I don't know. But my point is on the public trackers, popular content has a higher seeder ratio than one would expect if we assume users are generally biz zealots. Jim McCoy wrote: > On Jun 17, 2010, at 5:40 AM, Will Morton wrote: > >> [...] >> While you're here, Zooko, a MN question (perhaps a memory test :-) - >> my understanding is that in a MN network, an uploading node sends data >> until a threshold is reached, at which point it demands a Mojo token >> transfer. How does the protocol deal with a node downloading data up >> to the threshold, then disconnecting, and repeating this process with >> other nodes, hence downloading without ever paying anything? I ask >> because I'm currently implementing an escrow system within robonobo to >> deal with this attack. > > An attack that was called "flaming smurfs" internally. The general idea was to require an up-front token at the beginning of the transaction, which had catastrophic consequences when combined with the original "set your own prices for services" model because savvy gamers of the system realized they could take advantage of these two properties to demand an outrageous up-front fee for establishing a connection and then just drop the counter-party and wait for the next sucker. Using the second-gen paris metro pricing model (pay for "do it now" requests while system upkeep tasks and low priority tasks were in the free category) solved this partially and I think we tried "split tokens" for a while, but in retrospect I would recommend you make the first transaction be a hashcash-like proof of work exchange; decide who is benefiting from a particular task or transaction and use a proof of work exchange to handle the first transaction between two nodes that have no established re pu > tation/history between the counter-parties. > > Since trustworthy distributed accounting is deep in the "hard problem" territory you could also use this alternate currency to deal with accounting discrepancies such as when party A thinks party B owes it tokens but party B disagrees (usually caused by network problems like half-failed transactions, etc.) -- party A "writes off" the debt in real tokens but will demand that party B make up the difference in proof of work tokens before it considers party B trustworthy enough to engage in normal commerce. > > jim > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@lists.zooko.com > http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
