On Apr 22, 2009, at 7:48 PM, Matthew Toseland wrote: > It has recently come to our attention that the problem with data > persistence > is usually that the top block has fallen out or that the few nodes > with the > block are never online at the same time as the person who wants to > fetch it. > Hence we need to duplicate the top block. So far there have been two > schemes: > 1) Duplicate the top block with SSKs: > SSK,3@<pubkey>,<cryptokey>,<extra>/<filename> would insert e.g. > SSK@<pubkey>,<cryptokey>,<extra>/<filename>-N for a series of N's. > 2) CHKs with extra routing keys: > CHK@<routing key 1>,<routing key 2>,<routing key 3>,<crypto > key>,<extra> > > Neither of these schemes is acceptable IMHO. The former allows for > an attacker > to insert different content to different keys, and get some info about > targets that way, and it is non-convergent, not allowing for > reinserts. The > latter doubles the length of the already way too long CHKs. > > I propose a new key type which is convergent, has URIs shorter than > existing > CHKs, and any number of duplicate blocks: the Content Multiplication > Key (for > want of a better name, alternatives are welcome).
Perhaps there is an easier solution? How about extending the chk logic into an alternate-chk-key (ACK?); that simply adds 0.25 to the expected location (for routing and storage). So when you insert the top block, put it in as a chk and an ack (no extra uri's neccesary). When you go to fetch it, if the chk does not work, try the ack variant of the same key. -- Robert Hailey _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl