public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@exmulti•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Development priorities
Date: Thu, 16 Jun 2011 13:59:56 -0400	[thread overview]
Message-ID: <BANLkTimV+0mSqqmLYJeTdvxhM2PjtyXXMw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimZ5j7=1G89uRO9f7fHPdmDMpLMqg@mail.gmail.com>

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.

-- 
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com



  parent reply	other threads:[~2011-06-16 18:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16 16:32 Gavin Andresen
2011-06-16 17:12 ` Luke-Jr
2011-06-16 17:59 ` Jeff Garzik [this message]
2011-06-16 18:18   ` Luke-Jr
2011-06-16 18:24     ` phantomcircuit
2011-06-17  3:05 ` bgroff
2011-06-19 14:26 ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTimV+0mSqqmLYJeTdvxhM2PjtyXXMw@mail.gmail.com \
    --to=jgarzik@exmulti$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gavinandresen@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox