Matthew Toseland wrote: > The other reason why people don't stay is that it's too much hassle to > update your node when there has been a mandatory build and you managed > to miss it. Their node doesn't offer them the option to update, and they > don't know how to update manually, so they just let it go. The solution > to this is update-over-mandatory support, or to not have mandatory > builds, or to include support for downloading a new update from emu in > the node. I believe we need mandatory builds to debug load balancing, > if for no other reason. Downloading a new update from emu is possible, > with sufficient warnings; of course it would put load on the mirrors, > and of course emu can be spoofed or cracked. Update over mandatory is > also possible, and nextgens has made some steps towards it in recent > days (N2NTMs over connections to incompatible nodes). What remains to be > done is packaging a file into a verifiable bag of keys, allowing nodes > to tell other nodes about the latest update, transfer the data, and tell > each other when the revocation key has been cracked. We can mitigate the > effects of mandatory updates through time-bomb builds (this build will > become mandatory at time X), but we will always need some.
From my understanding, the reason this truly *is* an issue is that Mandatory builds no longer allow "older" nodes to update off of them, either immediately, or after a period of time. Presumably, this is because something major enough has changed within the operation of the new build to invalidate the prior client's method of connection (though I know this is not always the case). Would a possible solution, then, be to provide a superset "update" protocol that was less transient and able to be used even if your node was "out of date"? Perhaps this would let a "Fallen behind" node connect to an upstream peer to at least pull down the update? -- Ken Snider
