Will we ever see automatically pushed updates?

[Rawted]

Will we ever see automatically pushed updates? And if so, how long until that happens? I was curious as I just noticed another new version is out and was recalling the fork issues and other problems with past versions. This seems to be a needed feature, unless there are reasons it hasn't already been implemented.

[1715166068]

1715166068

[1715166068]

1715166068

[1715166068]

1715166068

[azeteki]

Automatic updates are not a good idea.

I would personally never run a client that attempted any form of auto-update mechanism and I believe the same is true for many others.

It is very important that users audit the client before running it. Or if they are unable, to at least wait for some more experienced people to.

This, by the way, is one of the reasons why services such as blockchain.info's wallet should be considered insecure.
Fancy 'client-side' JS doesn't mean a lot when remotely served (the auto-update mechanism is built in).

[Rawted]

Automatic updates are not a good idea.

I would personally never run a client that attempted any form of auto-update mechanism and I believe the same is true for many others.

It is very important that users audit the client before running it. Or if they are unable, to at least wait for some more experienced people to.

This, by the way, is one of the reasons why services such as blockchain.info's wallet should be considered insecure.
Fancy 'client-side' JS doesn't mean a lot when remotely served (the auto-update mechanism is built in).

There will never be mass adoption of a client if users (read non-techie, normal users) have to perform these tasks. This is a must, and a way to do it securely will eventually be figured out, imo.

[DeathAndTaxes]

There will never be mass adoption of a client if users (read non-techie, normal users) have to perform these tasks. This is a must, and a way to do it securely will eventually be figured out, imo.

No it will never happen and if it does it would represent a systemic risk to the entire system.  The reality is the vast majority of users will never run a full node.  Those that do will never auto-update.  An auto-updater installed into the majority of the full nodes would give a malicious user the ability to circumvent the entire security model on which Bitcoin is built.

[makoto1337]

Will we ever see automatically pushed updates? And if so, how long until that happens? I was curious as I just noticed another new version is out and was recalling the fork issues and other problems with past versions. This seems to be a needed feature, unless there are reasons it hasn't already been implemented.

We are using Java WebStart for the client for NEM (ournem.com), which allows auto-updating. Someone would have to gain access to our certificate in order to create a fake version for nodes to update to.

[Rannasha]

Will we ever see automatically pushed updates? And if so, how long until that happens? I was curious as I just noticed another new version is out and was recalling the fork issues and other problems with past versions. This seems to be a needed feature, unless there are reasons it hasn't already been implemented.

We are using Java WebStart for the client for NEM (ournem.com), which allows auto-updating. Someone would have to gain access to our certificate in order to create a fake version for nodes to update to.

A malicious third party is not the only threat with automatic updates. In your situation your users also have to trust you to not push malicious code through an automated update. Automatic updates mean that users should always trust the parties with the access to plan through updates, even with open source software. And that required trust in a centralised party is diametrically opposed to the core ideas of crypto currency.

[gmaxwell]

Access to control such automatic updates would be begging to be kidnapped at gunpoint. Not only would it be a systematic risk to the entire system, it would be a risk to the centralized parties with the access to control it.

Classical centeralized updates are undesirable to the highest degree imaginable, they would undermine the very motivations of the system— if you're going to trust someone to freely change the software, you might as well just have them maintain a ledger themselves: it would be much more efficient!

There are tools that could be used to lubricate updates, without creating so much risk— but the ultimate answer is that updates should not and must not be urgent: Even if you could somehow make automatic updates themselves safe, they're still not acceptable— it's not like people with their own patches and update procedures can freely accept the software changing out from under them at any time. Any uncontrolled change in behavior might undermine the user's own infrastructure and cause funds loss... so it's simply not acceptable to expect that everyone is going to run the same software at all times.

[btchris]

Automatic updates are not a good idea.

I would personally never run a client that attempted any form of auto-update mechanism and I believe the same is true for many others.

