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 repu 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
