Implementation of push / auto update feature on bitcoin (per configuration)

[pocesar]

We are in 2013, in the era of "browser apps" and self updating software, and all coins, even though coded in C++, have no reason to not have an auto update / push update feature for critical bugs / exploits / etc. How many people get stuck and clueless about new versions, since the Qt client have no "check for new version" button, unless they check the forums? It's understandable, for a pool owner, to not have auto updating software because it can break everything, so it could be disabled. But for the end user, there's no excuse.

Coin developers should try to get to a consensus and implement a simple hash version checking against the tags on github / sourceforge for example, at least to warn users about new versions (and even a distributed changelog / news about the new version, take a look at Filezilla that is open source)

Imagine having 16 coin clients installed on the computer, and manually having to check for new versions for each one? An auto-update makes sense doesn't it?

[rme]

Auto update = one man controlls the network

[pocesar]

Auto update = one man controlls the network

where do you get your client btw? isn't from the same place you get the source? your comment makes no sense

[gmaxwell]

"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.

[pocesar]

Right, the auto update / push feature "vulnerability" makes sense now, even though, by downloading it, you are already trusting a binary and/or source code, otherwise Bitcoin wouldn't exist, if there was no trust for the first place, no one would ever use it, so it's not introducing a "vulnerability" per se, if you already installed it, you have made a conscious choice for trusting it.
But since the client would be using only official repos (as most coins are using), and the binaries are downloaded from the same place, doesn't it make sense to have the check for a changelog or news about versions of it, like the recent changes that had vulnerabitilies fixed? this way people would decide whether to download or install it by themselves. Like it or not, even being open source, the source is already centralized either on github or sourceforge, if you want to see it that way.

And even further, only conscious users check the MD5 signature of binaries when downloading them, or decide to build from the source themselves, which is the minority, but most non-techie users don't.

Another thing, right now, it's not always possible use the bleeding edge compiled version of bitcoin-qt for testing purposes, because would be a hassle for core developers to keep with nightlies. Of course, reading git status is simple (with their public API), if the client makes this check on-demand by the user, it can be possible, or after a big commit that changes the inner workings a lot, like Firefox Aurora. You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries, thats a formal fallacy that it will always be decentralized.

[justusranvier]

If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

That's a phrase that deserves to be quoted for posterity.

[gmaxwell]

Right, the auto update / push feature "vulnerability" makes sense now, even though, by downloading it, you are already trusting a binary and/or source code, otherwise Bitcoin wouldn't exist, [...] the source is already centralized either on github or sourceforge, if you want to see it that way.

Its far more nuanced than you're making it out to be.

The binaries are directly tractable to the source code. The process that turns one to the other is deterministic, and multiple people (including people outside of the core development group) publish signatures signing that they got the same results.  This is what gitian does.  You can run this process yourself, and I think it would be great if you did.

The source code is transparent. Not everyone reads it, but many people do.  If something suspect goes into the source code, there is a pretty good chance that someone will call it out and sound alarms "do not install this!". ... and this is true if only a small number of people outside the core group are checking. This is only possible because they can check.

This audibility and transparency is essential.  But it's not fast. And if you have automatic update that are deployed faster than the loop can close— faster than the binaries certifications can be published, faster than people can review and alarm, then it would be centeralized then it isn't now.

You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries,

I'd love to hear how you think the "NETWORK" could be decenteralized in any meaningful way if the software which makes up the network isn't.

[pocesar]

gitian is an answer for people that know what they are doing (aka developers, system administrators, etc), that most of users of bitcoin-qt/daemon aren't. they download binaries from a link. unless it's implemented in the client itself, which I think would be overkill, they will just click a link and download. Plus, if you get this gist https://gist.github.com/devrandom/806265 it still uses sourceforge as a source, so it defeats the purpose anyway.

You are mistaking a decentralized NETWORK (that Bitcoin is and will always be) with a centralized distribution of binaries,

I'd love to hear how you think the "NETWORK" could be decenteralized in any meaningful way if the software which makes up the network isn't.

Well, you just contradicted yourself.

Bitcoin is a decenteralized system and is staying that way.

[gmaxwell]

it still uses sourceforge as a source, so it defeats the purpose anyway.

Not at all. I'm obviously failing to explain this to you, though I can't tell why. I'll let someone else have a crack at it.

[cr1776]

The easy answer then is for you to go ahead and implement the auto-update feature you are proposing, and then let the market decide if they want to use the fork that includes auto-update.

I believe that for the reasons stated above me in the thread that it is a bad idea, however since it is open source, anyone is welcome to add this feature to their branch and see how it competes with the non-auto update.

:-)

We are in 2013, in the era of "browser apps" and self updating software, and all coins, even though coded in C++, have no reason to not have an auto update / push update feature for critical bugs / exploits / etc. How many people get stuck and clueless about new versions, since the Qt client have no "check for new version" button, unless they check the forums? It's understandable, for a pool owner, to not have auto updating software because it can break everything, so it could be disabled. But for the end user, there's no excuse.

