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
