Development priorities

Right! I'm back from the CIA, and trying to ignore all the reporters who want to talk with me.

I want to do a quick brain dump on what I think the short-term development priorities are. Here's my list:

1) Scaling-up issues, like disconnections when downloading the block chain.

2) Wallet security.

3) Unit testing framework. There was a PULL that had the start of boost unit tests; I think that is a critical need, along with a good suite of test cases.

Those are the big issues for me. Anything that slows those down I'm going to ignore (example: love the idea of escrow transactions, but I do NOT want to add nifty new features when we're having trouble keeping the features we're using now working properly).

Does everybody agree those are the critical priorities? (try not to let this thread wander into a discussion of HOW to do stuff, just WHAT the priorities aught to be)

I'd put wallet security before scaling, but inevitably, I'm not sure there's too much anyone can do about that. Even if the wallet is encrypted, it just takes a little more complex code to steal funds if you've infected your target.

On Thursday, June 16, 2011 12:32:57 PM Gavin Andresen wrote:

> Right!  I'm back from the CIA, and trying to ignore all the reporters
> who want to talk with me.
>
> I want to do a quick brain dump on what I think the short-term
> development priorities are.  Here's my list:
>
> 1) Scaling-up issues, like disconnections when downloading the block

chain.

>
> 2) Wallet security.
>
> 3) Unit testing framework.  There was a PULL that had the start of
> boost unit tests; I think that is a critical need, along with a good
> suite of test cases.
>
> Those are the big issues for me.  Anything that slows those down I'm
> going to ignore (example: love the idea of escrow transactions, but I
> do NOT want to add nifty new features when we're having trouble
> keeping the features we're using now working properly).
>
> Does everybody agree those are the critical priorities? (try not to
> let this thread wander into a discussion of HOW to do stuff, just WHAT
> the priorities aught to be)

On Thu, Jun 16, 2011 at 12:32 PM, Gavin Andresen <gavinandresen@gmail•com> wrote:

> 1) Scaling-up issues, like disconnections when downloading the block chain.
>
> 2) Wallet security.

Agreed, though security professionals (and luke-jr) are already pointing out the wallet crypto mainly eliminates a bit of bad PR, rather than being a major crime deterrent.

zooko on IRC had a pretty good suggestion: introduce a built-in facility for air-gapped wallets (multiple wallets), so that loss of your everyday transactional wallet does not mean loss of everything.

You can do this manually, but we need something for all the people who (a) don't know crypto, and (b) simply download and run the client without thinking much about security.

> 3) Unit testing framework.  There was a PULL that had the start of
> boost unit tests; I think that is a critical need, along with a good
> suite of test cases.

Three points, on testing:

T1) autotools has a minimal testing framework built into it. "make check" builds, and then runs tests. Each test is a program or script, that returns 0 on success and 1 on failure. "make distcheck" builds, runs tests, and then creates the distribution tarball if the tests succeed.

T2) I wouldn't narrow the focus to "unit tests", as stress tests and other comprehensive, automated tests are quite useful as well

but most importantly...

T3) Don't hold v0.4 release for this. As we say in kernel-land, we have a test lab called "the internet" Test suites have clear software engineering value, but they largely "guard the past" -- making sure you don't repeat past mistakes, rather than being a good indicator of possible upcoming problems. The best testing is always in the field. That always finds more problems than unit testing ever does.

On Thursday, June 16, 2011 1:59:56 PM Jeff Garzik wrote:

> > 2) Wallet security.
>
> Agreed, though security professionals (and luke-jr) are already
> pointing out the wallet crypto mainly eliminates a bit of bad PR,
> rather than being a major crime deterrent.
>
> zooko on IRC had a pretty good suggestion:  introduce a built-in
> facility for air-gapped wallets (multiple wallets), so that loss of
> your everyday transactional wallet does not mean loss of everything.

Even if you do this, a cracker can still simply send your encrypted wallet to himself, secure-delete your local one, kill your client, and demand you publish your password if you want some portion of your coins back.

I'm not sure there's *any* defense for an insecure PC. Maybe Bitcoin will end up forcing people to reconsider their priorities when it comes to security...

On 06/16/11 20:18, Luke-Jr wrote:

> On Thursday, June 16, 2011 1:59:56 PM Jeff Garzik wrote:
>>> 2) Wallet security.
>> Agreed, though security professionals (and luke-jr) are already
>> pointing out the wallet crypto mainly eliminates a bit of bad PR,
>> rather than being a major crime deterrent.
>>
>> zooko on IRC had a pretty good suggestion:  introduce a built-in
>> facility for air-gapped wallets (multiple wallets), so that loss of
>> your everyday transactional wallet does not mean loss of everything.
> Even if you do this, a cracker can still simply send your encrypted wallet to
> himself, secure-delete your local one, kill your client, and demand you
> publish your password if you want some portion of your coins back.
>
> I'm not sure there's *any* defense for an insecure PC. Maybe Bitcoin will end
> up forcing people to reconsider their priorities when it comes to security...

Jeff's scratch off branch modified to use email (as unique salt) and password would eliminate the need for a static wallet.dat for 99% of the userbase. This seems like a much better solution than encryption. (Although obviously it's still vulnerable to key loggers).

> 1) Scaling-up issues, like disconnections when downloading the block
> chain.
>
> 2) Wallet security.
>
> 3) Unit testing framework.  There was a PULL that had the start of
> boost unit tests; I think that is a critical need, along with a good
> suite of test cases.

I agree that these are critical and I'd love to help, especially on #2 and #3. #3 will, by necessity, include a thorough review of the code, which may uncover latent issues.

I think that for #2 it would also be good to publish a "Best security practices" document to try and educate the user base.

> Those are the big issues for me.  Anything that slows those down I'm
> going to ignore (example: love the idea of escrow transactions, but I
> do NOT want to add nifty new features when we're having trouble
> keeping the features we're using now working properly).

That is understandable. However, something to think about later is that multi-signature coins can help with #2, even with compromised end-user machines.

Probably patches for this bug would also be high priority:

   http://forum.bitcoin.org/index.php?topic=19168.0

It should be an easy fix.