Coin developers should try to get to a consensus and implement a simple hash version checking against the tags on github / sourceforge for example, at least to warn users about new versions (and even a distributed changelog / news about the new version, take a look at Filezilla that is open source)

Imagine having 16 coin clients installed on the computer, and manually having to check for new versions for each one? An auto-update makes sense doesn't it?

[Schleicher]

This audibility and transparency is essential.  But it's not fast. And if you have automatic update that are deployed faster than the loop can close— faster than the binaries certifications can be published, faster than people can review and alarm, then it would be centeralized then it isn't now.

Nobody said that the auto update would have to be fast.
You could have a delay of one day or two so that the experts can check the binaries first.

[ShadowOfHarbringer]

If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

This may one day become a historical quote. I think I will print it out using big letters and glue it above the screen of my computer.

[gmaxwell]

It's not a comment I made likely, nor is it a new one— I've made the comment many times in the past.

Nobody said that the auto update would have to be fast.
You could have a delay of one day or two so that the experts can check the binaries first.

I'm not sure if you read the latter half of my response... since I directly speak to that.  I think there are possibilities in that space, but they are not so simple, because a simple delay does nothing if the discovery of problems cannot substantially block the updates.

[Schleicher]

Well, since bitcoin.org is recommending Multibit anyway, it doesn't really matter if Bitcoin-QT has autoupdate or not.
The average user will not use Bitcoin-QT.

[pocesar]

Well, since bitcoin.org is recommending Multibit anyway, it doesn't really matter if Bitcoin-QT has autoupdate or not.
The average user will not use Bitcoin-QT.

All 'alt coins' fork from Bitcoin-QT, not multibit. And it's not a matter of recommendation. Bitcoin-qt is also available in bitcoin.org. And even if the majority of users use multibit (which I'm not sure unless numbers are brought up), it doesn't have a 'check new version' as well, and serious 0day exploits can lead to losing wallets, coins, address collision attacks, etc

[Maciek]

If the core developers start telling you that you need developer controlled automatic update you can assume that we've somehow been compromised.

This may one day become a historical quote. I think I will print it out using big letters and glue it above the screen of my computer.

+1

I agree.
This is a very important quote.

[Mike Hearn]

Given that Matt already submitted code to make Bitcoin-Qt easily auto update, I think saying "it means we're compromised" is rather extreme. Matt certainly isn't compromised. He also runs the Ubuntu PPA which is basically a form of auto update for bitcoinds.

I think where we'll end up is with the core bitcoind not having any kind of auto update, and the end user wallets all will. It's security sensitive software so it's pretty important for anything end user facing.

[pocesar]

Given that Matt already submitted code to make Bitcoin-Qt easily auto update, I think saying "it means we're compromised" is rather extreme. Matt certainly isn't compromised. He also runs the Ubuntu PPA which is basically a form of auto update for bitcoinds.

I think where we'll end up is with the core bitcoind not having any kind of auto update, and the end user wallets all will. It's security sensitive software so it's pretty important for anything end user facing.

Exactly my point. If you already have trust in the coder behind the binary, how trusting his auto update hurt you more than installing manually?

[gmaxwell]

Exactly my point. If you already have trust in the coder behind the binary, how trusting his auto update hurt you more than installing manually?

You do not have to trust the coder behind the binary.

The binary is proven to be a result of the published source code— provable by you yourself, or indirectly by many unrelated parties performing the check and publishing a certification of their result (which already happens today).  The source code is open, transparent and generally developed with an open process so that you, your designees, and/or the general public can audit it and sound alarms if it does something unwelcome or suspect.

[Mike Hearn]

Yeah, we're heading away from a world in which programs are issued by one entity. The gitian work is pioneering - in future we'll see security critical apps like Bitcoin wallets, Tor and maybe entire operating systems go through reproducible builds with threshold signing quorums, distributed across many jurisdictions.

Matt's work had an auto updater that watched for the gitian signatures, therefore, it would take a quorum of signers co-operating to push a bad Bitcoin release. If it were really bad or controversial then people would notice and downgrade or switch to some other fork, but of course the network would have been running with the new rulesets for a small amount of time.

What I'd like to see is a hybrid model in which a large quorum (maybe 20-30 people) is required to sign for an auto update, and the people in that group agree to only sign for an auto update for security-sensitive fixes. The recent mod zero bug would qualify for instance, but fee changes wouldn't. Thus most upgrades would still roll out slowly, but if a buffer overflow or other way to compromise bitcoind was discovered the community could patch itself fast.

Incidentally, we've started work on reproducible builds for bitcoinj. It's not very hard fortunately, most of the issues are the same as for native builds (timestamps in the files, etc).