Fascinating project. I am wondering, however, about a couple of things.
(1) If the data is to remain intact for 100+ years, how will Bit Mountain handle changing data media and changing computer architectures, programming languages, etc? For example, will Python still be a viable programming language in 20, 30, or 100 years?
(2) What about software errors? Some have approached this through Byzantine fault recovery methods; "shells" of redundancy in the software. Given that you'll have to update or probably re-write Bit Mountain every few decades, and a software error could be catastrophic in those transitions, how would you handle it?
I hope Bit Mountain survives and prospers. Again, it's a fascinating project.
Discussions around miscellaneous technologies and projects for the general membership.
RussellHltn wrote:Another question - are you keeping stats of the equipment that fails? I assume that you're expecting that failed components are changed out within a certain time frame, and that drives will fail at a certain rate. However, drive failure isn't random. As the collection of drives approach end of life, the number of failures in a unit of time will go up. Possibly quite dramatically. (I'm not sure if anyone gives the standard deviation to the MTBF.) How will you monitor the situation to warn that the statical probability of failures is reaching an unacceptable risk and that either parts must be changed more quickly or that aging components need to be proactively changed?
According to the Stat's class I took, the failure distribution is usually modeled as an exponential decay function. One feature of such a distribution is that the remaining life of a particular device is independent of the history of the device. Assuming that this distribution is a reasonable model of real failures, there is no increased risk due to using many similar devices of similar age. This distribution also has no standard deviation.
cannona wrote:FYI, cryptographers are recommending that new systems no longer use md5. I would recommend SHA1 as a minimum, or, even better, SHA512. Even with a 128 bit hash, the odds of a colision are extremly small, but since you are designing a system that is supposed to last for decades, you may as well use the best technology you can.
Just a thought.
I don't believe that cryptographic attack of the hash is relevant to this project. It sounds like the hash is used for integrity check against accidental errors rather than malicious modification. The cryptographic vulnerability is relevant to the latter, but not the former.
Who is online
Users browsing this forum: No registered users and 1 guest