Bitcoin Forum

Would be updating automatically, or at least informing the user that a new version of the Bitcoin client is available.

FileZilla, VLC, uTorrent, and many other open source projects do this quite nicely. Could we simply borrow their code?

Would bitcoin's decentralized nature might make this a bit more difficult?

Nobody would feel comfortable associating just one domain name with the "update notification" code I doubt, it would be too simple of an attack vector. Perhaps once we get the bitDNS and/or namecoin setup...

The new distribution/download script devrandom is working on for gitian and bitcoin 0.4.0 should be able to handle such things in a couple version out.  It also solves the trust issue as it requires a certain number of trusted developers to sign a new release after building it themselves deterministically before it will download and install the new version.

I strongly disagree. (on topic to another thread: does that make me an extremist?)

Automatic updating is merely yet another attack vector. I highly doubt it could be made secure. Is there any other money handling software that automatically updates?

How could you exploit a system which requires developers to sign the results with gpg?  You'd have to steal the gpg keys of multiple developers.

People should have to think about the things being added or changed in a new version so that the core of bitcoin isn't changed.

That is the point of distributed signatures.  Developers who are trusted by the community put their stamp of approval on changes.  Any interested users can obviously still watch the changes and chose for themselves but, lets face it, 99% of users just don't care.  Many of the changes are changes in tx requirements for mining and other small things that no one but small groups care about anyway. 

apt-get

Have fun getting that to work while we are still on wx 2.9.  Plus the recommended package will be the downloaded which checks trust on binaries before they are distributed (instead of the bitcoin binary itself).

I asked it some times ago :D
http://bitcointalk.org/index.php?topic=259

I responded before I saw your post. Do you have details on the implementation you describe?

I just thought of a potential problem the open sourced bitcoin community might face...

How many people currently have to "ok" a release?

What if tomorrow the value of BTC jumped up to $100,000 USD/BTC and Gavin decided he now wanted to "round" every transaction down and send the remainder to his own account (like the plot from "office space").

No offense to Gavin, but most everybody has their price.  :-\

OK, but the transaction record is public. That hack would make for some interesting reading on blockexplorer.com.

Sure, but the damage would have already been done.

One could (in theory, if (s)he were in charge of releases)...

1) Round up (or even direct the entire transaction amount) to his/her bitcoin address.
2) Sell as many bitcoins as they possibly could on any/every market within 24 hours.
3) (OPTIONAL) DDOS the bitcoin.org forums for another few days until their payments came through.

As of right now, that person could probably steal a few hundred thousand USD.

In the not too distant future, that person could feasibly steal millions of dollars, in less than a day... I regrettably imagine that there are already some people with similar plans.

I don't agree. The agency managing the automatic updates can instantly transform the network into whatever they want. They would be pretty much like the Fed.

Anyway, every p2p network works better if it has every clients updated ;)

Current build instructions are at https://gist.github.com/806265 (https://gist.github.com/806265).  The download/install/etc script is still a WIP, but you'd have to ask devrandom for more details on that.  Current signed copy of 0.3.21 is available on request (signatures in bitcoin-release repository of devrandom on github).

Well, I am not opposed to an automatic update system as long as all of the current developers agree that there aren't any security concerns, it is optional, and the user is prompted to update.

Google Chrome auto-updates without user knowing, and while many would argue that's a privacy breach, etc. etc. blah blah blah, no one can argue that Chrome has most up-to-date installs from all browsers. And because Bitcoin handles money, in my opinion it SHOULD auto-update in this manner, because if (when) we discover a hole in the protocol/client, it can take ages before everybody updates to new version.
Of course it could be done in way that an experienced user could turn it off, and there also could be stable and dev channels, just like Chrome does.

Automatic updates make things way too centralized, IMO.

Gavin should have an alert key, though, and an alert should be issued for every new version.

Right...so:

1. Outdated clients are potential attack vector.

2. Somebody mimicking Gavin is also an attack vector.

I was just asking about this today.

I think the client should be GPG signed by multiple developers, and the Bitcoin client should tell you when there is a new update, but not automatically update. It should also provide a quick changelog textbox.

I think it would be better to divide the client in 2 parts:

For windows: A EXE and a DLL.
For linux: A executeable and a SO.

The DLL/SO file contains the core functions for bitcoin, like chains, rules, mining, packets sending and such.  The DLL/SO is *NOT* locked in regards in which scripts that can appear in transactions, but the core functions will never allow the bitcoin client to change its inflation rules.

The DLL/SO is then locked in a way so *nobody* can update it while bitcoin is running, and the file is signed and checked by the bitcoin client prior to loading. The bitcoin client and the DLL/SO should also have a function preventing the bitcoin coin from updating the DLL/SO althogheter, even if you could completely decide which code is in the EXE/executeable.


In this way, we can have secure auto-update of the bitcoin, WITHOUT any fear that the core rules might change because of a hacker attack. To prevent stealing of coins from users, we could have the proposed signature scheme.

So in other words, the developers can send out autoupdates regarding non critical parts in the client, but nobody, not even the developers, can send out updates that change the central rules in the bitcoin.

Other projects with similar security requirements have been struggling with this too.

http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html

It's more subtle than you might initially expect. I advise against reinventing the wheel here.

So the part of the program I can update is responsible for the locking of the part I shouldn't be able to?

Yep, but its arranged in a situation where both survelliance each other.

So the DLL/SO survelliances that the EXE requesting API access is correctly signed and not modified, and that not critical parts are modified, and the EXE checks that the DLL/SO is not modified.

Also both the EXE and the DLL/SO can check itself in a way too.


If its too tough to make secure, you could have 2 identical DLL/SO, that survelliance each other.

How does the dll keep me from modifying it while it isn't running?

No matter how many complicated layers you add, I am still running code on your system. I can do whatever I want to circumvent those security layers because I am responsible for enforcing them in the first place.