It is very important that users audit the client before running it. Or if they are unable, to at least wait for some more experienced people to.

This, by the way, is one of the reasons why services such as blockchain.info's wallet should be considered insecure.
Fancy 'client-side' JS doesn't mean a lot when remotely served (the auto-update mechanism is built in).

Completely agree, with two caveats...

I wouldn't have a problem if there was a by-default-off automatic update mechanism (although the type of user who would most benefit from this probably wouldn't know enough to enable it, which kind of defeats the purpose...).

Blockchain-style wallets, while certainly less secure than desktop clients in most cases, shouldn't be compared equal to coinbase-style wallets, which is a phenomenon I see occurring all the time (not to imply that your doing so).

Edited to add: it's not that there isn't a clear benefit to automated updates, it's just that IMHO the risks outweigh the benefits, especially for the type of user who I'd expect to be running the full-node clients.

[gmaxwell]

Blockchain-style wallets, while certainly less secure than desktop clients in most cases, shouldn't be compared equal to coinbase-style wallets, which is a phenomenon I see occurring all the time (not to imply that your doing so).

They should be— they're much closer in security model than you're giving them credit for— though this is a bit off-topic.  They can be silently and very subtly changed to give bad random numbers to signing operations, for example, thus constantly leak keys for months without being noticed.  You cannot argue that they're strictly superior to centralized wallets, since the centralized kind may be using things like HSM spending limits, offline keys, and insurance policies to make fairly strong guarantees on potential losses.  (not that I favor either… I just think the "but you have the private keys!" argument is highly misleading about the true security model)

[btchris]

Blockchain-style wallets, while certainly less secure than desktop clients in most cases, shouldn't be compared equal to coinbase-style wallets, which is a phenomenon I see occurring all the time (not to imply that your doing so).

They should be— they're much closer in security model than you're giving them credit for— though this is a bit off-topic.  They can be silently and very subtly changed to give bad random numbers to signing operations, for example, thus constantly leak keys for months without being noticed.  You cannot argue that they're strictly superior to centralized wallets, since the centralized kind may be using things like HSM spending limits, offline keys, and insurance policies to make fairly strong guarantees on potential losses.  (not that I favor either… I just think the "but you have the private keys!" argument is highly misleading about the true security model)

In both cases (javascript-crypto despite its many weaknesses vs server-stored keys), the level of trust you're required to give the developers is roughly the same*, as far as I'm concerned. However in the someone-hacked-the-server case, I'd argue that you'd be safer with javascript-crypto. As you pointed out a clever hacker should certainly inject difficult-to-detect malicious javascript (and javascript being a dynamic language only makes this easier to go undetected), but I'd argue that the developers/admins would eventually catch such an exploit, decreasing the count of affected users.

In the end it's all shades of grey. A particularly clever hacker might do the same to a desktop client (e.g. a pull request whose true nature went undetected for some period of time), it's just a matter of likelihood. If that's true, the question then becomes what are the chances that someone could succeed in stealing any given wallet in such an attack? For example, maybe it's 0.1% for a particular desktop wallet, 25% for a javascript-crypto wallet on a compromised server, and 100% for a fully hosted wallet on a compromised server. Or maybe it's 0.1% / 95% / 100%. I'm sure I'm not qualified to guess, though.

* You could argue that you need to trust javascript-crypto developers more, simply because creating safe javascript-crypto is somewhere between hard and impossible, and you have to trust that the devs really know what they're doing.

[giveBTCpls]

IMO automatic updates are a good idea for the third party lightweight wallets, but not for the people running actual nodes (Bitcoin-QT) because of obvious reasons.

[drawingthesun]

I can see a lite client having automatic updates and this client becoming the primary client for most Bitcoin users. However putting automatic updates on the reference client undermines the security of the entire system. It creates centralized control.

[rz20]

I don't like that option. If you run a node or some miner and you need to update them each week you will lose a lot of time.

It is not the same if you use for example multibit and they publish a new update, you just download from the website once you see the compilation is ok.