Robert Hailey wrote: > 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.
At the moment each node on the path can verify that the data sent by previous hop corresponds to what it ought to; How would that work with your proposed solution? NextGen$
