~~~... As for autoupdate, that is what we are most focused on. We are working on an implementation that would cleanly and painlessly update the wallet automagically at once. and do all the mumbojambo
Please do think this through carefully - whilst there are technical solutions to auto-update (eg code signing & having the client validate signatures on update packages etc), pools & exchanges must have the ability to disable it and it is very hard to defend against the "one man controls the network" argument - if we want Cache to succeed (and I very much do!) we have to be careful about the perception of centralization.
Here's an interesting post from Greg addressing this topic in the Bitcoin context as food for thought
"Auto update" is categorically not the same as manual updates.
Bitcoin is an autonomous peer to peer system. It's security, its promises of non-inflation, everything that makes it valuable depends on someone not being able to just flip a switch and redefine it. As you say, "there's no excuse" to introduce that kind of vulnerability. Bitcoin was invented to remove the requirement for that kind of trust, and if you're willing to have that kind of trust you can build systems which are much more efficient than Bitcoin.
Someone with the ability to just push auto updates would be an extreme danger to the network, and that ability would be a potential danger to those who possess it by virtue of making them an attractive target. If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
There are certainly things that can be done to facilitate smoother updates and we should do them: For example, deploying the gitian updater tool for users to use which checks the gitian signatures and saves them some website clicking would be a nice improvement and would strictly reduce vulnerability. (since not that many users bother to check the signatures today when they update)
Any system which would run _automatically_ if any were to exist at all, however, should only work on a long randomized time delay to allow review and alarm if there is a problem and should support negative acknowledgements, the keys for which could be spread fairly liberally.
So go ahead with your "16 coins" run autoupdates for 15 of them. Bitcoin is a decenteralized system and is staying that way.
Bitcoin is an autonomous peer to peer system. It's security, its promises of non-inflation, everything that makes it valuable depends on someone not being able to just flip a switch and redefine it. As you say, "there's no excuse" to introduce that kind of vulnerability. Bitcoin was invented to remove the requirement for that kind of trust, and if you're willing to have that kind of trust you can build systems which are much more efficient than Bitcoin.
Someone with the ability to just push auto updates would be an extreme danger to the network, and that ability would be a potential danger to those who possess it by virtue of making them an attractive target. If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.
There are certainly things that can be done to facilitate smoother updates and we should do them: For example, deploying the gitian updater tool for users to use which checks the gitian signatures and saves them some website clicking would be a nice improvement and would strictly reduce vulnerability. (since not that many users bother to check the signatures today when they update)
Any system which would run _automatically_ if any were to exist at all, however, should only work on a long randomized time delay to allow review and alarm if there is a problem and should support negative acknowledgements, the keys for which could be spread fairly liberally.
So go ahead with your "16 coins" run autoupdates for 15 of them. Bitcoin is a decenteralized system and is staying that way.
Auto update will be optional. You'd be able to disable it. Also, auto update won't just update your wallet straight away, it will notice the update and notify you. If, you won't push the allow update button until the time when your wallet will be rejected from the network by newer wallet, it will update automatically (this won't happen if you have autoupdates off). So the auto update is somewhat not very auto. It's manual until required. And there will be an option to roll back. The packages will be signed and checked upon the auto update, and rejected if found invalid. Also, the wallet will have self diagnostic upon startup, veryfing signatures before loading itself. This would ensure that your wallet hasn't been infected by viruses or compromised.
I'm pleased to see you guys have obviously put some thought into it
I'd be interested in your thoughts around the 'traditional' model (ie broadcasting an alert in cases of required updates with integrators (pools/exchanges etc) polling the errors attribute from getinfo). Is the general feeling that it's insufficient, or that integrators do not follow this model even when available, or other factors? Or is the target audience for auto-updates primarily the end user?Hope I'm not distracting you with this discussion, just throwing in feedback where I think you may get value from it
Cheers