Bitcoin Forum

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?

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

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

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.

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

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.

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.

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.


Well, you just contradicted yourself.

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.

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.

:-)

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.

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.

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

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.

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

+1

I agree.
This is a very important quote.

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?

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.

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

An idea I find attractive is to have the ability to have signers who can only give "negative karma"— these keys could be issued pretty liberally, since the only risk is that they delay an update. This models what we already believe to be the primary existing source of assurance: "if something bad is done, someone somewhere will sound an alarm". Coupled with suitable delays this could be pretty powerful.

The tricky part is having a jamming resistant way to get their negative views out to people.

It's too bad we don't have some kind of data structure that is automatically replicated to all Bitcoin nodes, and has some kind of "fee/KB" mechanism to discourage spamming it.

I'm not sure that I'd want to promote mined transactions as a jamming resistant communications channel. Especially since, you know, it's not actually jamming resistant, and it's not hard to imagine examples where the miners would actually be interested in jamming NAKs on an update.

Perfect enemy of the good yadda yadda. The current alert broadcast mechanism would probably work OK for that. Hopefully it'd hardly ever be used. The difficult bit would be testing it in the real world.

NAK's in the blockchain don't need to be exclusive though. For instance the protocol can be that NAK's are just some signed data, and you don't care how you get the data. For some scenarios putting it in the blockchain is great - the dev team goes crazy and backdoors the RNG - for others you're going to have to hope some other jam-proof communication mechanism works, like P2P distributed alerts or DNS seeds or whatever.

The big advantage of the blockchain is that many attacks aren't going to be very useful unless the target is synced with the network. Someone might, say, backdoor the RNG or make transactions be signed using nonces the attacker can predict. But users whose clients do manage to sync with the network will see the alert and not upgrade, and the ones that don't (because the attacker isolated them) are likely to do fewer transactions because they notice their client is acting funny and tx's aren't confirming or whatever.

Obviously the attacker could also fake parts of the GUI to make it looks like tx's are confirming, but now the number of lines of code they need to hijack just got even larger, making the attack even ever to spot.