----- Original Message ----- From: "Will Glynn" <[email protected]>
> > Basically, we keep our current minimum and before we release, > > we set a date (say we released today, we'd set the date at > > the 29th of january) at which point the minimum build increases > > automatically to the new one. > > Remember one of the Code Red variants? It was supposed to extinguish itself > if the day of the month was after 20 -- and indeed, it did. But there was > one small problem: not everyone's clock is set right. A small fraction of > the infected machines had a different date and remained active, so when the > month rolled over, mass re-infection happened. > > Lesson learned: don't trust dates. This could work if you got your date > from, say, an NTP server, but that's not anonymous... Actaully, it's not a problem. Having some of the network allowing connections to older nodes won't prevent the majority (which is what I'm trying to affect) upgrading the nodes. Those few nodes in the grand scheme of things most likely won't affect the network greatly. I'm just looking at the large change over the entire network, not at a closer scale. > I would say the best idea would be to release a build now (with a specific > number) and use a different number for the 0.5.1 release. As soon as the > first build sees a set number of the second build in the routing table, it > assumes 0.5.1 has been released and increases its minimum build. This would > make those constants most decidedly not constant, but it is reasonably > graceful and hard to fool (if the threshold is high enough). > > Feel free to pass these ideas to the devl list. Passing it along via sending my reply to the mailing list. > --Will -Mathew _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
