The Most Important Bitcoin Client Feature IMHO...

[lulzplzkthx]

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.

[1715019148]

1715019148

[1715019148]

1715019148

[sebastian]

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.

[gmaxwell]

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?

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.

[anisoptera]

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.

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

[sebastian]

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.

[anisoptera]

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.